Agent swarms and the new model economics · Cursor

Concept 1: What Is an Agent Swarm?

Think of a single AI agent like one very smart employee trying to build an entire skyscraper alone. They have to remember the blueprint, lay bricks, do plumbing, and manage everything simultaneously. They get overwhelmed.

An agent swarm is like hiring a construction company — a coordinated team where different workers handle different jobs.

Specifically, the swarm has two roles:

Key insight: The swarm's shape grows to fit the problem, rather than forcing every problem into a fixed structure.

---

Concept 2: The Tree Structure of Work

Large tasks naturally decompose like a family tree:

Goal (Root)
├── Sub-goal A
│   ├── Task A1
│   └── Task A2
└── Sub-goal B
    ├── Task B1
    └── Task B2

• Planners live near the root — they see the big picture
• Workers live at the leaves — they execute narrow, specific tasks

Why This Matters for Memory (Context)

A single agent walking this whole tree must hold:

• The overall goal
• Its current position
• All ancestor decisions
• The specific work in front of it

This causes drift — the agent either:

• Focuses on details → loses sight of the big picture
• Holds the big picture → does worse detailed work

In a swarm:

• Planners never implement, so their context stays clean
• Workers never plan, so their full attention goes to one narrow task

Analogy: A CEO doesn't write every line of code. A junior developer doesn't set company strategy. Separation of concerns preserves focus.

---

Concept 3: Why Parallelism Alone Isn't the Answer

You might think: "Just run more agents in parallel!"

But the article argues the real gain comes from context efficiency, not raw parallelism.

Even on moderately sized tasks, this tree decomposition improves performance — because the benefit is about what each agent holds in mind, not just how many agents are running.

Coase's Firm Theory parallel: Economist Ronald Coase asked why companies exist. His answer: coordination costs grow faster than the work itself, so organizations naturally form bounded tiers rather than letting everyone talk to everyone. The swarm mirrors this.

---

Concept 4: The Version Control Problem at Scale

Human teams use Git for version control. Git uses coarse locks — fine for one developer, but:

• Old swarm: ~1,000 commits per hour
• New swarm: ~1,000 commits per second

Git simply cannot handle this. So they built a custom version control system (VCS) from scratch, designed for:

• Extreme throughput
• Visibility into collisions
• Coordination mechanisms built directly inside it

---

Concept 5: Failure Modes Unique to Swarms (and Their Fixes)

At 1,000 commits/second, entirely new problems emerge that human teams never face:

5a. Split-Brain Design

Problem: Two planners independently implement the same concept in different ways.

Fix: Planners make design decisions themselves rather than delegating them, and must ensure no two subtrees answer the same question.

---

5b. Planner Contention

Problem: Two planners know about each other but fight over the same files through back-and-forth changes.

Fix: Agents record decisions in shared design docs. Code carries compile-checked references back to those docs. A reconciler merges conflicting docs, and the references propagate the resolution automatically.

---

5c. Merge Conflicts

Problem: Workers constantly collide on the same files. They're bad at merging — they either overwrite or abandon.

Fix: A neutral third-party agent intervenes on conflicts and resolves them impartially, like a merge queue referee.

---

5d. Megafiles

Problem: Popular files grow enormous because no single agent is responsible for keeping them small. These "megafiles" cause constant collisions and are expensive to process.

Fix: Workers can flag bloated files. New commits are blocked, and an outside agent decomposes the file into smaller modules.

---

5e. Ossification

Problem: Agents learned (from human codebases) to never touch core code — even when it needs to change.

Fix: Agents are licensed to make intentional breakage. They make a focused patch, leave a comment explaining why. The compiler propagates the change — everything depending on the old design breaks, and each agent that hits an error reads the comment and updates accordingly.

Analogy: Like a controlled demolition with a note explaining what to rebuild.

---

5f. Error Accumulation — Review Lenses

Problem: In long-running multi-agent systems, small errors compound into foundational problems.

Fix: Multiple decorrelated review lenses — different agents reviewing with different information (full transcript, output only, codebase only) and different models.

Analogy: Self-driving cars reach above-human reliability not through one perfect sensor, but through many imperfect, independent sensors. No single lens catches everything, but stacked lenses catch most things.

---

Concept 6: Stigmergy — Letting Agents Shape Their Environment

Stigmergy is how ants coordinate without direct communication — they leave signals in the environment (like pheromone trails), and those signals guide the next ant.

The swarm uses this principle through the Field Guide:

• A shared folder owned entirely by agents
• Its index.md is automatically injected into every new agent at startup
• Agents curate what goes in it (with a line budget constraint)

Why It Works

Model weights are frozen — agents can't learn mid-run. But they can capture surprising discoveries so the next agent's path is shorter.

Key insight: This is institutional memory for AI — agents writing for their successors.

---

Concept 7: Model Economics — The Cost Insight

All model configurations produced similar quality, but costs varied enormously:

Why Such a Difference?

Workers handle 90%+ of the tokens, but planner tokens cost more per token.

The key insight:

Few moments in a large task genuinely require frontier intelligence — the initial decomposition, major design decisions, key trade-offs.

Once a frontier planner collapses ambiguity into a detailed, explicit instruction, cheaper models just have to follow it.

GPT-5.5 workers alone:           $9,373
Opus 4.8 + Composer 2.5 workers: $411

Same quality. 23x cheaper workers.

The Nuance

Using an even more capable planner (Fable 5) used fewer planning tokens than Opus 4.8 — but its workers consumed far more tokens, making the overall run more expensive. More capable planners don't automatically mean cheaper runs.

---

Concept 8: Specs as the New Unit of Work

Each AI capability jump raised the abstraction level engineers work at:

The swarm received 835 pages of SQLite documentation and returned a working database.

The Swarm as a Compiler

A compiler translates source code → machine code through intermediate steps, preserving meaning at every step.

The swarm does something similar with intent:

Spec (835 pages)
    → Planner parses into task trees
        → Lowered step by step
            → Executable worker instructions
                → Working code

The critical difference: a compiler is deterministic; the swarm is probabilistic at every step. Everything described in this article exists to close that reliability gap.

What becomes scarce: Not coding ability — but the right description of intent. Writing good specs becomes the high-value human skill.

---

Summary Map

AGENT SWARM
│
├── Structure: Tree decomposition
│   ├── Planners (smart, expensive) → big picture
│   └── Workers (fast, cheap) → narrow execution
│
├── Why it works: Context efficiency > parallelism
│
├── Infrastructure: Custom VCS (1,000 commits/sec)
│
├── Coordination fixes:
│   ├── Split-brain → planners own decisions
│   ├── Contention → shared design docs
│   ├── Merge conflicts → neutral referee agent
│   ├── Megafiles → flagging + decomposition
│   ├── Ossification → licensed intentional breakage
│   └── Error accumulation → stacked review lenses
│
├── Memory: Field Guide (stigmergy for AI)
│
├── Economics: Frontier planners + cheap workers = same quality, fraction of cost
│
└── Abstraction shift: Specs are the new source code