Splitting the context window

Why two specialized coding agents with a precise handoff between them beat one agent that holds everything in its context window.

For six months I used Claude Code for everything, from architecture to tests. It was good at most of that. Then Google shipped Antigravity and I started using it for the part Claude was mediocre at, which was mostly UI and visual layout1.

1Launched in November 2025 as an agent-first development platform, with a Manager Surface for spawning parallel agents and agents that work across the editor, the terminal and a browser; free for individuals during the public preview, with Gemini 3 Pro, Claude Sonnet 4.5 and GPT-OSS as models. Google, Build with Google Antigravity, our new agentic development platform, Google Developers Blog, November 2025.

Antigravity is worse than Claude Code overall and better at that specific thing, and in software engineering being better at one thing is all you need to justify a separate tool. This is a thread about why.

The monolith problem

When you ask a single agent to do everything, from research to validation, you are making a familiar architectural mistake. You are building a monolith.

Monoliths work. For a while. They are easy to reason about because everything lives in one place. But they have a ceiling, and the ceiling is the context window.

An agent that switches from architecture to pixel-level UI decisions and back is doing the cognitive equivalent of a context switch in an operating system. Every time it crosses a boundary between concerns, it pays a tax. Relevant earlier context falls out of attention, and the quality of each domain degrades in proportion to how many domains share the same window.

Inside a transformer this happens literally. Attention is a finite resource1. The more unrelated concerns compete for it, the worse each one gets served.

1The self-attention mechanism computes a weighted sum over all tokens in the context. As the context fills with heterogeneous concerns, the model's capacity to attend to what matters for any single concern decreases. The math is quadratic, but the practical failure mode is simpler: the model just starts forgetting your earlier instructions.

The specialization argument.

A single agent with a 200k context window holding everything from architecture decisions to validation rules is overloaded. Each concern dilutes the others. The context window works as an attention budget, and you are spending it on everything at once.

Two agents with 100k windows each, one holding architecture and logic, the other holding UI specs and design system rules, will outperform the monolith. They have the same total context; what changes is that each token of it is relevant to the task that agent is performing.

This is the same reason microservices beat monoliths at scale: specialization lets each unit optimize for its actual job without being distorted by concerns that belong somewhere else.

What each tool is actually good at

I have used both tools daily for three months. Here is what I observed, marketing aside.

Claude Code is a terminal. It reads your entire project and holds architectural context across sessions via CLAUDE.md. It modifies files with surgical precision and reasons about codebases as interconnected systems. It is excellent at anything that requires understanding how pieces fit together, a migration path or a bug that crosses file boundaries. Its weakness is spatial. It cannot see. Ask it to build a dashboard and you will get structurally correct HTML that looks like it was designed by someone who has never used a computer1.

1This is unfair. It is getting better. But the fundamental limitation is that language models operating on text tokens have no spatial reasoning loop: they cannot look at their output and iterate on what they see.

Antigravity is a cockpit. Its Manager Surface lets you spawn multiple agents across separate workspaces, each with its own context, each working in parallel. One agent can work on the frontend while another works on the backend, both visible in a single dashboard. Its agents can also control a browser and screenshot their own visual output to check it. The feature that changes the equation is that an agent that can see what it built can iterate on what it sees. But Antigravity's understanding of existing codebases is shallow. It generates well. It does not integrate well. Hand it a project with 200 files and non-obvious conventions and it will produce beautiful components that do not fit.

The gap is obvious. Claude Code understands your project but cannot visualize. Antigravity visualizes but does not understand your project. Alone, each produces incomplete work.

The communication pattern

Telling people to use both tools is trivially true and trivially unhelpful. What makes multi-agent work is that the quality of the handoff between agents determines the quality of the output. The shared context between them is the bottleneck, more than the agents themselves.

Here is the minimal architecture:

Claude Code researches, analyzes, and produces a specification: file structure, data models, component contracts, naming conventions, constraints That specification becomes a shared artifact (a JSON file, a markdown doc, whatever; the format matters less than the precision) Antigravity reads the spec and generates UI components within those constraints Claude Code receives the generated components and integrates them: wiring logic, adjusting imports, connecting to the actual data layer A validation step (automated or manual) catches the gaps

Why the spec is the hard part.

