An 11-hour coding-agent run produced six proposed optimizations for Google’s Agent Development Kit. Human reviewers shipped two and rejected four, including a cache with a stale-data risk and a rewrite that failed to improve a held-out benchmark.
That review process is the most useful part of Google’s ADK case study, published October 13, 2026. Google reports that the accepted changes reduced in-memory session preparation overhead by about 40% in long sessions and accelerated cold package imports by 21%. Those are improvements to specific framework operations, not evidence that entire agent applications became 40% faster.
The case study describes Gemini 4 Argon working inside Google Antigravity on ADK’s Python repository, which Google says contains roughly 205,000 lines across nearly 800 source files. Its practical contribution is a workflow: supply repository-specific instructions, preserve an explicit goal, establish benchmarks, run the full test suite and keep merge authority with maintainers.
The First Attempt Found Bottlenecks but Missed Maintainer Rules
Google first gave Argon an outcome-oriented prompt without custom repository instructions. The objective was to remove noticeable ADK overhead across startup, long sessions and multi-agent workflows while preserving the public API and what the model receives. Changes also needed regression tests.
That roughly two-hour attempt did useful investigation. According to Google, Argon spent 70 minutes measuring and reading code before editing ADK source, identifying bottlenecks in session copying and package imports. Some code from this attempt survived into the shipped change.
The failures were more specific than simply writing incorrect code. An authentication-model hook subtly changed a public JSON schema despite the compatibility requirement. A custom copier missed mock-event edge cases. The agent ran only 216 nearby unit tests and omitted benchmark results from its pull request description.
This distinction matters for teams evaluating coding agents. Finding a real bottleneck did not make the resulting patch acceptable. The agent also needed to understand the project’s compatibility boundaries, testing expectations and evidence required for review.
A broad instruction to preserve the API had not supplied enough operational detail to enforce those requirements.
Repository Skills Made the Acceptance Criteria Concrete
For the second attempt, Google put maintainer guidance in .agents/skills. Each skill used a short SKILL.md index pointing to focused files under references/, allowing the agent to retrieve detailed guidance when needed rather than loading every rule into context at once.
Google reports that Argon read 12 guideline files before changing source code. These included rules for private, underscore-prefixed modules and checks governing lazy imports.
The team also enabled /goal mode in Antigravity. Google describes this as preserving the objective across context compactions, when accumulated working context is condensed during a long session. The revised instruction required one pull request against main, before-and-after measurements in its description and no merge.
Those additions addressed different problems. Repository skills supplied project-specific constraints. The persistent goal kept the intended outcome available over a long run. The pull request requirements defined a reviewable deliverable and reserved the final decision for humans.
This was not a controlled comparison isolating the effect of skills. The second run also used /goal, stronger delivery instructions and substantially more time. The evidence supports the combined workflow, not a claim that one directory alone caused the improvement.
For another repository, the transferable principle is to document the rules that routinely block otherwise plausible patches: compatibility promises, import conventions, required tests and benchmark expectations.
Full Tests Were Necessary, but They Still Missed a Breakage
Before editing source in the guided run, Argon established benchmark baselines covering package startup, a 200-step conversation, a 20-sub-agent handoff application and a 12-node workflow. Google reports 30 repetitions for the baseline workloads.
The agent also ran all 16,892 open-source unit tests. Near the end of the overnight session, it was still inspecting its diff, correcting a bug in its proposed multi-agent cache and rerunning the suite.
That was a substantial improvement over the first attempt’s 216 tests. Yet even the complete open-source suite did not establish compatibility everywhere.
One proposed import change passed all those tests but broke 25 internal Google test targets. Those tests patched attributes exposed by modules whose imports the agent had removed. The final implementation needed to retain those patch points while avoiding eager loading.
The lesson is that a complete repository test suite is a defined boundary, not proof that every downstream consumer remains compatible. Framework changes may require additional integration checks or knowledge of how consumers use module attributes.
Google also prepared a held-out benchmark before either run and kept it hidden from Argon. It grew a session turn by turn using an instant model and instant tools, isolating framework overhead rather than remote inference or tool latency.
This benchmark was independent of the agent’s optimization process, but not an independent external evaluation. Google designed, ran and reported the study.
The Shipped Changes Removed Work From Two Specific Paths
The first accepted optimization changed how ADK’s in-memory session service retrieved conversation history.
Previously, the service deep-copied the stored conversation before filtering it to the events the caller requested. Even listing sessions without their events could copy those events first. The accepted change filtered before copying and replaced a generic Pydantic deep-copy path with a specialized, cycle-safe copier that preserved shared state dictionaries and test mocks.
The important mechanism is avoiding unnecessary work. As a session grows, copying history that the caller does not need can consume increasing time. Filtering earlier reduces the amount of data that reaches the copying step.
The second accepted optimization deferred heavy imports. Google says import google.adk previously pulled in components for live audio and video, OpenTelemetry tracing and web servers, even for a basic text agent.
The shipped solution used lazy module accessors, loading heavy packages when needed while preserving attributes that downstream tests expected to patch.
After review, Google combined work from both attempts into a 22-file change with 17 new test functions and landed it in main.
The reported performance scope remains narrow: about 40% less in-memory session preparation overhead in long sessions and 21% faster cold package imports. Neither figure establishes a comparable improvement in total application latency. Model responses, tool execution and other work remain outside those measurements.
Reviewers Rejected Four Different Kinds of Weak Optimization
The four discarded proposals provide a useful checklist for reviewing agent-generated performance work.
- A multi-agent event cache had a correctness risk. Google reports a 17% gain on a synthetic benchmark, but the implementation relied on a weak reference that could return stale data across sessions if Python reused a memory address after garbage collection.
Sources
- Google’s ADK case studydevelopers.googleblog.com
