Google ADK 2.14 Stabilizes Its A2A Integration: What Changes for Multi-Agent Teams

Most multi-agent systems become harder to maintain at the handoffs. Each agent works on its own, but handing work to another agent usually means custom integration code, and that code depends on both implementations staying unchanged. On November 7, Google released version 2.14.0 of its Agent Development Kit, and the most consequential change is a graduation: its A2A integration, execution environments, evaluation modules and core runtime all move from experimental to stable, per Google ADK 2.14 Makes the A2A Protocol Stable. Stable status does not make an application production-ready. It gives builders a defined API baseline in areas that previously carried experimental warnings.

What actually graduated on November 7

The release moves 26 auth, environment, app, CLI and cache modules, plus 16 toolset and integration features, from experimental to stable in a single update, per Google ADK 2.14 Adds Teams Integration and Multi-Run Evals. The execution layer is part of that surface: BaseEnvironment, LocalEnvironment, EnvironmentToolset, DaytonaEnvironment and E2BEnvironment are now stable, per Google ADK v2.14.0 makes execution environments, A2A and evaluation stable. Two execution details matter for anyone running agents against real systems. A streamed file read now supports line ranges without loading the whole file into memory, and the code executor runs skill scripts from validated paths and arguments instead of accepting a free-form shell command string. That second change is a security boundary, not a convenience: it narrows what an agent can be talked into executing.

Evaluation graduated too, and it matters more in production than in a demo. MultiRunConfig executes each evaluation case multiple times, concurrently, and combines scores or pass rates across runs. ToolArgsMatcher compares tool-call arguments through exact, case-insensitive, numeric-tolerance or LLM-backed semantic checks, and the matching rule becomes an explicit part of the test. Single-run evaluation hides variance: a model that passes once can fail the same case on the next attempt. Repeated runs are how you find that out before your customers do.

Why the stable A2A integration matters more than the version number

A2A — the Agent2Agent protocol — defines how one agent hands a stateful task to another agent: an Agent Card, a JSON document listing an agent's identity, skills, endpoint and authentication requirements, plus a Task with a lifecycle, Messages and Artifacts, with JSON-RPC, gRPC and HTTP+JSON bindings, per MCP vs A2A vs OpenAPI: Which Agent Integration Standard to Use. The distinction the protocol's own documentation draws is the useful one: agents partner on tasks over A2A and use capabilities over MCP. If the thing on the far side keeps no plan of its own, it is a tool, and a tool call does not need a task lifecycle. If it reasons, holds state and accepts work, it is an agent, and it needs a protocol for delegation.

Precision matters here: A2A 1.0 was already a stable protocol specification — Google called the March 2026 v1.0 release its first stable version, per the Beri comparison linked above. What changes in ADK 2.14 is the implementation status: Google's A2A integration is no longer experimental, and a CLI command — `adk generate_agent_card` — builds an agent card from the command line, per the DEV Community release breakdown linked above. The release also adds a TeamsRunner that exposes ADK agents inside Microsoft Teams chats and channels, and a MongoDB memory service with vector-search retrieval and TTL expiration, per the release notes coverage. Google reports that a 30-node workflow running 200 turns executes 23% faster with 9% lower peak memory. Treat the figure with care: the release notes publish no baseline hardware, no named comparison version and no second workload, and the result has not been independently verified, as both the AIToolsRecap and Emergent coverage note.

One caution matters. A stable specification does not mean every implementation speaks the same version of it. A2A 1.0 renamed core methods, and a November 4 check of vendor guides found major platforms still documenting older protocol names and older SDK pins, per the Beri comparison linked above. A vendor's A2A checkbox tells you nothing about which version it speaks. Test the exact pair of agents you plan to run together.

The breaking changes, and one security fix

Three breaking changes accompany the release, per the Emergent coverage. Enum tool arguments now arrive as enum members rather than raw strings, so existing code needs type adjustments. VertexAiSessionService now raises an error on unrecognized keyword arguments instead of ignoring them. And the skill-script tool no longer accepts a free-form command parameter, restricting execution to validated scripts from a designated directory. That third change closes a real gap: free-form command execution increases prompt-injection and misuse risk, because model-generated text can influence what the host runs. Budget the upgrade and treat the migration as a reliability exercise, not a chore.

What this means for your business

1. Audit your pairwise glue before paying for more of it. Every custom integration between two agents becomes code your team must maintain, secure and update whenever either side changes. Where agents expose a standard Agent Card and accept tasks over a stable protocol, a new agent can join a workflow with less bespoke work — but identity, permissions, data contracts and version compatibility still remain, so measure the saving against your current maintenance load instead of assuming it. Inventory your hand-built agent-to-agent handoffs; those are the first candidates to test against the standard.

2. Adopt A2A at real agent boundaries, not everywhere. The protocol earns its overhead only where another agent — one with its own reasoning and its own state, often owned by another team or vendor — has to accept work from yours. Inside a single system, direct tool calls and your existing APIs remain the cheaper answer. The standard also does not remove inference, retry or coordination costs, and it does not define your policy for failed tasks, duplicate submissions or partial completion. Drawing the boundary, and the failure policy, is the architecture decision; the protocol is just the mechanism.

3. Make repeated-run evaluation your release gate. A single successful run should not qualify an agent change for release. Run each case several times, declare how tool arguments will be matched, and track pass rates per agent, task duration and failure state — not anecdotes.

4. Verify version compatibility before you believe a roadmap. Stable on one side does not guarantee the other side speaks the same revision. Before committing to a cross-vendor workflow, run a live task between the two exact systems, check the Agent Card each one actually serves, and confirm the method names and task states match. Check session and state compatibility before upgrading, too — and whether you can roll back if the new version writes data the old one cannot read. A short interoperability test before commitment is cheaper than discovering the mismatch in production.

5. Assign an owner to every shared agent. A stable protocol does not answer who keeps an Agent Card accurate, who approves changes to a shared agent's skills, who rotates its credentials, or how much notice consumers get before an endpoint changes. Name that owner before other teams build on the agent, and apply the same review to permissions: list what each agent can execute, what it can call, and which identity and permissions apply at each handoff.

The durable change in ADK 2.14 is narrower than the launch framing — and more useful. Execution, evaluation and agent-to-agent communication now sit on a stable API baseline inside a major framework. That makes cross-team agent delegation easier to plan, test and price. The teams that benefit first will be the ones that map their agent boundaries now, while adoption is still a deliberate choice rather than a deadline.

Ready to map where standard agent protocols would cut integration cost in your operation? Get a free AI audit — we'll map your highest-leverage automation opportunities in one session.