



























1
LangGraph currently supports MCP adapters via langchain-mcp-adapters, which allow external tools to be integrated as @tools.
However, in many cases external systems are not just tools but full agents — capable of reasoning, maintaining state, and returning structured results.
The emerging Agent-to-Agent (A2A) protocol provides a standard for communication between such agents. Supporting A2A natively in LangGraph would allow users to seamlessly add remote agents as first-class nodes/sub-graphs.
Today, connecting to a remote agent requires custom handoff implementations (handoffs guide) or custom commands.
This is not ergonomic, and doesn’t fully capture the semantics of stateful remote agents.
Users should be able to declare remote agents just as easily as they do with tools.
Introduce a new concept of RemoteAgentNode (similar to ToolNode), backed by an A2A adapter/client.
Prototype Architecture
RemoteAgent: Represents a remote agent endpoint.
RemoteAgentNode: Wraps RemoteAgent for integration into LangGraph execution.
A2AClient: Handles transport and protocol translation.
Message Flow:
LangGraph (handoff)
↓
RemoteAgentNode.run()
↓
RemoteAgent.call()
↓
A2AClient.send()
↓
[A2A protocol transport: HTTP/WebSocket/gRPC/etc.]
↓
Remote Agent
↓
Response (state update)
↓
RemoteAgentNode returns to LangGraph
To keep scope small, the first PR could implement:
RemoteAgentNode with blocking handoff only
Synchronously send state → wait for full response → return to LangGraph.
No streaming, concurrency, or advanced orchestration.
Minimal A2AClient abstraction
Simple Example Notebook
This keeps the first PR low-risk, reviewable, and easy to merge.
Future PRs can then add streaming, concurrent orchestration, memory federation, etc.
Streaming support: Pass remote agent’s token/thought stream back into LangGraph channels.
Memory federation: Allow sharing of selected history/state with remote agents.
Parallel orchestration: Enable multiple remote agents to run concurrently as graph branches.
1 Like
mnanal 3
My understanding is that A2A endpoint allows the agents to send/receive messages, it does not share the state. So the remote agent is not first-class nodes/sub-graphs as mentioned in the original feature request.
Can you comment if above understanding is correct?
Any there plans to implement the original feature request?
1 Like
Based on my understanding there is no support for converting an existing agent created using create_agent to a2a , other than need to use agent server.
What is the scenario if i have to mount to my existing fastapi , or want to deploy on aws lambda as a serverless.
I was looking for a similar implementation such as adk-python/src/google/adk/a2a/utils/agent_to_a2a.py at 7623ff1a27c412ff9b758bb76701e2daff570741 · google/adk-python · GitHub
Thank you
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。