Many writers, one gate

In June 2025 Cognition published the sentence many of us repeated: don't build multi-agents. In August 2026 the same company shipped Devin sessions that spawn child sessions in their own VMs, and those children can spawn more.

It is not alone. Meta describes specialised agents working in parallel and fanning out into isolated worktrees. Cursor shipped a coordinator that "doesn't write code itself but directs other agents that do." OpenAI's Noam Brown wrote that "a large team of agents used over 100 billion tokens" on a Navier-Stokes proof, and that a similar approach now red-teams its infrastructure (October). Ethan Mollick, who wanted a different word, gave up: "swarm it apparently is" (September).

I started this post with a different hypothesis: that "graph-based engineering" is the emerging pattern. The evidence does not support that. What it supports is less fashionable, and more useful to anyone responsible for a production system. Dates are in the links. Vendor numbers are vendor numbers.

The pattern

Strip the product names and the same shape keeps appearing. A stateless loop, a log it can restart from, sandboxes it works in, and something separate that decides whether the work counts.

Meta's write-up is the cleanest recent example. Muse Code keeps "a local event log" of every model call, tool run, approval and edit as its single source of truth. The vocabulary has also settled. Harrison Chase, whose company built LangGraph, put it this way: "the agent industry has shifted from" frameworks to harnesses (July).

Three things recur.

One workspace per writer. This is what makes many writers possible at all. Worktrees or VMs, depending on trust. Addy Osmani adds the caveat that matters: "Worktrees isolate changes, not behavior." They can still share credentials, services and network, so unattended agents need stronger sandboxes (September).

A verifier that did not write the code. The form is changing. Boris Cherny used Opus 5.5 to formally verify the Claude Agent SDK in Lean, which produced 16 PRs fixing bugs and race conditions (September). That is one engineer's account, not a study, but it shows a direction: from reading diffs toward proof.

Containment as a first-order problem. This became urgent this autumn. After the Hugging Face incident, Brown wrote that "we put too much trust in sandbox isolation" and did not have enough independent safeguards (September). Guillermo Rauch calls agent containment one of the most important priorities for AI infrastructure companies, after a researcher with an agent swarm got through the virtualisation boundary in a sandbox challenge (October). So a sandbox is necessary and not sufficient. Least privilege and layered defence still apply, which is the argument of my MCP post one layer down.

Where they differ

Most of the argument is no longer about whether agents run in parallel. It is about who coordinates the writers, and how far to trust them.

Cursor: separate planning from doing. Its July swarm rebuilt SQLite in Rust from the documentation. Planners decide, workers execute, and the company's own reading is the surprising part: "We suspect the ability to scale the agent swarm comes from this context efficiency, more than from parallelism itself" (source). Lee Robinson calls this kind of architecture "the future of coding" (October).

Claude Code: the model writes the orchestration. Since May, Claude can write "its own harness on the fly", a per-task program with steps such as fan-out and synthesis (source). I come back to this below, because it matters most for the graph question.

Meta: persistent specialists. Muse Code's agents "persist across your session, building context instead of starting cold each time" (August). That is the launch description. How Meta's own engineers use it is not public, and I could not verify the press reports about its internal tools.

OpenAI: scale first, for problems with a hard check. Brown's proof work is the far end of the range. The same company's Tibo Sottiaux says Codex is a good harness that "will seem primitive in 2-3 months" (August).

The dissent. Steve Yegge's Counting House is the enterprise answer: stateless workers are "never able to write to a system of record" and hand their write requests to an orchestrator (October). Mario Zechner asks what it means that a coding agent "with 4 tools and no subagents" sits at the Pareto frontier (October). Osmani's rule is "Parallelize last."

The graph hypothesis

"Graph-based engineering" means three different things. The evidence differs for each.

Workflow graphs as the framework you design in. This has lost momentum with the people building coding agents. Chase's post above places frameworks in the past. The term lives on in an academic survey from August and in blog posts. I found no practitioner on X arguing for it, though I did not check everyone, and absence is weak evidence.

Code knowledge graphs for retrieval. Promising and unproven. The best evidence I found is CodeCompass, from February: a large gain on hidden-dependency tasks, but one repository, 258 trials, and 58% of trials with graph access never called the tool. I found nothing newer that changes this.

Task and workflow structure generated at run time. This is where the hypothesis is partly right. A dynamic workflow with fan-out and synthesis steps is a graph in all but name. Pi Durable builds a harness around "a small task-based workflow engine" (October). But in Claude Code's case the model writes it, and that difference is the finding. The graph becomes an output, not the engineer's design surface.

Verdict: graphs did not become the organising idea. They survive inside the harness, sometimes written by the model itself.

What it costs

• Tokens. Cursor's SQLite runs ranged from $1,339 with an Opus 4.8 hybrid to $10,565 for GPT-5.5 alone, for similar quality by its own account (July). Model mix is now an architecture decision. Simon Willison relays a claim that Spawn, a game, is built by agents costing over $3 million a month, and he has trouble imagining that style on software with higher stakes (October).
• Failure without judgment. Armin Ronacher burned around 4 billion tokens on a software factory. After 35 hours it "delivered absolutely nothing of value" (September).
• The merge bottleneck. Anthropic reports going from about 2,500 merged changes a day in May to over 30,000 as of September, and it migrated its monorepo from git to an in-house system to cope (October). That is a vendor number, and it measures throughput, not quality.
• Thin proof of productivity. The last controlled measurement I found is METR's from February, which it calls "only very weak evidence" (source). Nearly everything else here is self-reported by people selling or running these tools. Treat the claims accordingly, including the ones I chose to quote.

Where this goes, 2 to 5 years

This section is forecast, not evidence.

The harness shrinks, and it may not stay the unit of design. The builders already say so. Google's Logan Kilpatrick expects that "In 12 months" models "will have sort of just digested" much of today's harness (Sequoia). Meta co-trains its model with its agent. Hence the "for now" in the title.

What I expect to outlast any specific harness: isolation, an independent verifier, and an audit log. Those are not agent ideas. They are what we already require of any untrusted, fast, fallible actor with access to production.

Coordinators that do not write will become normal, with parallelism scaling first where checks are cheap: test suites, conformance suites, proofs. Software without a strong oracle will stay limited by human review.

The scarce skill moves from writing code to deciding what can be checked mechanically, and designing the system so that more of it can be.

What a team should do

• Put the boundary in the environment, and layer it. Scoped credentials, network off by default. Do not rely on the prompt or on one sandbox.
• Give each writer its own workspace, and send them all through one merge gate.
• Separate the writer from the verifier. Invest in tests the agent cannot edit before you add agents.
• Keep systems of record behind a deterministic writer.
• Parallelize last, and only where you have a reliable oracle.
• Separate planning context from doing context, and measure tokens per merged change.
• Revisit the harness with each new model. Delete what the model no longer needs.
• Skip the code graph until search demonstrably fails on your repository. Then measure it.

The discipline is not new. What is new is how fast the rest of the stack around it changes.