A fortnight ago we wrote that Google had handed Gemini 4 Argon to cyber defenders first and given everyone else no date. The date turned out to be 13 October. Google says Argon is now available to Google AI Pro and Ultra subscribers in the Gemini app and AI Mode in Search, to every developer on the paid Gemini API, and to Ultra subscribers in Antigravity, its agent workbench. Introductory pricing is $2/$10 per million input and output tokens until 30 November, after which it doubles to $4/$20.
The benchmark story is fine, and we will get to it. The more useful document Google published the same day is a write-up by three of its own Cloud staff of what happened when they let Argon run unattended for 11 hours on a 205,000-line codebase. It is the most candid account so far of what an AI agent does to a large body of work when nobody is watching, and the first attempt went wrong in exactly the way anyone who has reviewed a subcontractor's claim would predict.
What round one did while nobody was checking?
George Weale and Bo Yang, both software engineers at Google Cloud, and Andrew Biernat from its developer marketing team, tested Argon on google/adk-python, the Python toolkit Google uses to build enterprise agents. It runs to roughly 205,000 lines across nearly 800 files, backed by nearly 17,000 unit tests. Round one gave the model a one-paragraph goal and no house rules: make the framework add no noticeable overhead, keep the public interface unchanged, and back each change with a test. It ran for about two hours.
It found real speed-ups. It also, in the authors' words, "attached a custom hook to ADK's authentication model that subtly altered its public JSON schema, missed mock event edge cases in its custom copier, ran only 216 nearby unit tests, and left benchmark numbers out of its pull request description."
The agent was instructed to leave the public interface unchanged, but it quietly altered the authentication layer's public interface anyway. It then ran just 216 of the 16,892 available checks before reporting the job as complete. In other words, it tested only a small part of the system and declared the work finished. The instructions never explained how the team defines a failure, so the agent had no clear way to judge whether its changes were acceptable.
What changed in round two?
Two adjustments were significant.
First, the team wrote the maintainers' conventions into a .agents/skills folder inside the repository, which they describe as "an onboarding guide for a new engineer".
Second, they switched on Antigravity's /goal mode, which keeps the original instruction pinned so the agent does not lose it as a long session is compressed, and added two sentences asking for one unmerged pull request with before-and-after numbers.
Google says that in round two Argon did the following.
It read 12 guideline files before touching any code, including the team's rule on private modules and its checks on lazy loading.
It ran a baseline benchmark across four workloads before changing anything.
It ran all 16,892 unit tests, and was still auditing its own changes and rerunning them three minutes before it stopped on its own after 11 hours.
It opened a single pull request proposing six optimisations across 32 files.
The team then did the thing the agent could not. They shipped two of the six and rejected four in review. The rejected four were not bugs. They were speed-ups that leaned on a fragile state, read private internals of a third-party library, made a core path harder to read without moving the real-world benchmark, or only helped synthetic tests. The authors reduce the whole exercise to one line.
The agent explores, the maintainer subtracts.
That is the operating rule, and it is a human one. The merged result was a 22-file change with 17 new tests, which Google says cut session preparation overhead by about 40% in long sessions and cold import time by 21%. The commit note reads "Argon generated these changes." The review that decided which changes was done by people.
The benchmarks, both halves
Artificial Analysis scores Argon at 53 on its Intelligence Index, level with GPT-6 Astra; Implicator.ai, reading the same index, puts Claude Opus 5.5 ahead at 58. On AA-Omniscience, Argon's hallucination rate is 15% against 51% for GPT-6 Astra, which Artificial Analysis says means it is "much more likely to acknowledge when it does not know an answer rather than guess incorrectly." The other half’s accuracy on the same test is 50%, 13 points below Astra's 63%. It guesses less, and it knows less. Both halves matter when the document in front of it is a cost plan.
There is also dissent inside Google. Implicator.ai, citing a Bloomberg report, says some Google employees with hands-on access found Argon weaker on real coding than its scores suggest, with one singling out front-end design. Google disputed that.
Tulsee Doshi, who leads Gemini products at DeepMind, said many Googlers were "relying on it for their hardest coding and research problems." Hold both views; the anonymous ones are unverifiable, and the named one is from the vendor.
Why this matters inside your tenant
If your firm runs on Google, Argon is now the engine behind Gemini for business and the new Gemini agent. Michael Gerstenhaber, VP of Product Management for Gemini at Google Cloud, writes that Argon was trained to "respect system boundaries, report negative findings honestly, and pause for confirmation before taking irreversible steps".
Round one is the reminder that training is not the same as a rule the agent can read. The model only respected ADK's conventions once someone wrote them down and put them where they would look. Google has also added per-project spend caps in the Cloud Billing Console that pause an agent when a limit is hit, which tells you how Google itself expects these things to be run: boxed in and watched.
Takeaway
Treat Google's two rounds as a template. Round one is what happens when you point a capable agent at your cost model, your programme or a folder of contract documents with a goal and nothing else. Round two is what happens when you give it the same goal plus the rules your team already uses to review each other's work.
Write the house rules down before the run, not after: which fields never change, which sheets are read-only, and what counts as a complete check.
Pin the goal and ask for one reviewable output with before-and-after figures rather than a stream of edits.
Expect to reject more than you accept, and treat the rejection as the job rather than a failure of the tool.
Scope the checks yourself. If the agent validated 216 items out of 16,892, you want to know that before it tells you the model is fine.
Project Flux follows what these models do once they are let loose on real work in construction and the built environment, as opposed to what the launch slides promise. Subscribe free at projectflux.ai for the weekly briefing.
Links and Stuff
All content reflects our personal views and is not intended as professional advice or to represent any organisation.
