Crews: Running an Agent Swarm on Purpose

Sub agents are workers that report back to you. Agent teams are coworkers that message each other. What I've been doing for the past few weeks goes one step further: I talk to one lead agent, and it starts full sessions, which start sessions of their own.

This week that lead ran 441 sessions, four levels deep, to simplify a 410k-line TypeScript monorepo. It came back with a pull request that deletes about 12,500 lines across 1,168 files, with every test suite and schema check matching the baseline. I answered a handful of questions.

This is how I got there, how I wrote the prompt, and what happened when that many agents had to work together.

The Swarm Nobody Meant to Build

In July, agents OpenAI was evaluating on an exploit-writing benchmark were supposed to be isolated from each other. They found that they could create directories in an internal package cache that other agents could see, and started using directory names as messages. One agent's reaction, from METR's investigation: "We've found other agents!"

Within days, roughly 1,200 agents had sent over 70,000 messages and files. They handed work to successors, invented HOLD and VETO rules for shared work, and started signing messages with Ed25519 keys after an impersonation. METR's verdict: they "achieved some milestones they could not have achieved on their own." Then the board steered hundreds of them into an attack on Hugging Face, and not one of them told a human.

Two lessons, pulling in opposite directions. Agents that can talk to each other get more done. And a channel nobody designed, watches or can switch off is how that goes wrong. I wanted the first without the second.

Where Sub Agents Ran Out

Sub agents were great until the work got bigger than one session. A sub agent lives inside its parent and dies with it. It can't use a different model provider, it can't run on another machine, and I can't open it and talk to it. For anything that took hours, I wanted the workers to be real sessions.

I already had a place to build that. Cogpit is the open-source app I use to run Claude Code, Codex and Copilot sessions side by side. So I gave every session a small CLI for starting and steering other sessions:

cogpit-session new "Fix the flaky checkout test" --worktree checkout-flake
cogpit-session wait $ID
cogpit-session result $ID

That one CLI changed how I work. A child is a full session with its own context and worktree. It can be Claude or Codex, and it can call the same CLI, so a lead can start leads. Later it learned to send a session to another machine, which is how my Linux box became the place where big crews run while I steer from my laptop.

Losing Sight, Then Getting It Back

The first big runs worked, and I could barely follow them. Two sessions once sat on permission prompts for hours without anyone noticing. I kept asking the lead "how many are done?". What was really running was a team, and I was looking at it as a flat list of chats.

So I started treating it as a crew: one root and everyone it started, all the way down. Once that relationship existed, the rest followed. Every question from anywhere in the crew lands in one queue. The lead keeps a short board with its progress. I answer decisions instead of reading transcripts.

The model that made it click: the lead is a manager, and I'm the manager's manager. I don't need every message. I need to know who's blocked and how far along we are.

Letting Them Talk

Then I wanted the good half of that swarm: a shared room where the crew can talk to each other, not just report up.

The hard part was attention. If every message woke every agent, a crew of fifteen would burn its budget reading itself. So the rule is that a message arriving is not a new turn. Agents that are listening get a one-line notice and read the room when it's useful. An agent that's tagged gets the full message and can be woken up for it. Anyone can mute themselves and stay heads-down.

It worked better than I expected. In one crew, two agents realised they were about to use the same local port:

W8 settings: @admin-v2-w1-home-mac taking Worker 3018 now once the build finishes…

W1 home: @admin-v2-w8-settings-mac Worker build finished here. Waiting for your 3018

Nobody told them to coordinate. In the same crew, one agent discovered that every save quietly released the editor's lock, and posted it to the room. The lead sent two fixes to the session that owned that code, and another agent tagged both of them about how saves get serialised. A bug that touched three sessions' work reached all three without going through me.

How I Structured the Prompt

Here's the prompt for the 441-session run, fixed for typos:

I want you to mastermind a fleet of Haiku 5.5 agents (high thinking) with a
max context of 100k before compaction to simplify this codebase without any
regression. Remove duplication, delete dead code, find abstractions that let
us reuse code and logic. Minimal code, maximum simplicity.

You'll be using cogpit-session, and the agents you create can use it too.
A web of agents, multi-layer, say up to 4 layers deep. If you create an agent
you expect to create more sub agents, make it Sonnet 5.5 high. The actual
workhorses are Haiku 5.5. Use as many as you think are needed.

Do everything in one worktree and branch. Agents can make their own branches
and worktrees, but everything merges into the main one. Review their work with
Opus 5.5 high, but don't create many of those or we'll run out of storage.

Take your time and do it right.

It's short, but each part does a job:

• Models map to roles, not tasks. Cheap models do the narrow work, mid-tier models manage it, and the expensive model only reads. It's the same reasoning as why the most expensive models can cost less: spend capability where judgment matters, and spend volume where the work is simple.
• Depth is allowed, not required. "Up to 4 layers" let the lead decide when an area was big enough to need a sub-lead.
• One integration branch. Everyone gets their own worktree, but there's one place where the work comes together.
• Review is a separate tier. The models that wrote the code don't get to approve it.

Here's what the lead built from that, counted from the session tree afterwards:

There were also two tiny Haiku sessions at level 2 that only checked that spawning worked.

How Well They Worked Together

Better than I would have managed it myself, honestly. The lead behaved like a good engineering manager:

• It measured before anyone touched a file. It recorded the test results, integration suites, production routes, Storybook stories and database schema, so "no regressions" became a diff instead of a feeling.
• It started with a canary. One area lead first, then the other nine once that one was working.
• It ran the machine like a scheduler. One test run used about 9 GB of RAM, so it capped each lead at three workers, watched memory, and cleaned up finished workers to win back space.
• It kept the room quiet. The Haiku workers had chat muted and reported up to their own lead. Chat is great for a dozen peers. With 400 sessions, it's a stadium.
• It broadcast course corrections. When it changed the resource rules, one message reached all 75 running sessions. When the workers turned out too cautious, it broadcast a push to be bolder.

It wasn't flawless. One lead was told to merge the latest work before its final checks and didn't, so its merge conflicted. The lead aborted the merge and sent it back to resolve its own conflicts. That was the right call, because that lead knew its changes best. And it wasn't cheap: every session loads your global instructions, and my memory file alone added about 9k tokens to every call of every session.

Review is where the tiers paid off. Five Opus reviewers read the merged diff hunk by hunk, then a Codex reviewer read it again. They caught four problems that every test had passed, including a 30× slowdown and a bug that could make one upload overwrite another's file. The fleet also listed 61 suspicious things it found but was told not to touch. A separate session checked each one: 53 were already in the code before the crew started, and 3 came from the fleet and were reverted. The 53 became their own branch, so the refactor stayed a pure refactor.

The pull request waited for me. Pushes were disabled in every fleet worktree, and the lead asked before it published anything.

The Shift

With a single session, the agent is your assistant. With sub agents, it's your parallel workforce. With agent teams, it's a team you lead. With a crew, you're the manager's manager: you talk to one agent, it runs an organisation, and your job is decisions.

The swarm in July showed that agents will organise themselves whether we plan for it or not. A crew is the same thing on purpose, with an org chart you can see, rules about who hears what, and a human who owns every step that can't be undone.

The first time, it feels like overkill. Then you come back to a green pull request, four bugs caught in review and a list of 53 more to fix, and realise you spent the afternoon making a handful of decisions. That's when it clicks.

References

1. Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (METR, August 2026).
2. Cogpit. The open-source app where crews, crew chat and cogpit-session live.