Google ran Gemini 4 Argon unattended for 11 hours against its own Agent Development Kit and accepted two performance optimizations into the codebase. Session preparation in memory became about 40% faster in long sessions, while cold package import time fell by 21%. The result matters because it shows an agent working across an existing large project rather than generating code from scratch.
How the overnight run on the ADK codebase worked
The target was a Python codebase of more than 200,000 lines across approximately 800 files, covered by nearly 17,000 unit tests. Google engineers framed the task as a test of how the model handles an existing codebase, which they describe as harder than building greenfield applications from an empty folder. Performance work was chosen deliberately, since slowdowns rarely sit in the file where symptoms appear. The run therefore required the agent to keep a map of the whole system over a long period.
The team first made a short trial run to learn what the prompt had to contain for the agent to follow unit testing and benchmarking conventions. Repository-specific rules were then written into. agents/skills files, described as an onboarding guide for a new engineer. The agent was told to load only the skill needed for the task, preserving space in the context window. The final prompt was executed in Antigravity with /goal mode, a setting intended to keep the objective intact through context compaction.
According to Google, the logs showed a complete working cycle: the agent read the repository guidelines, set performance baselines, proposed optimizations, reviewed its own changes, and ran all 16,892 open-source unit tests. The accepted changes filtered session events before copying them and added lazy loading so heavy packages load only when needed. Google contrasts this with a profiler, which reports that session copying and package imports take time but does not trace callers, mock targets, and shared references across 40 files. That cross-module checking was meant to keep faster paths compatible with existing applications.
What the 40% and 21% gains mean for agent projects
For companies running agents with multi-tool interactions over dozens or hundreds of iterations, small framework savings compound across turns. Google cites a 158-turn run of tool-calling interactions where the changes cut total time from 65.6 seconds to 56.1 seconds, removing nearly 10 seconds of framework overhead. Individual savings of 28 ms or 78 ms are invisible on a single LLM call lasting seconds. In long sessions that repeat session preparation many times, the 40% reduction in copying overhead changes throughput and operating cost.
The same logic applies unevenly by company size and workload. A small team with short agent runs and few tools may not notice faster cold imports or session handling, since model latency dominates. A larger operation with long-running assistants, repeated session state copies, and heavy dependencies gains more from the 21% import improvement and lazy loading. The decision point is workload shape: session length, number of tool calls, and how often processes restart determine whether framework overhead is worth optimizing.
Four other modifications from the same run were rejected after developer review over reliability, maintainability, compatibility, or measurable benefit. That outcome leaves verification work with people, including PR review, debugging, and testing. Before treating such agent output as production-ready, teams should ask for baselines, benchmark method, test coverage, and a list of affected callers and mocks. The marker to watch is whether future agent-proposed changes pass the full unit test suite and human review without rework, and how many are accepted per run.
