What Google released
Google published Agent Development Kit for Python v2.14.0 on GitHub on November 7. The release notes label the version November 4. Google says the release promotes execution environments and sandboxes, A2A integration, evaluation and user-simulation classes, and other runtime modules from experimental to stable. It also adds multi-run evaluation, semantic tool-argument matching, Microsoft Teams and OpenAI Decisions integrations, and improvements for long multi-turn workflows.
The release changes more than API labels. RunSkillScriptTool now receives validated paths and arguments rather than a free-form shell command, closing a path by which a prompt-injected model could execute arbitrary shell commands. Google also reports that a 30-node, 200-turn workflow ran 23% faster with 9% lower peak memory.
There are operationally significant compatibility changes. Enum-annotated tool parameters now arrive as enum members; promoted features can no longer be disabled through the former feature flags; and sessions written by FirestoreSessionService in 2.14 cannot be read by 2.13 or earlier. These are Google’s reported release details and measurements. The production conclusions below are Ineeza analysis.
“Stable” is an API promise, not an isolation proof
LocalEnvironment, E2BEnvironment, DaytonaEnvironment, and the shared environment toolset now expose stable interfaces. The same interface can still sit over materially different trust boundaries: local processes, remote sandboxes, container images, network policies, credential delivery, filesystem persistence, and teardown guarantees.
Ineeza analysis: qualify each environment implementation as a capability profile, not as an interchangeable backend. Record image or runtime identity, effective user, mounted data, secret path, outbound destinations, resource ceilings, file-retention rules, and termination authority. Run the same conformance suite against every allowed backend, including prompt injection, network denial, process escape attempts, timeout, orphan cleanup, and evidence capture. A stable adapter should mean predictable control semantics, not only compatible method signatures.
Safer arguments still need independent authorization
Replacing a model-generated shell string with validated script paths and structured arguments removes an important command-construction hazard. It does not prove that the selected script, target file, argument value, or business action was authorized for this agent and this task.
Ineeza analysis: bind every executable skill to an immutable manifest containing its digest, allowed interpreter, argument schema, filesystem scope, egress policy, credential class, and approval requirement. Resolve and validate paths outside the model, reject traversal and symlink escapes, and emit a decision record before execution. Keep the runtime sandbox and business-policy engine independent of the agent framework so a parsing mistake or framework upgrade cannot grant authority by itself.
Multi-run evaluation needs statistical and policy boundaries
ADK can now run each evaluation case multiple times, in parallel, and combine scores or pass rates. ToolArgsMatcher can compare arguments exactly, case-insensitively, with numeric tolerance, or through an LLM-backed semantic check. These features make nondeterministic systems easier to test, but different matching modes answer different assurance questions.
Ineeza analysis: use exact matching for security principals, destinations, asset identifiers, monetary values, policy versions, and irreversible actions. Reserve semantic matching for fields where equivalence is explicitly safe and retain the matcher model, prompt, and verdict as evidence. Define sample count and acceptance thresholds from the consequence of failure; report distributions and worst cases rather than only an average pass rate. Pin model, tool fixture, policy, dataset, and environment versions so a release gate can be reproduced.
Upgrade and rollback must be designed together
The release includes breaking tool-argument behavior, removes disable controls for promoted features, and introduces Firestore session writes that older versions cannot read. A deployment can therefore appear healthy until a tool receives a changed type, an emergency feature shutdown is attempted, or operators roll back while new-format sessions remain active.
Ineeza analysis: canary the framework with recorded traffic and explicit assertions for tool inputs, session serialization, feature availability, and telemetry. Gate session readers and writers by schema version, preserve a tested downgrade or forward-repair path, and stop mixed-version workers from claiming incompatible sessions. Replace removed framework feature flags with controls at the deployment, routing, or policy layer. Rollback readiness is part of the release acceptance test, not an assumption made during an incident.
A2A discovery is not agent trust
The A2A integration is now stable and the CLI can generate an agent card. That can standardize discovery and interoperability, but a card describes an endpoint and capabilities; it does not establish which organization operates it, what authority it should receive, or whether a particular task result is safe to accept.
Ineeza analysis: authenticate the remote workload, bind its card and protocol version to an approved identity, and authorize every task by action, resource, tenant, and expiry. Correlate delegation, progress, cancellation, artifacts, and terminal state under one durable task identity. Treat remote output as untrusted input until its provenance and policy checks pass, and test cancellation and duplicate delivery across network failure. Interoperability expands the control surface as well as the integration surface.
Ineeza’s view
ADK 2.14 matters because it moves several building blocks that production agent teams need—sandbox adapters, inter-agent communication, and nondeterministic evaluation—behind stable interfaces while also exposing the costs of treating a framework version as a simple library update. The correct production unit is the whole runtime contract: environment capabilities, executable authority, evaluation policy, session schema, interoperability identity, observability, and rollback. Teams should promote that contract through environments together and require evidence for each boundary before accepting the framework’s stable label as operational readiness.