What stable covers here
The graduation list is the substance of this release. Google says 26 modules and 16 toolset and integration features have moved out of experimental status, including execution environments, A2A-related capabilities and parts of the evaluation stack. The list includes local, Daytona and E2B execution environments. The release also adds multi-run evaluation and semantic tool-argument matching, which extend the testing capabilities available to agent developers.
MultiRunConfig runs each eval case several times concurrently and combines the scores, which is how you stop a single lucky run from passing a bad agent. ToolArgsMatcher can check tool call arguments with an LLM-backed semantic comparison instead of exact string matching alone.
A2A going stable is the piece with reach beyond Google's own stack. A2A is designed to let agents discover and communicate with agents built using different frameworks. ADK now includes adk generate_agent_card, a command for generating the agent metadata used in that process. Moving ADK's A2A integration to stable gives developers a stronger compatibility signal for Google's implementation. It does not guarantee interoperability with every other A2A implementation, or eliminate versioning and integration risks across frameworks.
The integrations are smaller. A runner puts ADK agents inside Microsoft Teams chats and channels. A classifier for workflow and tool-gating questions can call OpenAI's Decisions API, an odd guest inside a Google framework, but a practical one. Agent memory can sit in MongoDB with vector search and an expiry date.
The 23 percent, read closely
The performance line in the notes is one sentence: a 30-node workflow's 200-turn run is 23 percent faster with 9 percent lower peak memory. Faster than what is not stated. The notes do not name the release it was compared against, the hardware it ran on, or the absolute times behind either percentage, and there is no second workflow shape to show whether the gain holds at a different size.
That does not establish that Google's figure is false. It establishes that the published evidence is insufficient to reproduce or generalize it. The notes give a 23% runtime improvement and 9% lower peak memory for a 30-node, 200-turn workflow, but do not identify the comparison version, hardware, absolute measurements, number of repetitions or variability. They also provide no results for other workflow sizes. Google may have run additional tests; none are documented in the cited release notes. Until it publishes the methodology, teams should treat both percentages as vendor-reported results for an incompletely specified benchmark, not as expected gains in their own deployments.
The security fix is filed as a breaking change
The change closes a prompt-injection path identified in Google's release notes: in environment mode, RunSkillScriptTool previously accepted a free-form shell command string, potentially allowing a prompt-injected model to execute arbitrary commands. Version 2.14 instead requires structured arguments and restricts execution to supported scripts in the skill directory. Existing calls that pass a command string will fail. The release notes do not establish that the issue was exploited in production, nor does this change make skill execution generally immune to prompt injection.
Removing that command-execution path is a security-relevant change, even though Google presents it under breaking changes rather than a separate security advisory. Teams using skill scripts should prioritize reviewing this change, test their invocation paths and upgrade through their normal security process. The absence of a CVE or urgency label in the cited notes should not be mistaken for evidence that the old behavior was harmless.
Three quieter traps in the same release
Two more changes deserve a look before an unattended upgrade. Tool arguments typed as Enums now arrive as enum members rather than the strings the model sent, and the notes list the casualties directly: equality checks against string values, string-keyed dictionary lookups and JSON serialization no longer work the way existing code expects. That is the kind of break that passes import checks and fails at runtime.
The release also removes the ability to disable the 16 promoted toolset features through their former experimental feature flags and CLI options. According to the notes, those obsolete switches no longer block the features and produce no error or warning. That does not establish that every feature activates automatically in every deployment. It does mean teams relying on the old switches can no longer assume those settings enforce their intended restrictions. Check the actual configuration and runtime behavior before upgrading.
The release notes also warn that Firestore sessions written by version 2.14 cannot be read by version 2.13 or earlier. That creates a backward-compatibility problem for deployments using the affected session service, rather than a universal rollback failure across ADK. Teams should test session migration and recovery, preserve appropriate backups and plan for the possibility that older application versions cannot read sessions created after the upgrade.
None of this makes 2.14 a release to avoid. It makes it a release to schedule rather than absorb. The stable surface is the reason to move; the breaking list is the reason to move deliberately, with the Enum change and the skill-script change tested before the version touches production agents. For production deployments, the minimum upgrade test should cover Enum arguments, skill-script invocation, obsolete feature flags and Firestore session compatibility where applicable.
Sources
- [1] Google, ADK Python v2.14.0 release notes, google/adk-python on GitHub (notes dated 4 November 2026; tag published 7 November 2026)Read source
- [2] PyPI, google-adk package record (2.14.0 uploaded 7 November 2026)Read source
- [3] AI Weekly, "Google ADK 2.14.0 Graduates Core Modules, Adds Teams Runner" (8 November 2026), secondary coverage flagging the missing benchmark baselineRead source