Deprecating A2A Supervisor and packaged A2A sub-agents

[sriaradhyula]

We are proposing to deprecate the legacy A2A-based Supervisor agent and packaged A2A sub-agents.

Related issue: #1972
Follow-up feature request: #1996

Summary

Issue #1972 reported that A2A agent container images have not been published after 0.5.16-dev.1, which causes A2A agent deployments on Helm 0.5.17 to enter ImagePullBackOff.

In the June 22, 2026 CNOE SIG Agentic AI community meeting, we discussed that this is part of a larger architecture shift: CAIPE is moving away from the legacy Supervisor-to-A2A-sub-agent model and toward Dynamic Agents as the default agent runtime.

Rationale

The original A2A Supervisor/sub-agent design made sense when model context windows were smaller and splitting responsibilities across sub-agents helped keep prompts and tool access manageable.

That tradeoff has changed. Dynamic Agents now give us a simpler path:

• users can create and customize agents at runtime
• prompts, tools, skills, workflows, and middleware can be configured without new agent code
• MCP tools can be attached directly to an agent
• role-based access control can be applied around tools
• default agents such as an SRE agent can replace the old default Supervisor experience

The legacy A2A topology also adds operational and maintenance cost:

• extra containers and release artifacts to build and publish
• dependency and CVE surface from code paths we no longer actively use
• network hops, retries, latency, and startup ordering concerns
• health polling and lifecycle management for remote sub-agents
• complex streaming behavior when multiple sub-agents stream tool events and partial results back to the Supervisor

What is changing

We plan to deprecate the current A2A-based Supervisor agent and packaged A2A sub-agents as the default CAIPE architecture.

This does not mean the sub-agent concept disappears. Dynamic Agents can still support composed agent behavior, but the preferred path is local/configured agents and tools rather than packaged A2A sub-agent containers.

A2A going forward

A2A can still make sense for remote or enterprise agents that need to be federated across boundaries.

The follow-up proposal in #1996 tracks adding A2A support back through Dynamic Agents as an explicit tool-call style integration. That work may evaluate ADK A2A support instead of continuing custom native A2A scaffolding, and may keep a minimal A2A tool implementation if it remains useful and maintainable.

Feedback requested

Please share concerns, use cases, or migration blockers in this discussion, especially if you depend on the current A2A Supervisor or packaged A2A sub-agent images.

[sriaradhyula]

Follow-on: A2A as tool calls in dynamic agents

Opened #2013 to track the next step after this deprecation — integrating remote A2A agents as LangChain tool calls inside dynamic agents, with netutils as the first example.

The approach avoids restoring the old BaseLangGraphAgent monolith. Instead:

• A lightweight create_remote_agent_tool factory in dynamic agents wraps any A2A endpoint as a BaseTool using plain httpx (no A2A SDK on the client side)
• Netutils gets a thin A2A server rewrite (~30-line executor backed by the existing mcp/netutils) using the A2A SDK only on the server side
• Agent card at /.well-known/agent.json auto-populates the tool name + description for the LLM

See #2013 for full design, sample code, and acceptance criteria.