How to Run Multiple Claude Code Agents

I don't write code by hand. I build software by directing AI agents, and on a normal day I run multiple Claude Code agents at once: five to ten sessions, across different codebases and different companies.

The first version of that was a mess. The mess taught me the whole method.

The bottleneck was me

A single coding agent does one thing at a time, and it asks you questions while it does it. So in July I ran five to eight of them by hand. One window held the plan. I copied a prompt out of it into a new session, waited, then pasted the session's report back in.

It worked. It also made me the bottleneck.

Every session waited hours for a paste that took seconds. The agents were fast. The human routing work between them was not. I had built a fleet of tireless workers and put the slowest possible manager in charge of it: me, switching tabs.

That is the trap with any new kind of leverage. You add capacity, and the constraint moves to whoever coordinates it. If that is you, you have hired yourself into a full-⁠time job.

How to run multiple Claude Code agents without becoming the bottleneck

The fix was to take me out of every step where a file could stand in for a paste. Four pieces do the work.

1. One chair. One long-lived conversation holds the map. It writes every prompt, reads every result and never builds a feature itself. Its whole job is coordination, so mine doesn't have to be.
2. One folder per job. Each piece of work gets its own git worktree, a separate working copy of the code on its own branch. Two agents never type into the same files, so they never trip over each other.
3. A written prompt, launched in the background. The chair starts each session itself, with the model and the effort spelled out. Nobody sits at that session's keyboard, so it never stops to ask a question. Everything it needs to know is in the prompt.
4. A briefing file, not a chat message. Every session ends by committing a report to the repository: what it did, what it found, what is left. The chair reads the file, never the chat.

What reaches me is one short message: what landed, what is running, and the one decision that is genuinely mine. Everything else is a file a fresh conversation can pick up and read.

Every rule was written after something broke

None of this came from a whiteboard. Every rule in the method was written after something went wrong on a real fleet, and the damage got measured.

A session launched without an explicit model inherits whatever you last selected, which is usually the most expensive one on the account. A swarm of fifty helper agents on that model used up a full five-hour usage window in one call, and the top model's allowance for the whole week with it. So now every launch names its model and its effort, in the command and in the line that reports it.

A finished session once sat unnoticed for twenty-five minutes while the chair was busy answering questions inside one long turn. So now there is a check the chair runs before it takes each new ask.

That is the pattern I trust most. A rule that keeps getting broken does not need another sentence. It needs a check at the moment of action.

Memory fails. Good intentions fail. A check that runs every time does not get tired.

What it adds up to

This is how I build everything now. My own operating system, the software I run my life and companies on, runs more than 90 scheduled jobs. It was built through more than 800 sessions and more than 900 released versions, without me writing code by hand.

A few years ago, that would have needed a team of engineers. Today it needs a method, and the discipline to follow it when you are in a hurry.

Why I published the method

I put the whole thing on my GitHub as ai-orchestrator: thirteen short chapters, the templates, and a few small scripts that turn the rules into checks. It works with Claude Code, Codex, Gemini CLI, Cursor and more, and it needs nothing beyond git and Python.

I published it because it is the clearest proof of how I think. The same thinking runs every system I build at Brauto Labs: one source of truth, one place to see what is happening, and automation only where it has earned its place. The agents are the leverage. The files and the checks are the floor they stand on.

What travels, even with one agent

You don't need ten agents to use the idea:

1. Write it down where the next worker will read it. A file outlives a conversation, and the next worker might be you next week.
2. Make one place the map. If the map lives in your head, you are the bottleneck.
3. Turn every repeated mistake into a check. The second time something breaks the same way, stop writing reminders and build the thing that catches it.

Questions people ask me

Do you need to know how to code to run multiple AI coding agents?

I don't write code by hand, and everything I build ships through agents. What you do need is to know what you want, to judge whether it works, and to write both down clearly. The agents do the typing. The checks do the catching.

How many agents can one person run at once?

My normal day is five to ten sessions. The real limit is how many results you can read and decide on, which is why every session ends in a short file and a single question at most. Cost is the other limit: every session spends from the same plan, so each one is launched on purpose, with its model named.

Does this only work with Claude Code?

No. The method is files and git, so it works with Claude Code, Codex, Gemini CLI, Cursor and other agentic coding tools. The commands differ from tool to tool. The rules don't.

The agents get better every month. The system around them is the part you own.