[Feature] remote agent communication

[x87shukliu]

🎯 The Goal / Use Case

let agent can send message to another agent(remote, not local) through gateway, even user can set to gateway
external channel is quite limited on the cluster based agent.

💡 Proposed Solution

gateway open a ws or http

ex: http
xxxx/agent/{x}
{message}

=> {message} will be sent to agent x and wait for response (ws,

🚦 Impact & Roadmap Alignment

• This is a Core Feature, to enable large scale deployment of agents and agentic cooperation between agents

🔄 Alternatives Considered

I rough go through the code with llm, no sure whether I fully understand correctly whether any channel without social media channel. and can communicate between agents not in the local

💬 Additional Context

[alexhoshina]

This is within the plan

[x87shukliu]

@alexhoshina any feature link I can follow with?

[nikolasdehor]

Interesting feature. A few thoughts on the architecture:

HTTP vs WebSocket

For agent-to-agent communication, both have tradeoffs:

• HTTP (POST /agent/{id}/message): Simpler, stateless, works well for request-response patterns. But adds latency if the remote agent needs multiple tool iterations before responding.
• WebSocket: Better for streaming responses and bi-directional communication, but adds connection management complexity.

A practical approach might be HTTP for the external API with an optional WebSocket upgrade for streaming, similar to how the Pico Protocol channel works (Phase 7 in #621).

Implementation suggestion

This could be implemented as a new channel type (pico-remote or agent-mesh) rather than modifying the gateway core. The channel would:

1. Expose an HTTP endpoint on the gateway: POST /api/v1/agents/{agent_id}/message
2. Route incoming messages through the existing MessageBus
3. Return the agent response synchronously (or stream via SSE)

Authentication would be critical here — an API key or mTLS between gateways to prevent unauthorized agent invocation.

Relation to existing work

The channel refactor (#621, PR #662 — now merged) introduced the Pico Protocol channel, which already provides a structured message format. Extending it with remote transport could be a natural next step rather than building from scratch.

@alexhoshina mentioned this is in the plan — is there a tracking issue or branch for the design doc?