[ENHANCEMENT] Support A2A Protocol

[farazoman]

Problem (one or two sentences)

Agent to agent communication is the new standard. Not many if at all, coding agents support this yet. To be ahead, if a2a support is enabled, it can allow Roo to have long term connections to agents outside of it self which can solve problems like having a specialized agent resolve a specific task while roo continues with what its an expert in. Right now, if we want to do this connction, we can wrap an agent with MCP but that is only a 1 way connection. A2A allows for roo to continue to run.

Context (who is affected and when)

Any time we want to connect an agent to roo code, I can do that with A2A.

Desired behavior (conceptual, not technical)

Ability to connect agents that support A2A.

Constraints / preferences (optional)

Should be similar to MCP config, where we can disable some agents and not others.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

Given a user wants to add an agent
When configuring roo
Then the experience will be the same as adding an MCP server

Given roo wants to accomplish a task which a configured agent is made to do
When it calls that agent
Then using a2a a connection is established with the other agent

Given an agent is executing work for roo
When the connection starts
Then roo doesn't have to wait for the agent to finish to continue doing something else

Given an agent is executing work for roo
When the agent asks roo for more information
Then roo can respond

Given an agent is executing work for roo
When roo wants an update or wants to share new information or a new task
Then roo can use the existing connection to tell the agent the new piece of information or question

Given an agent is executing work for roo
When roo asks an agent a question after giving it its initial task
Then the agent can respond to roo

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote-v0]

I have looked into this issue and explored the existing MCP infrastructure in the codebase to understand the patterns. Here are some thoughts and questions before proposing an implementation plan.

Context

The A2A (Agent-to-Agent) protocol is Google's open protocol for inter-agent communication. It complements MCP by enabling bidirectional, asynchronous communication between agents -- where MCP is a one-way "client calls server tools" pattern, A2A allows two agents to negotiate, delegate tasks, stream updates, and exchange artifacts.

The current MCP implementation in Roo Code follows this architecture:

• Configuration: mcp_settings.json (global) and .roo/mcp.json (project-level)
• Service layer: McpHub manages connections, McpServerManager handles lifecycle
• Tool integration: use_mcp_tool and access_mcp_resource tools exposed to the LLM
• UI: MCP settings panel for configuring/enabling/disabling servers
• System prompt: MCP capabilities injected into the system prompt dynamically

Clarifying Questions

1. A2A spec version: The A2A protocol is still evolving. Should we target the current spec (as of mid-2025), or is there a specific version/draft you have in mind?

2. Scope of initial implementation: A full A2A implementation is substantial. Would you be open to a phased approach? For example:

   • Phase 1: A2A client support only (Roo delegates tasks to external A2A agents, receives results)
   • Phase 2: Bidirectional communication (external agents can query Roo back)
   • Phase 3: Roo as an A2A server (other agents can discover and delegate to Roo)

3. Discovery mechanism: A2A uses "Agent Cards" (.well-known/agent.json) for discovery. Should the initial implementation support:

   • Manual configuration only (like MCP -- user provides agent URLs)?
   • Auto-discovery via Agent Cards?
   • Both?

4. Task lifecycle: A2A supports long-running tasks with streaming updates. How should this integrate with Roo's existing task model? Should A2A tasks run as background subtasks, or should Roo wait for completion?

5. Authentication: A2A supports various auth schemes. Should the initial implementation support a specific auth method, or should it be configurable (Bearer tokens, OAuth, API keys)?

6. Priority: Is there a specific use case or external agent you are trying to connect with? That could help prioritize which A2A features to implement first.

High-Level Proposed Plan

Assuming a phased approach starting with A2A client support:

1. New service: src/services/a2a/ -- mirroring the MCP pattern with A2aHub (manages agent connections) and A2aAgentManager (lifecycle management)
2. Configuration: a2a_settings.json (global) and .roo/a2a.json (project-level), similar to MCP settings, storing agent URLs, auth config, and enable/disable flags
3. Agent discovery: Fetch and cache Agent Cards from configured agent URLs
4. New tools: delegate_to_agent tool (exposed to the LLM) that sends a task to an A2A agent and handles the response/streaming
5. Tool group: New a2a tool group in mode configurations, similar to the mcp group
6. UI: A2A settings panel in the webview (similar to MCP settings) for adding/removing/enabling agents
7. System prompt integration: Inject available A2A agent capabilities into the system prompt
8. Types: New types in @roo-code/types for A2A agent configs, task messages, etc.

This is a significant feature. I would appreciate your input on the questions above and whether this direction aligns with your vision.

Please mention @roomote in a comment saying that you approve this plan (or with answers to the questions), and I'll proceed with the implementation.

[farazoman]

@roomote 1. use the latest spec available
2. lets do a phased approach, and phase 3 is probably not needed at the moment
3. manual configuration only, auto discovery should be out of scope
4. as background sub-tasks. Prompts will have to keep that in mind as well ofcourse
5. lets keep it simple with api keys for the moment. When configuring the url we should be able to set headers so that any auth can be with custom key value pair, to make it simple it should be a json
6. its a custom one, so really just trying to get away from having to wrap an agent in mcp for a more seamless experience and avoid long running mcp tool calls

[roomote-v0]

Thanks for the detailed answers @farazoman! I've seen your comment and will proceed with Phase 1 & 2 implementation based on your guidance:

1. Latest A2A spec
2. Phased approach (Phase 1: client delegation, Phase 2: bidirectional) -- Phase 3 out of scope
3. Manual configuration only -- no auto-discovery
4. Background sub-tasks with prompt awareness
5. Simple auth via configurable headers as JSON key-value pairs
6. Custom agent use case -- seamless alternative to wrapping agents in MCP

I'll explore the codebase now and open a draft PR to share progress. Feedback and guidance are welcome!

[roomote-v0]

Opened a draft PR with my attempt at implementing Phase 1 of A2A protocol support: #12008

This includes:

• A2aHub service -- manages agent connections via a2a_settings.json (global) and .roo/a2a.json (project-level)
• delegate_to_agent tool -- lets the LLM send tasks to external A2A agents using JSON-RPC 2.0 over HTTP
• Configurable auth -- headers as JSON key-value pairs for API keys or custom auth
• System prompt integration -- available agents listed in capabilities section
• New a2a tool group -- added to code mode, follows MCP patterns

All existing tests pass, lint and type-check clean across the monorepo. Feedback welcome!