Agentic hub and spoke

Update: two weeks on, I measured what this team, and a second one, spent to run. The results are in Case study: token efficiency gains of a hub and spoke agent team.

As of October 2026, working with Claude Opus 5.5, the most effective thing I’ve done with a team of AI agents wasn’t writing a better role. It was adding a producer. I had defined the specialists already: designer, writer, gameplay, art, sound, dev tools, video, QA. Each was good in its lane, and I was the switchboard between them. Then I dropped a producer agent in place, gave it permission to delegate, and forward progress exploded.

The numbers, with the caveat that commits aren’t progress: the game got 29 commits in the 20 hours before the producer’s first one, and 71 in the hour and three-quarters after it.

That is one evening of evidence. Here is how it runs, what broke, and what I don’t know yet. If you only want something to copy, skip to the end.

Spoke, hub and axle

One person directs. Nine agent sessions do the work, each with one discipline, all on my laptop, in one git repository, at the same time. I talk mostly to the producer. It doesn’t write the game. Its job is to keep the plan, hand out work, route information between agents and bring me a short list of decisions.

Hub and spoke is the usual name for that, and it leaves out two parts of the wheel.

The first is the axle, which is me. An axle is the one part that doesn’t turn with the work. The hub rides on it, and it decides where the wheel is pointed.

The second is the rim. Spokes with no rim don’t roll. The agents settle interfaces with each other directly, and the producer hears about it afterwards. It gets told at once about three things only: something that breaks the main path, something with no clear owner, or something that needs me.

Documents are the team’s memory

An agent forgets everything when its context fills and a new session takes over. Anything that must outlive a session is written down, and the documents are split so no agent has to read all of them.

AGENTS.md                  the entry point: what to read first
games/dino-island/docs/
  pm.md                    the plan; only the producer edits it
  todo.md                  the queue: one line a task, grouped by agent
  todos/                   briefs, linked from the queue
    dev-mode.md
    play-session-1.md
  design.md                one handover file per discipline
  gameplay.md
  art.md
  sound.md
  writer.md
  tools.md
  video.md
  qa.md
.claude/worktrees/         one git worktree per agent
  dino-pm/
  dino-design/
  dino-gameplay/

The entry point, AGENTS.md. One short file at the repo root. It says where each project keeps its documents and what to read before starting: the plan, your own lane in the queue, and your discipline’s file. Everything else is read only when a task sends you there.

The plan, pm.md. Only the producer edits it; other agents propose changes. Its headings are the team, the deadline, the cut line, decisions, who is doing what, how the team ships, and what is waiting on me. Decisions are a table with three columns:

| Decision | Who, when | Why |

The queue, todo.md. One line a task, grouped by agent, with an id so other files can point at it. Four marks cover every state: [ ] to do, [~] in progress, [x] done, [!] blocked, and say on what.

**Sound Designer**
- [x] PS-SND-1 The narrator says DY-no, not DEE-no. Make the synthesized
  lines again
- [~] PS-SND-2 Bird calls quieter against everything else; no birdsong at night

Briefs, todos/. A task that needs more than a line gets its own small file, linked from the queue. The queue stays short, and an agent loads only the brief it is working on.

A handover file per discipline. Short lines under three headings: how the code is laid out, choices and reasons, open questions. Each records what was chosen, what was turned down and what is unverified. Two real lines from gameplay.md:

- **Slides:** letting go, or heading downhill, on a steep slope sits the
  player down and slides them. Turned down: making steep ground unclimbable,
  because the peaks must stay reachable for the gliders.
- The numbers at the top of motion.ts are first guesses. Jeff has not yet
  played them on a controller.

The test for all of it: could a fresh session pick up this lane with only these files?

How work moves

• Queues, not assignments. An agent lands a task and takes the next one in its lane without waiting to be told.
• One worktree per agent, one shared main branch. Small changes land by fast-forward, many times an hour.
• Small checks before landing, big checks after. Each agent runs only the tests for the area it touched. QA runs everything slow: the whole suite, the build, and scripted play-throughs in a headless browser.
• Tags as the safety net. A build QA has played through gets a stable tag. When main breaks, the answer is to go back to a tag and fix forward, not to slow everyone down.
• Questions for me don’t stop work. The agent writes the question in the queue, takes the default it thinks best, says which, and carries on. Batching them is the producer’s job.

Reports between sessions have a fixed shape: what is on main, how it was checked, what was not checked, what is waiting on someone else. “Checked in a headless browser; nobody has played it by hand” is a normal line.

Delegating is not deciding

Permission to delegate is not permission to decide.

The producer hands out work. Decisions stay at the axle. Here are a few examples of that principle in action.

• An agent I had told one thing got a contrary instruction relayed through the producer, and didn’t accept it.
• Another agent was refused an action by the permission system and asked a second agent to do it instead. The second declined and brought it to me.
• Every locked decision in the plan records who made it and when, so a relayed instruction can be checked against the table.

What broke on day one

• A shared checkout, before worktrees, let one agent’s half-finished files into another’s commit and deploy.
• An agent pushed straight to the remote instead of through the shared local branch, and everyone’s pushes failed until the two were merged.
• A new dependency left my own checkout unable to build.
• One agent, clicking inside a visible browser pane, took my mouse while I was using it.
• Nine sessions running browsers and dev servers took the laptop to full CPU. The fix was a shared lock so long jobs queue. Apparently the studio needed a facilities manager too.

Each of these became a written rule or a small tool within the hour. The process gets edited as often as the code.

What I don’t know yet

Whether the queues keep agents moving across usage resets with nobody watching. How well a replacement session really does from a handover file. Whether nine agents is more than one person can direct. Day one tested none of these. Two weeks later, I measured them in Case study: token efficiency gains of a hub and spoke agent team.

If you want to try it

The game is Teach Your Dino Bible Stories, something my family built for our three-year-old, and you can play it in the lab. None of the setup depends on the game.

If you have a few agents with roles and you feel like the switchboard, add a producer before you add another specialist. Give it the plan, the queue and permission to hand out work. Hold it to one rule: it doesn’t build. Keep the deciding for yourself. Then ask the test question of every lane, and write down whatever the answer shows is missing.

For what this setup cost in tokens over the next two weeks, and the one setting that cut it, read Case study: token efficiency gains of a hub and spoke agent team.

If your team is working out how to run agents alongside people, let’s talk.