A2A's Future Directions: Agents Are Planning to Form a Local Area Network

A2A already lets Hermes instances on two different machines “call” each other. So what’s next? Hidden in the community’s wishlist is a much bigger blueprint.

What’s Already Possible: A Quick Recap of the “Phone” Itself

A2A v1.0 has landed. In simple terms, it lets Hermes instances on different machines exchange business cards (Agent Card) like two colleagues, communicate using standard protocols (JSON-RPC), push real-time progress updates (SSE streaming), and remember context across multi-turn conversations. Security is solid by default: each peer gets its own token, and every action is audited. Think of it as giving each Hermes a “work phone” — it can call, text, and leave voicemails, but only one-on-one.

Direction One: Agent LAN (Multi-Node Coordination Network)

The hottest proposal from the community is upgrading the “phone” into a “local area network.” Picture this: you’ve got a macOS workstation, a Windows desktop, a Linux server, maybe even a laptop and a phone at home, each running its own Hermes instance. Right now they’re all doing their own thing. The hope is that they’ll form an “agent LAN” over a private overlay network. It’s like all your smart devices connecting to the same Wi-Fi — you shout once, and the living room speaker, the bedroom lights, and the kitchen oven all respond in sync. For Hermes, this means tasks can flow automatically across devices: research gathered on your laptop gets synced to your workstation for heavy processing, and the results get pushed to your phone for a quick review.

Direction Two: Agent Hierarchy (Boss and Subordinates)

Right now, Hermes instances are “peers” — whoever initiates the conversation is the active party. What the community wants is a “hierarchy”: a leader Hermes can delegate tasks to a subordinate Hermes on another machine, and the leader can see the task’s progress in real time — note, “see,” not “interfere.” It’s like a boss assigning work to a subordinate: you just need to know the status, not micromanage every step. This “passive observability” is key: it preserves the subordinate’s autonomy while keeping the boss in the loop.

Direction Three: Multi-Session Collaboration (From Islands to a Meeting Room)

Say you open three sessions on the same machine — one for research, one for implementation, one for review. Right now they’re three isolated islands. Key findings from the research session have to be manually copy-pasted into the implementation session, which is fragile and error-prone. The community proposal is to let these sessions “message” each other and share necessary context. Imagine: instead of three separate cubicles, it’s one meeting room where three people can pass notes and exchange opinions anytime, but each person’s own notes remain private.

Direction Four: Local Walkie-Talkie (Cross-Session Messaging)

This proposal is more focused: multiple interactive Hermes sessions on the same machine should have a “first-class” local messaging mechanism. No network protocols needed — it’s like a walkie-talkie in the office: press a button and you’re talking. The research session finds a critical piece of info and directly “pings” the implementation session: “Hey, watch out for that API usage in paragraph three.” No copy-pasting, no fragile hacks like tmux send-keys. This complements Direction Three: one handles cross-machine, the other handles same-machine.

Direction Five: Remote Approval Policies (Security Gates)

A2A currently allows remote peers to push tasks into your live session. Useful, but risky — what if the remote party asks you to modify files? The community wants a “scoped trusted peer” policy: you can designate a specific Hermes on a specific machine as “trusted,” and tasks from it are allowed to execute local side effects. Everything else is read-only. It’s like an office access card: some people can enter the finance room, others can only use the conference room. This is a critical piece of the delegation security puzzle.

Direction Six: Visible Notifications for Task Completion

Right now, when an A2A task finishes, the result gets written to logs or returned via a JSON-RPC response. But what if you’re not staring at the logs? The community wants a notification to pop up in the Hermes channel you’re actively using when a task completes — like a push notification on your phone: “The task you delegated to that machine is done, here’s the result.” It doesn’t interrupt you, but it keeps you informed.

What’s Already Partially Implemented?

Good news: the “bounded worker” concept from the community proposals is already partially implemented — a configurable external launcher that can restrict the execution boundaries of remote tasks. That’s basically laying the foundation for “remote approval.” Also, details like the 330-second timeout, late-arriving results, and context isolation are already in place. But keep in mind, the big-ticket items — multi-node coordination, hierarchy, local walkie-talkie — are still just wishes sitting in open issues.

What Does This Mean for You?

If you’re a regular user, these directions mean: in the future, Hermes instances might no longer be lone operators, but a coordinated “team.” You don’t need to worry about how they communicate — you just need to know that all the Hermes instances across your devices will help each other out like family, and nothing you need to know will slip through the cracks.

One final reminder: these are all open issues proposed by the community. The official .plans directory has already been removed (2026-08), so there’s no guarantee everything will be implemented. But at least the blueprint is drawn — agents are planning to form a LAN, and this time, they intend to bring the “home” into the network too.

One More Thing: Forwarded Sessions After the Ownership Cutover

Forwarding to another local profile now submits to that profile’s gateway owner — there is no fallback hermes chat process writing its session database. New forwarded conversations keep the exact agent, tenant, authenticated peer and context ID in their owner binding. Historical forwarded sessions, however, cannot be identified safely from their titles: the old adapter used a2a-{agent}-{sanitized-context} and dropped peer and tenant identity, so different contexts (even from different peers) could share one transcript. A matching historical title therefore returns runtime_coordination_required instead of attaching a peer to unrelated history, and the old session ID, title and messages stay untouched. Automatic migration is not yet supported, and there is no supported migration command — don’t retitle or edit database rows to bypass the ownership check.