Agentic Engineering and the Outer Loop: Where Antigravity and Agents CLI Fit

The next stretch of AI development depends less on stronger models and more on stronger engineering systems. At Sequoia Ascent 2026, Andrej Karpathy described the industry moving from vibe coding toward agentic engineering. In that discipline, people write the specs, the evaluation loops and the guardrails, and agents take on bounded pieces of implementation.

The shift matters because AI doesn't replace software engineering discipline. It magnifies whatever discipline is already there. Google's DORA research and related platform guidance point the same way: organizations with solid engineering foundations get more out of AI-assisted workflows than those with fragile pipelines and weak verification. Adoption of AI development tools is wide, but trust is not. The limiting factor has stopped being the model and become the system around it: specifications, evaluations, the deployment pipeline and a governance layer. Agentic engineering is the practice of building that system.

What agentic engineering means

Put briefly, it's a structured way of doing AI-assisted development in which humans own architecture, quality and correctness, while agents handle bounded implementation tasks inside defined limits. Karpathy laid out three pillars.

Specifications first. Before an agent writes any code, the engineer states the objective, constraints and success criteria in a machine-readable spec. A structured contract between human and agent takes the place of a vague prompt.

Evaluation before trust. One successful run says nothing about reliability. Agents need to be run against structured evaluation datasets, scored with metrics and LLM-as-a-judge methods, so that performance is repeatable before anything is deployed.

Guardrails and sandboxing. An agent belongs in a secure sandbox with explicit permissions, tool hooks and policy gates, so execution can't run unchecked. Just 12% of enterprise AI agent pilots make it to production today, and models aren't mostly to blame. Infrastructure gaps are: no sandboxing, no secret scanning, no policy gates.

Where current coding tools stand

Any honest assessment begins by crediting what today's AI coding tools do well, and it's impressive.

They excel at inner-loop agentic work: breaking a task down, editing several files, running local terminal commands and correcting themselves from compiler errors. They've moved well past simple code generation and autocomplete.

The inner loop is only half of it, though. Enterprise teams no longer ask whether an agent can write and edit code, because in 2026 nearly every major tool can. The harder issue is the outer loop: how an organization evaluates, deploys, monitors and governs agents once they leave a developer's local terminal. That's where the discussion changes. The structural difference looks like this:

None of this faults the other tools. As engines for inner-loop execution, they remain among the best available. But code generation is only the starting line, and tools tuned for a developer's local terminal aren't natively built to manage the whole outer-loop lifecycle. Doing well in 2026 takes more than producing capable agents. It takes infrastructure for evaluating, deploying and governing them in production.

Agents CLI as the on-ramp

Google's approach rests on a single design decision. Agents CLI is intended to work alongside any coding assistant, and that's the architecture rather than a shortcoming. On installation it adds seven core skills built on the Agent Development Kit (ADK), spanning scaffolding, evaluation, LLM-as-judge scoring, runtime setup, Cloud Run deployment and Cloud Trace observability. A Claude Code or Cursor user can run agents-cli scaffold, agents-cli eval and agents-cli deploy with roughly the same ease as an Antigravity user.

That's deliberate. Google isn't competing at the code-generation layer. It's betting that the value in agentic engineering moves from the frontend, where code gets written, to the backend, where agents are run, watched and governed. And whichever frontend a developer picks, the CLI commands lead to the same place:

• agents-cli deploy targets Cloud Run, GKE or Agent Engine, which are all GCP.
• agents-cli observe sends telemetry to Cloud Trace and BigQuery, again GCP.
• agents-cli publish registers agents in the Agent Registry, also GCP.
• The governance layer, with Model Armor, Agent Identity and policy gates, runs on GCP too.

The CLI is the on-ramp, then, and GCP is where it ends up. Every coding assistant that adopts it turns into a GCP client for the production lifecycle. That's why "it works with Cursor too" supports the strategy instead of undercutting it: Google doesn't need anyone to switch editors, only to run production on GCP, and the CLI makes that the lowest-friction path for every tool.

Three concentric layers

The Google ecosystem is arranged as three nested layers. Each one adds capability, and none demands that existing tools be dropped.

The innermost layer is Agents CLI, compatible with Cursor, Claude Code, Codex, Copilot, Antigravity or whatever supports skill injection. It offers a standard way to scaffold a project (agents-cli scaffold), structured evaluation scored by an LLM judge (agents-cli eval), deployment to Cloud Run or GKE with a single command (agents-cli deploy) and automatic Cloud Trace observability setup (agents-cli observe). Missing from it are multi-agent orchestration, persistent context engineering and built-in verification loops. The pitch to users: keep the favorite editor, gain a repeatable route from prototype to production, and accept that production runs on GCP.

