Google’s AI Agent Problem Is Not Tools. It Is the Work Loop

Google should be unusually hard to beat in AI agents. It owns a leading model family, a cloud runtime, a browser, a mobile operating system, a productivity suite, a search product and an identity estate. Most companies trying to sell agents would be delighted to possess even two of those pieces. An agent that can reason over a Workspace document, inspect a Cloud project, operate a browser, execute in a sandbox and hand a reviewable result back to a developer is an obvious Google-shaped product.

That is why the present result is so disappointing. Google has tools. It has an agent platform. Yet its agent experience can feel like a fast assistant wearing an operator’s uniform: it sees enough to make an early move, writes a plausible answer or patch, and then stops before the hard part—checking the surrounding material, pursuing the consequences, recovering from a failed attempt and proving that the job is actually finished.

This is not a complaint that an agent produces answers quickly. Speed is valuable once a task is understood. The complaint is premature completion: the model mistakes the first credible route for the complete route. It reads a few files rather than building a working model of a codebase; it takes the first search result rather than testing competing evidence; it edits the obvious function rather than following the data flow; it reports success because a command exited cleanly rather than because the intended behaviour was demonstrated. Long thinking is not a theatrical stream of hidden tokens. In agent work, it is sustained, observable effort: inspect, hypothesise, act, test, learn, revise and only then stop.

That distinction matters more than a feature checklist. Google’s current Antigravity documentation describes a substantial stack. A plugin can package skills, background subagents, linting rules, MCP definitions and event hooks ^[3]. Its managed agent can provision a Google-hosted Linux sandbox, run code, manage files, search and fetch the web, use custom functions and remote MCP servers, and intercept code or filesystem activity with synchronous hooks ^[4]. Those are real capabilities. A rich harness, however, cannot compel a model to stay with an ambiguous problem long enough to use them well.

The comparison here is deliberately narrow: Google Antigravity, OpenAI Codex, Anthropic Claude Code and DeepSeek Harness as systems for delegated technical work. They are not identical products, and no single score establishes a universal winner. The model, harness, prompt, tool permissions, timeout and task distribution all affect a result. But independent tests and the everyday behaviour of these systems point to the same operational question: which agent keeps working usefully when the first answer is not enough?

Google’s agent problem is an impatient work loop

Google introduced Antigravity in November 2025 as an agentic development platform rather than merely an editor. The announcement described agents that could plan, execute and verify work across an editor, terminal and browser, with a manager surface for long-running tasks and review artifacts such as plans, screenshots and browser recordings ^[1]. It had the right vocabulary. The gap is between the word verify and an agent that genuinely keeps iterating until verification means something.

Google’s managed Antigravity documentation names gemini-3.7-flash as the default model for its preview agent, while allowing the caller to choose another Gemini model through agent_config for speed, cost or reasoning capability ^[4]. That is a reasonable product control, not proof that Flash is inherently incapable. But it creates a revealing default: the standard path optimises a general-purpose, fast agent loop, while thoroughness becomes a choice the operator must know to make, configure and pay for. A platform that wants to own difficult delegated work should make persistence, verification budget and escalation to a deeper model part of the default task contract.

The documented API also supplies automatic context compaction around 135,000 tokens ^[4]. Compaction is necessary for long work, but it is not long-horizon competence. A compressed session can still lose the hypothesis it was testing, forget why a failed attempt mattered, or shorten its plan to fit a convenient summary. The real question is whether the agent carries forward a tested task state: what it has inspected, what it changed, which evidence conflicts, what must be tried next, and which condition would permit it to stop. Google’s documentation describes the tools; it does not establish that the default agent reliably maintains that disciplined loop.

There is early comparative evidence that this concern is not simply aesthetic. CCBench evaluates coding agents on roughly 180 tasks in small codebases drawn from private user submissions, aiming to reduce public-repository training exposure. Its February 2026 results reported 75.4 percent success for Codex CLI with GPT-5.2-codex, 72.7 percent for Claude Code with Opus 4.6, 51.3 percent for Gemini CLI with Gemini 3 Flash Preview and 47.6 percent for Gemini CLI with Gemini 3 Pro Preview ^[12]. The same page notes that the Gemini 3 Pro Preview configuration exceeded the 20-minute timeout on about a quarter of tasks ^[12]. This is not an Antigravity benchmark and should not be read as a timeless model ranking. It is, however, a native-agent comparison in which Google’s then-current agent configurations were materially behind on unfamiliar real-world code tasks.

