Simon Last, co-founder of Notion, posted a thread in May about running coding agents on large-scale projects. He opened with a confession: "Most of this contradicts advice from 6 months ago." The thread went viral — 5,000+ bookmarks, 400K views. It's good advice. It's also, mostly, not new. What's interesting is where his practice quietly contradicts the loudest narrative around it, and what that tells us about where agent-assisted engineering actually is.
Here's what he recommends: Think bigger. Run one long-lived implementer session for days or weeks. Drive it with a persistent task list — "like shoveling coal into a steam engine." Spend your time writing plan docs, not watching the agent. Use adversarial review before anything gets checked off. Set up role-based sessions: planner, implementer, reviewer, tester. Get yourself out of the loop.
#The Swarm That Isn't
Last's setup is small by design: one implementer, one reviewer, a planner session he spins up to append tasks and then kills. Maybe five or six agents total, one human holding the plan. His own metaphor — a steam engine with one person shoveling coal — is one engine, one operator, closer to a well-run CI pipeline than to agents negotiating with each other. That's a calibration point, not a claim that needs debunking: nobody reading that thread called it a swarm. The real question is what happens when you take the same shape and scale it past one operator, and Last didn't wait around to find out — by the end of that same month, other Notion appearances describe him running a "software factory," 30-plus custom agents, one colleague getting 70 stuck-agent notifications a day, solved by building a manager agent with authority to invoke and supervise the other 30. One operator became a hierarchy within weeks.
Cursor ran the scaled-up version of that same experiment first, in public, and on the first attempt it broke. They tried flat self-coordination — agents with equal status sharing a file. It failed. Agents held locks too long, became risk-averse, avoided hard problems. "No agent took responsibility for hard problems or end-to-end implementation." Nick Carlini built a C compiler with 16 parallel Claudes using just lock files, and even at that modest scale, agents would hit the same bug, fix it, then overwrite each other's changes.
Cursor didn't need a separate rescue mission to fix it — the same post describes the failure and the fix in one write-up: a strict planner/worker split, tried and working. A later post tested a further-engineered version of that same tree on a new task, building SQLite from scratch in Rust, and beat the earlier version in every model configuration — 80% of a held-out test suite passing in four hours, versus the old swarm spiraling and needing to be paused before hour two. Same models, same time budget. The org chart was already a tree in both versions. What changed underneath it is the subject of the next section.
The fix wasn't more agents or smarter agents. It was a tree: planner agents split a goal and delegate, worker agents execute the pieces. Cursor's own explanation is the same argument I'm making about constraints, aimed at a different failure mode: "a planner never implements, so its context never fills with low-level detail, and a worker never plans, so it can spend all its context on one narrow piece of work." Context efficiency through role separation, running on the same asymmetry throughout — expensive model plans and judges, cheap model runs the volume work in between.
Worth being precise about the word "swarm" here, because two architectures hide under it and they're opposites. A real swarm — the ant-colony, pheromone-trail kind — coordinates through indirect signals with no central planner. That's what Cursor's flat version was, and it's what failed. Even products marketed with swarm language frequently expose hierarchical and centralized controls underneath. Pheromind, named for pheromone-based stigmergy, describes its own product as "not chaotic AI agents, a structured hierarchy." claude-flow still calls itself hive-mind, but ships selectable topologies and a "Queen" with a centralized override. The branding says swarm. The operational controls acknowledge the need for authority.
It's not just Cursor's war story, either. One production writeup describes a customer-service system built as a fully-connected swarm — seven agents, any of them free to hand off to any other: intent classifier, knowledge-base agent, return-policy agent, order-status agent, escalation agent, tone-checker, summarizer. It demoed well. In production, it fell into handoff loops — the tone-checker deferring to escalation, escalation deferring to policy, policy deferring back to the tone-checker — 47-second average response times, $1.80 in token cost per conversation. The pilot was killed at month three, fixed by the same move Cursor made: put one supervisor in charge of the decision. A separate survey of eighteen months of shipped agent products found the same shape every time it looked: Cursor Composer, Devin, Replit Agent, and Claude Code all run as orchestrator-plus-workers. The peer-agent "team in a box" pattern — AutoGen, CrewAI — demos well and rarely survives contact with a real product.
So here's the corrected implication: if your agent workflow needs more than one agent and it's falling apart, the constraint you're missing usually isn't in the plan doc, it's in the org chart. Flat coordination fails because everyone can plan, which means everyone can also quietly redefine the task.
There's a new benchmark preprint behind this, not just two companies' war stories. MSEval, testing 10 real full-stack projects across 10 collaboration topologies, found that organizational topology rivals model capability in determining outcome — the same task, the same model, a different topology shifts quality scores by 30+ points and doubles wall-clock time. It's a July 2026 preprint, not settled science, but the direction is hard to argue with: the topology isn't a footnote to the model.
None of this is conceptually new for organizations of people — it rhymes with Taylorism, with Coase's theory of the firm. I want to be careful with that comparison rather than lean on it: this is an argument about what makes agent systems legible and debuggable, not a claim about how humans should be managed. The context-efficiency case for keeping an agent's role narrow has nothing to say about how healthy teams of people actually learn, collaborate, and retain ownership — those are different mechanisms solving a different problem. What's new for agents is that the failure mode is now measured, with a number attached, and the number surprised people who assumed a good enough model would make the org chart optional.
Multi-agent orchestration still earns its complexity budget cheapest in evaluation — a fresh read-only sub-agent reviewing a diff against the spec catches things the implementer missed. But it's no longer the only place it earns it. Anthropic shipped dynamic workflows in Claude Code five days after Last's thread — tens to hundreds of parallel subagents building end-to-end, with independent verification folded into the run before anything surfaces. Multi-agent building works when it's deliberately orchestrated rather than left to self-coordinate — Anthropic's dynamic workflows support that broader point, though they don't establish that every workflow follows Cursor's specific tree topology.
#Decision Rights, Not Roles
"Planner never implements, worker never plans" is close but too literal — implementers necessarily make local decisions, which file to touch first, which helper function to extract, and pretending otherwise doesn't survive contact with real work. The distinction that actually holds is decision authority: planners own decomposition and cross-cutting choices; workers make bounded decisions inside their assigned scope but can't silently redefine the goal; reviewers judge the result without inheriting implementation ownership.
That framing also fixes something a stricter version breaks. A tree doesn't work because software is secretly tree-shaped — it's often closer to a graph, with dependencies crossing between branches. What the tree provides is a hierarchical control plane laid over work that would otherwise have no single place a given decision gets made. At small scale, one agent can hold planning, implementation, and judgment at once, and that's fine. The principle isn't "these must always be separate roles." It's narrower and more durable: at multi-agent scale, the same context shouldn't own global planning, local implementation, and final judgment simultaneously — because once it does, nothing stops it from quietly redefining the task it was supposed to be judged against.
The same failure shows up outside engineering. A design or creative review is a judgment role; the moment it also gets a vote on direction, it collapses into this exact single-context problem, and the output quietly drifts toward whatever the reviewer would have preferred instead of what the task actually asked for.
Role separation pays a second, quieter dividend: it shrinks what has to live in memory. A planner that doesn't implement doesn't carry codebase minutiae across a long session. A worker that doesn't own global planning doesn't need the project's full history, only the context and constraints governing its assigned slice. Compaction loses context fastest exactly where this split is missing — one undifferentiated session trying to hold the whole job in its head. A good org chart does structurally what good code does for the same reason: it moves what would otherwise live in someone's memory into structure that reduces how much has to be remembered in the first place.
Anthropic ran something close to a controlled version of this claim, on a task with no code to merge at all. Several swarms spent twelve hours each building a text-based fantasy game, and the org chart itself was the variable: a baseline "just coordinate" prompt, a prescriptive-roles prompt, and a "CEO hierarchy" prompt naming one agent CEO and telling everyone else to take assignments from it. It didn't matter. All three shipped a bad game — inscrutable interfaces, no sense of pacing — and the paper's own verdict is "models have poor taste in this arena." What actually moved the outcome, on a separate measurement across those same runs, was which model generation ran the swarm, not which org chart it ran under: Sonnet 4.6 and Opus 4.6 barely merged any PRs at all, real chaos, no hierarchy needed to explain it; Opus 4.8 and Mythos Preview "solved" merging by barely touching each other's files, order bought by refusing to actually collaborate; only Sonnet 5 held a high merge rate and real code-sharing at the same time, across every prompt variant they tried.
That's not a strike against Cursor's fix. A CEO title not teaching a model taste is a different claim than a planner not preventing a merge conflict, and the metric closest to Cursor's actual failure mode — PR-merge rate — moved with model generation here, hierarchy-agnostic, same as it did for Cursor. But it draws the boundary tighter than I'd like it to be. Decision rights fix one specific failure mode, agents stepping on each other's writes, and they fix it whether or not the model underneath has any judgment at all. They don't fix a model that doesn't know a fun game from a boring one. No org chart teaches taste it wasn't born with.
#Reads Fan Out. Writes Don't.
Call the shape a tree, call it a graph, call it whatever the next tweet renames it — there's a distinction hiding under the label that changes how I'd read the SQLite result, and it's older than any of this month's vocabulary.
In mid-2025, Cognition's Walden Yan made the case against multi-agent systems entirely: give parallel agents the same codebase and they make conflicting implicit decisions nobody can merge. His example got famous — ask a swarm to build a Flappy Bird clone, one subagent builds a Super Mario–style background, another builds an incompatible bird sprite, and no merge agent can reconcile choices neither agent knew the other was making. Anthropic's own multi-agent research post shipped the next day, arguing what sounded like the opposite case, and the pairing framed a year of the loudest architecture debate in the field. Yan refined his own position this April — the broader debate didn't close, but his revised claim narrowed to something more defensible: multi-agent works when writes stay single-threaded and the extra agents contribute intelligence, not more hands on the keyboard. Research. Review. Verification. Not implementation.
Cursor's workers write code in parallel. That sounds like a clean counterexample to Yan's rule, except it isn't, because Cursor didn't find a way around the danger he described — they built an enormous amount of infrastructure specifically to survive it: a version control system built from scratch, because Git's coarse locks couldn't handle a thousand commits a second; a neutral agent whose only job is resolving merge conflicts on everyone else's behalf; design decisions recorded in shared docs with compile-checked references back to them, so two planners can't quietly contradict each other; a process for splitting "megafiles" the moment they start absorbing every agent's changes. Every one of those exists because parallel writes are exactly as dangerous as Yan said. The tree didn't make the danger disappear. It made the danger survivable, and survival cost real engineering — most of a small distributed system, built underneath the coding agents.
Which means "make it a tree, not a mesh" needs one more clause. Reads fan out cheap — evaluation, research, verification barely need any of this machinery, a fresh context and a spec is most of what it takes. Writes only fan out safely if you're willing to build the coordination layer that turns a collision into a recoverable event instead of a corrupted file. Cursor built that layer, and it worked. Most teams reaching for "just add more agents," me included on a bad week, skip straight to spawning workers with no hierarchy underneath them, and never build any of what makes Cursor's survive contact with itself.
#When the Boundary Isn't Enforced
A tree only holds if a blocked worker treats the boundary as a stop condition instead of a routing problem. I've watched my own agent count climb past fifty this way — a workflow hits a permission boundary or a decision only I can make, and instead of stopping to ask, spawns another agent to try a different angle. That one hits the same wall and spawns another. Every one of them repeats the exact same blocked attempt its sibling just made, while the actual problem the whole time was a single yes-or-no that needed me, not more hands. One documented report put the damage at over a million tokens and fifty-plus levels of recursion before anyone noticed.
I wanted to know if the unease was backed by numbers, not just vibes. MAST evaluated seven multi-agent frameworks across 200+ benchmark tasks, producing a taxonomy of fourteen failure modes clustered into specification and system design, inter-agent misalignment, and inadequate verification — architecture problems, the same places this piece keeps returning to, not "the model wasn't smart enough." Failure rates across those evaluated configurations ranged from 41% to 87%. That's not a universal failure rate for multi-agent systems — these are benchmark tasks, not naturally occurring production traces — but it's strong evidence that architecture, not just model capability, is doing most of the damage.
Writing the rule down and living it aren't the same thing, and I've watched compliance with a clearly-stated rule quietly decay over a few weeks because nothing was actually checking whether anyone followed it. The fix that's held up isn't a better rule. It's something that measures whether the rule survived contact with a real week.
#The Honest Framing
Here's what I'd tell someone starting today:
Start with constraints, not agents. Before you pick a tool or decide how many agents to run, write down what "correct" looks like. Tests, types, linter rules, architecture docs, naming conventions.
One agent is usually enough — until the task doesn't fit in one context. A single well-constrained agent with a clear task list and verification strategy handles most work. Reach for more agents when the task decomposes cleanly into independent pieces, not because it sounds impressive.
If you do scale up, separate the decision rights before you separate the agents. One role plans and delegates; every other role executes its assigned piece without redefining the goal or negotiating with peers as equals. Flat coordination over shared implementation state — agents of equal status writing to the same files — is the failure mode, not multi-agent itself, and not flat coordination generally: flat, read-only research and evaluation works fine without a hierarchy.
Reads fan out cheap. Writes fan out expensive. Evaluation, research, and verification barely need coordination machinery. Parallel writes need real infrastructure — version control that handles the collision rate, a designated conflict resolver, decisions written down somewhere every agent has to check. Skip it and "add a swarm" gets you Cursor's first failure again, just with better marketing.
A blocked agent should stop, not route around. Treat a permission boundary or an unanswerable question as a stop condition that surfaces to a human, not a signal to try again sideways.
Invest in meta. Last's "spend time on meta" is the advice most people skip and shouldn't. Every mistake you incorporate into the constraints prevents a class of future mistakes.
Stay in the judgment loop, not the status-chasing loop. Stop manually polling agents and watching CI. Keep reviewing consequential decisions and production-bound changes. At Notion's scale, that loop got its own supervisor — a manager agent absorbing the mechanical noise across 30 workers so the human only hears about what matters. Same principle, moved up a level.
The advice changes fast because the tools change fast. The principle changes slow, because it was never really about tooling: constraints still do the work, but at multi-agent scale, constraints include decision rights — who may decompose the problem, who may make local implementation choices, who resolves collisions, and who independently judges the result without having built any of it.
"Org chart" is the most boring possible name for an engineering constraint, which might be exactly why it took this long for anyone to write it down as one. Cursor found it debugging a failed swarm. Notion found it drowning in stuck-agent notifications. A benchmark team found it just trying to get repeatable numbers. None of them were reading each other's work. Three rooms, the same answer: give someone the authority to plan, and nobody else the authority to redefine the task once it's handed off. Everyone was staring at the model. The thing that needed designing was the reporting structure.