RFC: Gemini CLI A2A Development-Tool Extension

[skeshive]

Our recent work integrating Gemini CLI with Zed and Gemini Code Assist’s agent mode has been a great learning experience. It highlighted the need for a robust, standard way to communicate between the Gemini CLI agent and various clients.

Based on these learnings, we are proposing standardizing on the Agent2Agent (A2A) protocol for all Gemini CLI integrations moving forward.

Here’s why we believe A2A is the right choice:

• Solid Foundation: A2A is a robust, open standard that gives us a stable and predictable foundation to build on.

• Extensibility: The protocol is built to be extended, giving us the flexibility to add custom data, new requirements and methods without deviating from the core standard.

• Ecosystem Alignment: With the formation of the official Agent2Agent project under the Linux Foundation, A2A is quickly becoming an industry standard (announcement). Adopting it aligns Gemini CLI with the direction of the broader AI ecosystem.

The full RFC is available here: Gemini CLI A2A Development-Tool Extension

We’ve already received positive initial feedback from partners and are now excited to open this discussion to the broader community. Once we get alignment on the spec, we plan to evolve our current experimental A2A server implementation into a proof-of-concept for this proposed extension.

To help get the conversation started, here are a few topics we're particularly interested in:

1. Does the proposed development-tool extension cover the workflows you'd expect? Are there any significant gaps in either the extension or the broader A2A spec that might hinder adoption?
2. What are your thoughts on fetching client-side context or executing client-side tools through MCP instead of within the A2A layer? Are there specific workflows where this separation of concerns might fail? (see section 4)

We look forward to your feedback.

Co-authored by: @cornmander, @adamfweidman, @skeshive

[mrlarson2007]

I think this is great idea and make it much easier to integrate gemini into more workflows. If there is an open standard then different agents can work together.

[sammccauley117]

It seems that this extension goes against two of the key guiding principals of A2A—"Async First" and "Opaque Execution". While the design does have async aspects, the fact that this is primarily being designed for IDEs means that it's more sync first where the client is in control each step of the way. Additionally, this design explicitly extends the A2A spec to make operation more interactive and manual.

I think these are completely valid changes to make for IDEs / other client surfaces and A2A Extensions are specifically for changing the behavior. However, I think it's also important to make sure that this design and implementation doesn't interfere with purely agentic tasks (ie something more like a background agent—not an IDE).

Additionally, the a2a-server requires important changes to make it truly A2A compatible and to make implementation of this design feasible (ex: restructuring task and context persistence, mechanism for determining task, mechanism for determining state transitions), but that's out of scope for this spec and requires a separate discussion. See #8118, #8117, #8116, and #8115.

My suggestion would be to ensure that the a2a-server stays just that—an A2A server. The development-tool should remain an extension and not a fundamental part of the a2a-server itself so as not to affect true async agents.

[mrlarson2007]

Those are great points. I want to build on top of Gemini if the a2a sever is too tightly integrated with IDE integrations then it's not very useful to systems builders trying to plug Gemini in to larger sysyem.

[TayDa64]

I haven't used MCP's, interest wasn't there. In my mind A2A provides more context window if the implementation was there with other ai provides as well. Then I read Sam's post A2A is more sync, hence my question to the community:: let's say GitHub codespace repo has Gemini-cli orchestrating multiple agents to work on different parts of a large project, each agent is triggered when another agent stages their task... ultimately, Gemini-cli would test/commit/and push all parts for a working model.
Is this feasible?