Google ADK 2.14 adds stronger agent tests, with upgrade risks
Google ADK Python 2.14.0 makes execution environments, A2A integration and mature evaluation components stable, while adding Microsoft Teams support. Existing users should review compatibility before upgrading. The GitHub release was published November 7, 2026. Its changelog heading is dated November 4.
The practical opportunity is better testing of agents that behave differently from run to run. The upgrade also changes tool arguments and session handling, so a successful installation alone is a poor readiness check.
Start with the upgrade risks
Tool inputs annotated as enums now arrive as enum members. Code expecting raw strings needs review. VertexAiSessionService also rejects unsupported session configuration keys. Pass state and session IDs through their dedicated parameters.
Firestore deserves a rollback check: sessions written by 2.14.0 cannot be read by 2.13.0 or earlier. For the 16 promoted toolset and integration features, experimental disable controls silently stop working. Teams relying on those switches should review their deployment controls.
For skill scripts, Google changed how execution arguments are constructed. Environment mode now uses validated script paths and structured arguments. Calls that still supply command return INVALID_ARGUMENTS. Supported script extensions are .py, .sh and .bash, and execution starts from the skill directory.
That can affect prompts and recorded evaluations as well as application code. Review examples that teach an agent the old call format, then check relative paths to bundled files. Otherwise, a correct script may appear broken because it is looking in a different working directory.
The updated guidance still warns that the script inherits its execution backend’s privileges. Local execution remains unisolated. Choose a sandbox for untrusted skills or users, and test permission boundaries separately from script correctness.
Repeated evaluations expose inconsistent agents
The evaluation configuration guide explains how multi_run_config repeats each case from a fresh session. Every repetition is retained. By default, scores are averaged across invocations, which means an overall pass can include an individual failure.
That distinction matters for actions with a narrow tolerance for error. An assistant that usually selects the right customer record can earn a respectable average while still making an unacceptable mistake. Pick the acceptance rule before comparing versions.
The CLI supports worst run scores and pass rates. Google also distinguishes pass_at_k, which estimates whether at least one attempt succeeds, from pass_hat_k, which estimates whether all k attempts succeed. They answer different questions about capability and consistency.
Check the entry point you use. The guide says AgentEvaluator takes its run count through its own num_runs argument, rather than reading multi_run_config. It and adk web ignore the documented scoring aggregation keys. A configuration file shared across tools therefore needs an explicit verification step.
Our suggested upgrade trial is to replay a small set of consequential workflows against both versions. Hold the model, prompts, input data and tool responses steady. Record failures individually, then examine whether any apparent improvement comes from a more forgiving scoring rule.
Argument matching needs clear boundaries
The new ToolArgsMatcher guide describes comparisons chosen per argument, including exact matching, case folding, numeric tolerance and semantic judgments. The guide still marks this API experimental, despite the wider graduation of mature evaluation components.
A useful example is a search tool that accepts a city and a record identifier. Case differences in a city name may be harmless. A different identifier should fail. Configure those expectations separately instead of giving the whole call a loose semantic comparison.
There is another subtlety: allow_extra_args defaults to true. Setting it to false makes unexpected arguments fail the overall matched decision, but extra arguments still do not reduce the score when short_circuit is off. A test that only checks the score can therefore miss what its author intended to reject.
For regression tests, inspect both the decision and the results for each argument. Keep exact checks for fields whose identity matters, and use model judging only where meaning is genuinely the requirement. This makes a failed test easier to explain and reduces dependence on a second model’s opinion.
Treat deployment readiness as a separate decision
ADK 2.14.0 gives developers more ways to run and evaluate agents. Whether a particular application is ready depends on its own tools, stored state and failure costs. Start with a staging replay, confirm the upgraded call shapes, and rehearse recovery before moving live traffic.
If the agent also stores lasting context, ByteForward’s guide to Google Memory Bank controls covers scope, retention and revision history. Include a remembered preference that changes over time in the test set, so retrieval correctness and action correctness are examined together.
Featured image: AI generated editorial illustration by ByteForward. Google and the Google logo are trademarks of Google LLC. ByteForward is not affiliated with or endorsed by Google.
