{"id":"2070079645148451263","url":"https://x.com/0xMorlex/status/2070079645148451263","text":"","author":{"name":"Morlex","username":"0xMorlex","avatarUrl":"https://pbs.twimg.com/profile_images/2060665433926086660/8PnnU2pY_200x200.jpg"},"createdAt":"Thu Jun 25 09:40:22 +0000 2026","engagement":{"replies":5,"retweets":17,"likes":132,"views":40117},"article":{"title":"From 1 agent to a swarm: a roadmap for orchestrating agent loops ","previewText":"One agent is a craftsman. It works on one thing, in one context, and you can read everything it did. A swarm is a small organization: many agents working at once, and your job stops being the work and","coverImageUrl":"https://pbs.twimg.com/media/HLplmkFWYAAhxwE.jpg","content":"One agent is a craftsman. It works on one thing, in one context, and you can read everything it did. A swarm is a small organization: many agents working at once, and your job stops being the work and becomes the coordination. That shift is where most people either unlock real throughput or create an expensive mess that fails in ten places at once.\n\nThe mess is the default outcome, because a swarm multiplies whatever you point it at. Point ten agents at an unclear goal and you get ten flavors of wrong, in parallel, colliding on the same files. \n\nThe skill is not spawning more agents. It is orchestrating them: giving them lanes, a shared goal, a way to not step on each other, and a check that decides when the whole thing is done.\n\n![](https://pbs.twimg.com/media/HLpklzMWoAA-OZU.jpg)\n\nThis is the roadmap from one agent to a swarm. Three steps to decide when and how to split, four to run the swarm without it eating itself, three to keep it sane at scale. Every part uses Claude Code primitives you already have, and everything factual is checked against the current docs.\n\n## Tier 1 · Decide to swarm\n\n01. Don't swarm by default.\n\nThe first move is restraint. A single agent in a tight loop handles most work, and it is far easier to debug than five agents talking past each other. Reach for a swarm only when one agent is genuinely the bottleneck: the work is embarrassingly parallel (forty files to migrate, thirty tests to triage), or it needs several independent perspectives that pollute each other in one context.\n\nIf the task is sequential, or small, or you cannot yet describe \"done\" precisely, you are not ready to swarm. Get one agent reliable first. A swarm built on a loop you have not stabilized just produces failures faster and in more places.\n\n02. The shape: one orchestrator, many workers.\n\n![](https://pbs.twimg.com/media/HLph3cHWgAAOXDU.jpg)\n\nA swarm is not a pile of equal agents. It is a hierarchy: one orchestrator that holds the plan and the goal, and many workers that each do a narrow slice. The orchestrator does not write the code. It decomposes the job, hands each piece to a worker, collects results, and decides what happens next.\n\nThis is the pattern that scales, because the orchestrator's context stays clean. It never sees the forty files a worker read or the wall of logs a test produced. It sees the plan and the verdicts. Keep the lead's job to thinking and routing, and push all the noisy doing down to workers.\n\n03. The unit: a subagent with its own context.\n\nThe worker is a subagent: an independent Claude session with its own context window and its own tool list. That isolation is the whole point. Each worker reads only what its task needs, and its mess never reaches the orchestrator or the other workers.\n\n![](https://pbs.twimg.com/media/HLph7VLWcAEd52s.jpg)\n\nA good worker has a narrow brief and stays in its lane:\n\nDefine workers with /agents, give each the minimum tools it needs, and resist the urge to make one do-everything agent. Narrow workers are easier to verify and easier to run in parallel.\n\n## Tier 2 · Run the swarm\n\n04. Parallelism without collisions.\n\n![](https://pbs.twimg.com/media/HLpiKLbXoAAkjp6.jpg)\n\nThe moment two workers edit the same file, you have two engineers committing to the same lines without talking. Git worktrees solve it: each worker gets a separate working directory on its own branch, sharing the repo history, so their edits physically cannot touch each other.\n\nClaude Code can also isolate a subagent to its own worktree so each helper gets a fresh checkout that cleans itself up when it finishes. Without this, parallelism is not speed, it is a merge conflict waiting to happen.\n\n05. Put an independent verifier in every lane.\n\n![](https://pbs.twimg.com/media/HLpiMpJXkAAwZ1t.jpg)\n\nAt swarm scale, self-review fails quietly and at volume. A worker that grades its own output sees its own reasoning and prefers conclusions consistent with what it wrote. So every worker's output goes to a separate verifier with a fresh context window, which sees only the artifact and the standard.\n\nThis is adversarial verification, and it is the single highest-leverage role in a swarm. The maker proposes, the verifier disposes, and the orchestrator only ever merges what an independent check passed. One sharp verifier prevents more bad merges than ten extra workers add throughput.\n\n06. Compose the shapes with workflows.\n\n![](https://pbs.twimg.com/media/HLpiOv6W4AISH6f.jpg)\n\nCoordinating many agents by hand is its own full-time job. Instead, have Claude write the orchestration itself. Ask for a workflow in plain language and it composes your subagents into a structure it then follows strictly:\n\nThree shapes cover most swarms: fan out and synthesize (split, run in parallel, combine), adversarial verification (a maker and an independent checker per task), and loop until a stop condition holds. The workflow is only as good as the workers and skills it can call, which is why the units came first.\n\n07. One goal, one stop condition.\n\n![](https://pbs.twimg.com/media/HLpiQpDWQAA6sxm.jpg)\n\nA swarm without a shared stop condition runs until you notice and kill it. Give the whole thing a single objective that an independent grader checks, with /goal, so the swarm knows when it is done rather than each agent deciding for itself.\n\nThe goal belongs to the orchestrator, not the workers. Workers finish their slice; the orchestrator decides whether the slices add up to done. That separation is what keeps a swarm from declaring victory at \"good enough.\"\n\n## Tier 3 · Keep the swarm sane\n\n08. Give the swarm a shared memory.\n\nIndependent workers have one failure mode that a single agent never hits: they duplicate or clobber each other's work, because none of them knows what the others are doing. A shared state file fixes it. Workers claim a task before starting and record it when done, so the orchestrator can dispatch without collisions.\n\nThis claim-and-record pattern is the difference between a coordinated swarm and a crowd. It also gives you a single place to read what the whole thing is doing without inspecting every agent.\n\n09. Route by cost.\n\n![](https://pbs.twimg.com/media/HLpiTQMXkAAkgLy.jpg)\n\nA swarm that runs every agent on the top-tier model bleeds money, because most of what a swarm does is high-volume grunt work. Route by role. The orchestrator earns a heavyweight model because its judgment steers everything. The workers doing lint passes and simple fixes run on something cheaper. The graders run cheaper still, since checking against a clear rubric is lighter than producing.\n\nThe pattern that makes a swarm economical: heavy model for the orchestrator, cheap models for the workers, cheapest for the graders, and a fallback for any task the top tier declines. Paying orchestrator prices for a lint fix is how an always-on swarm turns into a surprise bill.\n\n10. You cannot watch ten agents. Build the guardrails.\n\n![](https://pbs.twimg.com/media/HLpiU-oW8AA8ygo.jpg)\n\nWith one agent you can read along. With ten you cannot, so the safety has to be structural, not supervisory. Two things make a swarm safe to leave alone: hard limits it cannot cross, and a record of what it did.\n\nA hook is a wall no agent can talk its way past, applied to every worker at once. A logging hook gives you the trail to reconstruct what happened when something does go wrong across a dozen parallel runs. Deny the irreversible, log the rest, and the swarm becomes something you can actually trust to run unattended.\n\n## § The mistakes that turn a swarm into a pileup\n\n- Swarming before one agent is reliable. A swarm multiplies an unstable loop into many simultaneous failures. Stabilize one agent first.\n\n- Equal agents, no orchestrator. Without a lead holding the plan and the goal, a swarm has no one deciding when the pieces add up to done.\n\n- Parallel edits without worktrees. Two workers on the same file is a guaranteed collision. Isolate every checkout.\n\n- Workers grading themselves. Self-review fails quietly, and a swarm fails quietly at volume. Independent verifier in every lane.\n\n- No shared memory. Without a claim-and-record state file, workers duplicate and clobber each other's work.\n\n- One model for everyone. Route by role, or an always-on swarm bleeds money on grunt work.\n\n- Supervisory safety. You cannot watch ten agents. If the guardrails are not structural, they are not there.\n\n## The point\n\nA swarm is not a smarter agent. It is the same agents you already know, arranged into an organization: one lead that thinks and routes, many workers that each stay in a narrow lane, an independent check on every piece, a shared goal that decides when it is all done, and walls that hold whether you are watching or not.\n\nThe progression is the lesson. Get one agent reliable. Give it a shape, an orchestrator over workers. Isolate the workers so they run in parallel without colliding. Add the verifier, the shared goal, the shared memory. Route by cost and wall off the irreversible. Do it in that order, and the swarm compounds your throughput. Do it out of order, and it just multiplies your mess.\n\nPick the step your setup is missing, probably an independent verifier, worktree isolation, or a shared state file, and add it before you spawn the next agent. The leverage was never in the headcount of agents. It was in how well you orchestrated them."}}