A2A client support / remote subagent delegation

Submission checklist

• This is a feature request, not a bug report.
• I searched existing issues and didn't find this feature.
• I checked the docs and README for existing functionality.
• This request applies to this repo (deepagents) and not an external package.

Area (Required)

• deepagents (SDK)
• dcode
• talon
• acp
• evals
• harbor
• daytona
• modal
• quickjs
• runloop
• vercel
• langsmith-sandbox
• Other / not sure / general

Feature description

#565 ("Remote subagents," closed Dec 2025) asked directly: someone running independent agents on AWS AgentCore Runtime wanted to delegate coding subtasks to those remote agents with real bidirectional communication — MCP doesn't provide that, since it's built for agent-to-tool access, not agent-to-agent task delegation. The response was "implement a custom Runnable/tool," not real support. Reopening this as a scoped proposal for A2A (Agent2Agent protocol) client support, since the underlying need was never actually addressed.

A2A is no longer a Google-only proposal — it was transferred to Linux Foundation governance in June 2025 and reached stable v1.0 in early 2026 (https://a2a-protocol.org/latest/specification/). Real, shipped (not just announced) adoption: AWS Bedrock AgentCore Runtime — the exact platform #565's use case was hosted on — has native A2A server support today; Azure AI Foundry, Salesforce Agentforce, and ServiceNow have all shipped it; Google ADK has first-class client support (RemoteA2aAgent); CrewAI added it as first-class in v0.80+. One nuance worth being upfront about: LangGraph Platform (the hosted commercial product) added a server-side A2A endpoint, confirmed by a LangChain collaborator on langchain-ai/langgraph#5987 — but the open-source langgraph library deepagents builds on does not have this natively. This proposal is ahead of that specific upstream, not behind it.

Proposed solution (optional)

dcode already ships an SDK-level primitive that's architecturally very close to what A2A needs: AsyncSubAgentMiddleware (deepagents/middleware/async_subagents.py) implements start_async_task/check_async_task/update_async_task/cancel_async_task/list_async_tasks tools tracking a task-lifecycle state machine (submitted → working → completed) that matches A2A's Task model almost field-for-field. It's wired into dcode today via [async_subagents.<name>] config entries passed to create_deep_agent(..., async_subagents=...).

Proposing an A2ASubAgentMiddleware as a sibling to that existing middleware, reusing as much of the existing plumbing as actually transfers:

• Reusable as-is: connection caching (_ClientCache keyed by url+headers), the task-state tracking pattern (persisted in agent state, survives compaction), and the existing approval-gate wiring pattern.
• Reusable with light modification: mcp_auth.py's OAuth stack (FileTokenStorage, refresh-lock logic, loopback browser flow) is already parameterized by server_name/server_url, so it should retarget cleanly at an A2A endpoint's bearer/OAuth2 auth. Streaming reuses the same SSE/streamable-HTTP wire pattern MCP's remote transports already use.
• Genuinely net-new: A2A's Agent Card discovery step (fetching/parsing a remote agent's advertised skills/capabilities at /.well-known/agent-card.json) has no analog in either MCP (discovers via tools/list post-connection) or the existing Agent Protocol integration (invoked at a fixed graph_id, not self-describing) — this is the one piece of client-side logic that needs to be written from scratch.

A trust gap worth fixing regardless of this proposal: today's async_subagents trust model is weaker than MCP's — no approve-once trust store, just the general MANUAL/AUTO/YOLO tool-approval gate, which AUTO/YOLO bypasses entirely. For A2A specifically this matters more: a remote A2A agent is autonomous (can chain its own actions), so its output is untrusted natural-language text feeding straight back into the calling agent's context — the same prompt-injection-via-tool-result class of concern raised on #5309/#4844, but harder to sanitize than structured tool output. This proposal should adopt MCP's stronger pattern (a persistent, explicit approve-on-first-use trust list under ~/.deepagents/.state/a2a-trust/, independent of and stricter than the general approval-mode interrupt), not settle for async_subagents's current weaker bar.

Scope — client-only, deliberately: this proposes dcode calling out to one known, explicitly-trusted remote A2A agent, resolving #565's actual use case. It does not propose dcode advertising itself as a remote-callable A2A agent (inbound invocation of an agent with file/shell access from an external caller) — that's a separately larger, materially riskier feature and shouldn't be bundled into a first client-side proposal.

Config sketch:

[a2a_agents.code-reviewer]
name = "code-reviewer"
description = "Remote specialist agent for deep code review"
agent_card_url = "https://my-agentcore-endpoint.example.com/.well-known/agent-card.json"
# auth handled via the retargeted mcp_auth.py OAuth flow, same trust-store pattern as MCP servers

Additional context (optional)

Related: #565 (the original ask this reopens with a scoped design), #5309 (same trust-gating questions — persistent approve-once store vs. ambient trust — apply to both), #4844 (same class of "autonomous remote actor" trust concern, different subsystem). Key existing files this builds on: deepagents/middleware/async_subagents.py, deepagents_code/agent.py (async-subagent wiring), deepagents_code/mcp_auth.py (OAuth/trust pattern to retarget), deepagents_code/mcp_tools.py (remote-transport precedent).

If this direction looks right, I'd be glad to take this on if assigned.