🔎 Lint report: hermes/hermes-8d223d48 vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 10105 on HEAD, 10100 on base (🆕 +5)

🆕 New issues (4):

tests/plugins/test_a2a_plugin.py:17: [unresolved-import] unresolved-import: Cannot resolve imported module `pytest`
tests/plugins/test_a2a_plugin.py:405: [invalid-assignment] invalid-assignment: Object of type `object` is not assignable to attribute `_message_handler` of type `((MessageEvent, /) -> Awaitable[str | None]) | None`
plugins/platforms/a2a/tools.py:313: [invalid-argument-type] invalid-argument-type: Method `__getitem__` of type `bound method str.__getitem__(key: SupportsIndex | slice[SupportsIndex | None, SupportsIndex | None, SupportsIndex | None], /) -> str` cannot be called with key of type `Literal["description"]` on object of type `str`
plugins/platforms/a2a/protocol.py:151: [invalid-assignment] invalid-assignment: Invalid subscript assignment with key of type `Literal["message"]` and value of type `dict[Unknown, Unknown]` on object of type `dict[str, str]`

✅ Fixed issues: none

Unchanged: 5230 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

Live validation (Tier 1–3)

Ran the plugin end-to-end against real HTTP and a real model (gemini-2.5-flash on OpenRouter), in isolated HERMES_HOMEs — did not touch any live gateway.

Tier 1 — protocol + security loop (real HTTP, stub agent): ✓
Real client tools → real adapter → reply. Injection markers defanged, secrets redacted both directions, persistence + audit written, bearer-auth 401 enforced.

Tier 2 — real gateway + real model: ✓
message/send → live gateway → live session → model → reply over A2A. Confirmed "17 times 4 is 68." round-trip. Also confirmed A2A goes through the same first-contact flow as every platform (pairing auth via A2A_ALLOW_ALL_USERS, home-channel via A2A_HOME_CHANNEL) because it's a real platform adapter.

Tier 3 — CLI agent choosing the tools: ✓
Agent discovered the peer's Agent Card, called it, got PONG — verified on both client audit log and peer conversation log.

Bugs the live runs caught (fixed in 2c31741)

1. Handler calling convention. registry.dispatch calls handler(args, **kwargs) (args = dict positional). The handlers used keyword params, so the dict bound to the first param → 'dict' object has no attribute 'strip'. Rewrote to args: dict (spotify/google_meet convention) + added a registry-dispatch regression test that exercises the real call path the kwarg-style tests missed.
2. Param-name ergonomics. The model repeatedly tried agent_name= instead of agent= (6 retries). Now accepts agent_name/name + message/text/task aliases.

Known design note for review (not yet addressed)

A2A is synchronous request/response, but the gateway's first-contact onboarding notices (pairing code, "no home channel set") are delivered via the same send() path — so my adapter resolves the reply Future on that notice and returns it to the peer agent as the task answer instead of an actual response. A human on Telegram reads the notice and continues; a peer agent gets the notice as the reply with no way to act on it. Options: (a) pre-seed/skip onboarding for the a2a platform, (b) suppress one-time notices when the platform is request/response, (c) treat A2A peers as pre-authorized when a bearer token gates the surface. Worth deciding before promotion.

Agent Message Bus — a complementary internal orchestration approach

Hi team, great work on the A2A plugin! We have been working on a related but complementary solution for local multi-agent orchestration (which the DESIGN.md explicitly lists as a different problem left for future work). Sharing our approach in case it is useful.

What we built — Agent Message Bus (AMB)

AMB is a pull-based internal agent-to-agent message bus — Hermes profiles (general, dev, research, study) communicate via a shared SQLite store with MCP tool access:

# Every agent checks their inbox at turn start
messages = mcp_agent_message_bus_agent_read_messages()
if messages:
    for msg in messages:
        result = process_task(msg)
        mcp_agent_message_bus_agent_mark_done(message_id=msg.id, result=result)

Architecture highlights:

• SQLite backbone — messages are rows with status (pending/delivered/done/failed), priority, chain depth tracking, correlation IDs
• MCP tools — agent_read_messages, agent_send_message, agent_mark_done, agent_discover, agent_list_cards — registered via mcp_servers in config.yaml
• Autonomous cron layer — watchdog (2min), auto-responder (5min), message router (30s), dream engine (nightly) — all Hermes cron jobs
• Bridge engine — loop protection (max chain depth 3, rate limit 3/60s, auto_reply filter)
• LLM bridges — each specialist agent gets a bridge for autonomous task processing
• Permissions — AuthZ matrix per agent (who can message whom, what types)

Why it is complementary to the A2A plugin

AMB is what lets a Study profile agent ask Dev for a file path, or Research send a status update back to General — all on the same host, with zero network config.

How AMB could be packaged as a Hermes plugin

Following your plugins/platforms/a2a/ architecture, an equivalent plugins/platforms/amb/ would contain:

plugins/platforms/amb/
├── plugin.yaml          # manifest (kind: mcp_server)
├── __init__.py          # register(): MCP server + optional cron jobs
├── amb_bus.py           # SQLite CRUD, schema, correlation
├── amb_permissions.py   # AuthZ matrix
├── amb_bridge.py        # LLM bridge with loop protection
├── amb_watchdog.py      # Stale message monitoring
├── DESIGN.md
└── README.md

The MCP server registration pattern (from your register_tool API) would make the bus tools available to any profile without manual config:

# __init__.py
def register(ctx):
    # Register MCP tools
    ctx.register_tool("agent_read_messages", agent_read_messages_handler)
    ctx.register_tool("agent_send_message", agent_send_message_handler)
    ...
    
    # Optional: register cron jobs
    ctx.register_cron("amb-watchdog", schedule="*/2 * * * *", handler=watchdog_run)

Next steps

We have the full implementation running in production across multiple Hermes profiles. If the team is interested, we would be happy to:

1. Contribute an amb plugin PR following your architecture conventions
2. Add documentation and tests matching the existing patterns
3. Keep it aligned with the A2A plugin so both external and internal multi-agent are covered

Happy to discuss further — either in this PR or a dedicated issue.

(Full standalone repo: https://github.com/kriszmac4/a2a-communication-protocol)