Steps (a) and (b) are where most people fail. They hand Antigravity a vague description (build a dashboard for this data) and wonder why the result does not integrate. A vague handoff produces components that look right in isolation but assume a different data shape or a different state management pattern than what your project actually uses.

The spec needs to contain:

The exact props each component receives, with their data types

The exact file paths where components will live

The CSS conventions already in use

Anything the generating agent would otherwise have to guess

Every guess is a potential integration failure.

Human teams work the same way. A senior architect who writes a two-page spec and hands it to a frontend developer gets better results than one who asks for a settings page and leaves. The quality of the delegation determines the quality of the result. AI agents are no different. They are just faster at executing bad instructions.

Three levels of integration

The two tools can be wired together at three levels, and most people go through them in this order.

Manual handoff

You run both tools. You copy context between them manually. Claude Code writes the architecture and you paste the relevant decisions into Antigravity's prompt. Antigravity generates components, and you paste them back into your project for Claude Code to clean up.

This is where you start. It works for small projects and prototypes. The overhead is manageable because you are the router: you decide what each agent needs to know, and you filter out the noise.

Orchestrated workflow

You define explicit handoff points. Claude Code writes a specs.json after the architecture phase. Antigravity reads it. Claude Code integrates the output. You review at defined checkpoints.

This is where the real value appears. The spec file becomes a contract between agents. You refine it over multiple projects until it captures exactly the information the downstream agent needs and nothing more. This takes maybe 30 minutes to set up per project type, and it is reusable.

Automated pipeline

Agents communicate through shared files with no human in the loop between phases. Claude Code writes specs and Antigravity generates from them. Scripts validate the result, and a human reviews only the final output.

This is where most people think they want to be. Most people are not ready for it. Automated pipelines require that your spec format is precise enough to eliminate ambiguity, and ambiguity is what humans are best at resolving. I would not recommend this unless you have run the orchestrated workflow at least twenty times and your specs have converged to a stable format.

The autonomy trap.

Antigravity can give agents significant autonomy: in its Turbo mode they run terminal commands without asking. Developers have reported agents issuing destructive system commands, and in the best-known case a request to clear a project's cache ended with the whole D: drive wiped1. Claude Code has guardrails for this, hooks and permission tiers among them. Antigravity is still catching up. If you are running agents in parallel with filesystem access, you need to understand exactly what each one is allowed to do before you press start.

1Reported in Google's Antigravity AI deleted a developer's drive and then apologized, TechRadar, December 2025.

When this does not work

Multi-agent is not always the answer. There are three cases where the overhead exceeds the benefit:

SMALL PROJECTSIf the entire codebase fits in a single context window with room to spare, splitting work across agents just adds communication overhead. A monolith works fine when the monolith is small.

TIGHTLY COUPLED LOGICIf the frontend and backend are deeply interleaved (websocket handlers that mirror client state, say, or shared type definitions that change constantly), the spec file becomes so large and so frequently outdated that it costs more to maintain than it saves. The agents need to share a context because the concerns cannot be cleanly separated.

ONE-SHOT TASKSIf you are building something once and never touching it again, the setup cost of multi-agent orchestration is not amortized over anything. Just use whichever tool is closest.

The compounding value of multi-agent shows up when you build the same kind of thing repeatedly, a dashboard pipeline, say. The spec format stabilizes, and the human time per project drops from hours to minutes. Before that, you are just adding complexity.

The actual reason this matters

Claude Code and Antigravity will both change, and new tools will appear. The principle outlives them: the right unit of AI-assisted work is a team of specialized agents with a well-defined communication protocol, rather than one omniscient agent. The idea is old. It is the Unix philosophy applied to AI (do one thing well, and compose), and the same division of labor every organism more complex than a bacterium runs on.

The reason it took this long to become practical is that until recently, the communication protocol between AI agents had to be a human copy-pasting text. That bottleneck is dissolving. Agents now hand each other files and structured output, and skills can encode the handoff logic. The plumbing is finally catching up to the architecture.

We are not at the fully automated pipeline yet. We are somewhere in the middle: human-in-the-loop orchestration, with the loop getting shorter. The developers who learn to design that loop well now will have a significant advantage when it tightens further, because what they will be designing is the specification, and that has always been the hard part.