The cloud layer is required by any tool using Agents CLI, since it's where the agents actually run. It consists of:

• Cloud Run, GKE and the agent platform for scalable managed hosting
• Cloud Trace, for full execution-path tracing with OTel-compliant telemetry
• BigQuery Agent Analytics, for dashboards across a whole fleet of deployed agents
• Agent Registry, a central catalog for governing, versioning and sharing agents
• Model Armor, which prevents data leakage and filters unsafe content
• Agent Identity, with cryptographic IDs tied to verifiable human identities or service principals
• The Agent2Agent (A2A) protocol, for communication between agents when coordinating a fleet

The reasoning here is that standalone coding assistants generally depend on outside cloud infrastructure for production deployment, observability and governance and don't offer an integrated enterprise runtime. That's a structural point and not a competitive one. Claude Code doesn't compete with Cloud Run, since the two sit at different layers.

What Antigravity adds

If everyone has subagents and context files, what separates Antigravity? The answer isn't a single feature. It's vertical integration with the production layer.

Subagents in Claude Code work inside the terminal: they write code, run tests and produce output. Deploying that code, monitoring it live, governing a fleet of agents and coordinating agents across services all fall on the user, because Claude Code knows nothing about the Cloud Run instances, observability pipeline or governance policies in play. It's a development tool. Antigravity's subagents can do more:

• Deploy straight to Cloud Run, GKE or the agent platform through Agents CLI, because the CLI is first-party and not a third-party plugin.
• Query Cloud Trace telemetry while debugging, since Antigravity can read GCP observability data.
• Register finished agents in the Agent Registry, because publishing is a native workflow.
• Coordinate with deployed agents over the A2A protocol, since the communication layer belongs to the same ecosystem.

Claude Code's subagents are capable development tools, while Antigravity's are development tools aware of the production environment because they share a vendor stack. Four capabilities are claimed that other tools don't currently match:

1. Multi-surface continuity: one agent context spans the desktop IDE, the CLI, the SDK for programmatic use and the managed API. A workflow might start in the IDE, continue in the terminal and be triggered from CI/CD. Claude Code mainly lives in the terminal, while Cursor centers on the IDE.
2. First-party Agents CLI integration: scaffold, eval, deploy and observe were co-designed with Antigravity, so the agent knows the CLI natively and can chain lifecycle commands with no prompt engineering.
3. GCP-aware context. Agents can pull Cloud Trace data, Agent Registry entries and deployment metadata into their working context, so an agent chasing a production problem can read telemetry, review the deployed agent's configuration and propose fixes in one session.
4. Enterprise discoverability. Many custom agents stay isolated behind private endpoint URLs, reachable only by their builders and needing credentials shared by hand. A native publishing pipeline addresses that: telling the CLI to register an agent with Gemini Enterprise runs agents-cli publish, and the agent turns up as a secure, discoverable tool inside the Gemini Enterprise app across the organization. Native IAM governs access, and teams can use it without provisioning their own infrastructure.

Comparing ecosystems

To make the comparison concrete, the next table shows where the tools are equivalent and where they differ.

In the top half of the comparison, the three ecosystems converge architecturally, with good code generation, parallel subagent orchestration and managed cloud sandboxes for long-running tasks. The bottom half is where Google claims extra enterprise value. Competing platforms move code, data and credentials into proprietary third-party runtimes, whereas Google lets an organization execute, identify, authenticate, govern and monitor agents within its own Google Cloud perimeter via Agent Runtime, Agent Identity, Model Armor and Agent Registry. The separation shows up in production: GCP-native telemetry, a unified four-surface deployment harness and governance for models out of the box.

Fairly put, local inner-loop capability is converging, and the infrastructure layer is where vertical integration opens a gap.

How to decide

The decision framework for leaders and engineers is simple. A team mainly focused on speeding up the inner loop should stay with its current tools. Claude Code, Cursor and Copilot are excellent and keep improving monthly. Agents CLI can be added for its lifecycle capabilities, with deployment to GCP when the team is ready.

An organization moving from AI-assisted coding to agent-operated workflows faces different requirements. Fleet management, quality driven by evaluation, governance for regulated industries and multi-agent coordination call for another architecture, and Google is one of few vendors offering a vertically integrated stack from coding agents through evaluation, deployment, observability and governance.

The case doesn't depend on model superiority, since models are converging. It depends on infrastructure integration: the distance from writing agent code to operating governed agent fleets in production. Google has narrowed that distance further than anyone, whichever editor a team begins in.