Longer tasks make the standard harsher. Horizon-SWE places agents in a production-grade environment with a running application, live traffic and 73 engineering tools, then asks them to gather information, implement, test, deploy, monitor and respond to incidents. Its reported pass rates were low across the board: 25.5 percent for Claude Opus 4.6, 19.1 percent for Gemini 3 Pro, 18.0 percent for GPT-5.2 Codex and 16.7 percent for Gemini 3 Flash ^[13]. This is model-and-harness research rather than a direct product shootout, so the ordering should not be over-read. Its useful result is qualitative: Google’s models do not gain a long-horizon advantage merely because the task comes with more tools. The hard part is feedback control after the first plan meets reality.

That conclusion is broader than Google. Long-Horizon-Terminal-Bench reports that demanding terminal workflows require hundreds of episodes, millions of tokens and minutes to hours of execution; even its strongest tested configuration reached only 15.2 percent success at a demanding reward threshold ^[14]. Its analysis distinguishes incomplete progress caused by timeout from premature stopping and weak self-verification ^[14]. Those are exactly the failures a human sees when an agent moves briskly through material and reports a partial answer as a finished deliverable. Google is not alone in this class of failure. It is the vendor most exposed to it because its platform rhetoric promises the full delegated workflow.

A harness should be judged at the point of persistence

The useful test is not whether a product can edit a file in a demo. All four can reach a version of that capability. The test is what happens when the agent needs information it does not have, hits a failed test, encounters conflicting evidence, delegates work, or needs to prove that its task is done. Does it investigate, verify and continue—or does it convert uncertainty into a polished stopping message?

Model Context Protocol matters here because it turns “connect this agent to our tools” into a portable systems problem rather than a separate proprietary integration for each model. MCP describes itself as an open standard for connecting AI applications to external systems, including data sources, tools and workflows ^[11]. Support for MCP is valuable, but it is only the connector. The hard question is whether the client makes authority, approval, observability, failure and configuration manageable after the connector is installed.

This is a capability map, not a benchmark ranking. “Strong” here means that the vendor’s published design makes a particular operational promise concrete. It does not mean that every model call succeeds or that every deployment is safe.

Codex makes continued execution easier to supervise

Codex’s advantage is not that its users never need to configure it. It is that the product increasingly exposes configuration as a first-class part of the agent rather than treating it as incidental terminal plumbing. Official OpenAI documentation places Codex across a CLI, IDE extension, cloud environment and desktop surfaces, then separately documents agent configuration, subagents, rules, skills, plugins, hooks, MCP, sandboxing, approvals, network access, code review and enterprise administration ^{[6, 5]}. That is a large surface, but it is recognizably one control plane.

The important promise is that a team can give the agent a bounded environment, make routine low-risk work fast and stop higher-risk work for review. In practice, that requires real policy work: a sandbox is not a substitute for least-privilege credentials, and a review screen is not proof that a patch is correct. Still, the system’s centre of gravity is operational. It asks: what may this agent do, where, under which approval rule, with which tools and evidence? That framing matters when a task goes wrong. A user can require more work, keep the session and its state alive, examine the evidence, and make a consequential action a visible control point rather than a reason for the model to declare victory.

That makes Codex a tougher competitor for Google than a model leaderboard suggests. Google can match a shell, a sandbox or an MCP configuration. It must also show that the agent running inside those tools knows when a task is unfinished. Codex’s documentation breadth is not independent proof of model superiority, but it gives a buyer a legible map of the machinery used to extend, inspect and govern a difficult run.

Claude Code’s advantage is programmable intervention

Claude Code takes a more terminal-native route. Anthropic documents an interactive CLI as well as non-interactive execution, session continuation, output formats, tool allow and deny lists, permission modes and explicit limits on agentic turns ^[7]. Those are not glamorous features. They are the controls engineers need when an agent moves from “help me understand this repository” to “run this repeated workflow in CI.”

Its hook and subagent materials deepen that claim. Hooks provide lifecycle points at which a team can run deterministic commands or other handlers around agent actions; custom subagents create separately configured workers rather than merely asking one chat session to imitate multiple roles ^{[8, 9]}. This does not make Claude Code automatically safe. Hooks are executable extension code, and extension systems demand review. It does make intervention an explicit design object.

The contrast with Google is revealing. Antigravity also documents hooks, plugins and subagents. The question is not which page has more nouns. Claude Code has spent longer teaching developers how to compose the nouns into a workflow: permission mode, an allowed tool, a project-level MCP configuration, a hook, a separate worker and a resumed session. That composition makes it easier to force a difficult task back into evidence gathering and testing rather than accept a model’s first declaration of completion. Google’s tooling will become formidable if Antigravity treats that sustained loop—not just task dispatch—as the central product behaviour.

DeepSeek Harness shows what Google has not yet made visible

DeepSeek Harness is the odd system in this comparison. It is explicitly a developer preview, and DeepSeek warns that its core plugins and APIs will continue to evolve ^[10]. It therefore should not be presented as the conservative enterprise default. Its weakness is forthright: users are accepting an evolving open-source substrate and the engineering burden that comes with it.

Yet it exposes a valuable counterexample to Google. DeepSeek says every major capability—models, tools, skills, sessions, sandboxes, storage, loops, scheduling and the UI—is a plugin that can be selected, swapped or extended ^[10]. It documents several runtime modes and an append-only session log that records system prompts, tool calls, results, subagent scheduling and context injection, with replay and fork operations over the same event stream ^[10]. Whether a team wants that much openness is a separate decision. But it can inspect what the harness is made of.

Google has the capacity to offer both a polished managed product and a deeply programmable substrate. Its present weakness is that Antigravity still reads as a set of capable surfaces around an impatient default loop. DeepSeek makes an unavoidable question visible: when an agent stops too early, which part failed—the model, the context policy, the tool loop, the stopping condition, the verifier or the task state? A user can inspect and replace those layers in DeepSeek Harness. Google needs to make them equally legible, then demonstrate that Gemini can use them to keep working when the first answer fails.

The verdict: tools amplify the work loop they are given

Google’s agent tools are weak relative to Google, not relative to a blank page. The company can host the runtime, ground the agent in search, connect it to enterprise systems and distribute it through developer surfaces few rivals can match. Antigravity’s combination of sandboxed execution, filesystem work, web access, custom functions, MCP and synchronous hooks is a credible technical foundation ^[4]. The mistake is to take that foundation as evidence that Google has solved delegation.

It has not. The decisive gap is that Google agents do not yet consistently feel willing to do the slow work. They can move quickly through a repository or research packet, produce a tidy plan and make an initial change. Too often, however, they stop at the first locally plausible conclusion. That is particularly damaging in long-form research, software maintenance, incident response and enterprise workflows, where a partial completion is worse than an explicit “I need to investigate further.” A fast incomplete agent increases review load while creating the appearance that review is no longer necessary.

Google’s product transitions make this harder, not easier. Its May 2026 migration notice says Antigravity CLI would not initially have one-to-one parity with Gemini CLI, even while retaining critical skills, hooks, subagents and extensions ^[2]. The lesson is not that a renamed CLI is the core problem. It is that Google must stop treating capability nouns as the outcome. A hook does not create a persistent researcher. An MCP server does not create a careful engineer. A sandbox does not create a model that knows it has not finished.

The immediate recommendation for teams is not “avoid Google.” It is to evaluate Antigravity against a work-loop protocol rather than an impressive demo. Give every candidate agent the same ambiguous, multi-step task; require it to state what evidence would let it stop; allow it to revise its plan after failed tests; record the number of files and sources it inspected; and score the final result only after an independent verifier has checked it. Test the same protocol in Codex, Claude Code and DeepSeek Harness. Keep project instructions and acceptance tests vendor-neutral, and put high-consequence authority in CI, IAM and secret-management systems rather than an agent prompt.

For Google, the path out is direct. First, make a high-effort, long-horizon mode explicit and easy to select, with a documented continuation budget rather than an ambiguous promise of agentic reasoning. Second, make task state durable: hypotheses, attempted actions, failed tests, unresolved questions and stop conditions should survive compaction and be inspectable by the user. Third, make verified completion—not a fluent final message—the default terminal condition. Fourth, expose the model escalation and verifier policy in the same place as tool permissions. Finally, provide a compatibility contract for skills, hooks, subagents and plugins so teams can improve the loop without rebuilding it at every product transition.

Prediction, with a twelve-month horizon: Google can reverse this judgement if Antigravity demonstrably sustains difficult work better than its current default experience. Observable indicators would include a non-preview long-horizon model route, explicit effort and continuation controls, task-state and verifier artifacts that survive compaction, and independent evaluations in which Google’s native agent closes the gap on unfamiliar multi-tool tasks. This prediction is falsified if Google adds more tools and interfaces while users still observe the same pattern: rapid scanning, an early answer and a stop before the work has earned completion.

Google does not need another agent demo. It needs agents that linger productively in uncertainty. Codex, Claude Code and DeepSeek Harness each make a different part of that discipline more visible: governed execution, programmable intervention and inspectable composition. Until Google makes sustained thinking and verification as real as its tool menu, it will remain the company with the most obvious ingredients and the weakest agent experience.