firaz.
← writing
aiosJun 24, 2026·6 min read

how to manage multiple ai agents without losing the plot

how to manage multiple ai agents is not just a search term for aios. it is the operating pattern firaz is building around agents, loops, terminals, and real work.

if you're asking how to manage multiple ai agents, you've already passed the fun part. one agent in a chat box is a toy. two agents is a demo. five agents running at once — claude on a refactor, codex on a review, a terminal job churning, two background loops waking on timers — is a coordination problem that no chat window was built for.

i hit this wall building aios. the leverage is real: agents do the work while i talk to myself between meetings. but every agent you add creates coordination debt. more output, yes. also more places to lose the thread, more half-finished branches, more "wait, which agent was doing that?"

this is the part nobody warns you about. so here's the operating pattern i actually use.

more agents is leverage. it's also debt.

an agent is cheap to spin up. that's the trap. you fire off three because you can, and now you're the bottleneck — context-switching between three streams, none of which know about the other two.

the cost isn't the agents. it's you. every switch, you reload state. what was this one doing? did the other one finish? is that branch safe to merge? that reload is the hidden tax of ai coding, and it scales worse than linearly. two agents you can hold in your head. six you cannot.

so the goal isn't "run more agents." it's "stay the supervisor without becoming the integration layer." the rest of this is how.

separate discovery, execution, verification, reporting

the single biggest fix: stop asking one agent to do everything. a request like "figure out the bug and fix it and make sure it works" is four jobs wearing one coat, and when it fails you can't tell which job failed.

split the pipeline into four roles:

  • discovery — understand the repo, find the right files, map what changed. read-only. no edits.
  • execution — make the change. one task, one branch.
  • verification — run the tests, open the app, check it against the actual product decision. adversarial. its job is to find the problem, not to agree.
  • reporting — write down what happened so tomorrow-you doesn't rebuild the context.

the value of the split is that each stage hands off something inspectable. discovery returns a map. execution returns a diff. verification returns a verdict. when something breaks, you know exactly which stage lied to you. one mega-agent gives you a wall of text and a shrug.

this maps cleanly onto which tool you reach for. claude code earns its keep on the messy execution pass — deep reasoning through a tangled change. codex is sharp on repo-native discovery and review loops. you don't have to pick a winner. you assign roles.

make every agent leave a receipt

posting more is not the hack. posting proof is. same rule applies inside your own workflow.

if an agent does work and leaves nothing behind — no branch, no log line, no note, no diff you can read — it didn't really happen. you have a vibe, not a result. the fix is a hard rule: every agent leaves a receipt.

a receipt is anything you can inspect after the fact without asking the agent to restate itself:

  • a named branch with a real commit message
  • a log of the commands it ran and what they returned
  • a note recording the decision, not just the output
  • a screenshot of the app in the state it claimed to produce

this is the difference between "the agent says it cleaned the discord and queued the content" and being able to open the branch, read the log, and see it. when you supervise five agents, you cannot re-interrogate each one. you read receipts. receipts are how you scale trust without re-running the work.

it's also why i build the workspace around receipts on purpose. terminals, files, notes, screenshots, memory — those aren't decoration. they're the audit trail that makes parallel agents safe to leave alone.

centralize the command surface

here's where most setups quietly fall apart. one agent lives in a terminal. another in a chat. docs in a browser tab. logs in a different terminal. the plan buried in a session from yesterday. the work is real but it's scattered across six surfaces, and you are the only thing holding them together.

that's a workspace problem, not a model problem. most ai tools still feel like a chat box with ambition — fine for asking questions, bad for running work. real work needs the terminal, the browser, the files, the agents, the notes, the screenshots, and the memory in one place. that's why aios is a shell, not another chat app.

the fix is a single command surface — one place where you can see every agent, every job, every receipt at a glance, and step in without app-switching. i think of it as an ai agent command center: the panes are the agents, the terminals, the browser, the files, the notes. you supervise from one screen instead of chasing tabs.

for a real build session i usually want five surfaces visible — an agent pane for the task, a terminal for commands and logs, a browser for the app or docs, a file pane for the project, and a scratch pane for decisions. when an agent finishes, its receipt is already in front of me. i approve or i don't. i don't go hunting.

that's also the whole point of treating it as an ai coding agent workspace rather than a smarter agent. the agent is one pane. important, not sacred. the surface around it is what lets you run more than one without losing the plot.

promote repeatable patterns into loops

once a pattern survives a few runs — discovery, execution, verification, reporting, all leaving receipts — stop doing it by hand. promote it into a loop.

a loop is a background agent that wakes on a timer, picks one task, builds it in an isolated branch, and waits for you to approve. that last clause is the entire safety model. the loop does the work; the human owns the merge. i've had six running on my machine at once. the honest version: leaving them fully autonomous over a weekend is a real gamble — you genuinely don't know if monday is clean shipped code or a pile of half-finished branches.

that's why the approval gate matters more than the autonomy. the loop is allowed to run unattended precisely because it can't ship unattended. it isolates its work in a branch and stops at the gate. you come back, read the receipts, and decide.

this is the top of the pyramid. discovery/execution/verification/reporting gives you a clean unit of work. receipts make it inspectable. the command center lets you supervise many at once. loops take the patterns that have earned your trust and run them on a timer so you only show up for the decision.

where to start

don't try to stand up six loops on day one. you'll spend the weekend cleaning up after agents that had no receipts and no gate.

start with one pipeline. split a single task into the four roles, force each stage to leave a receipt, and run it from one surface so you can actually watch it. once that feels boring — boring is the goal — add a second agent. then promote the pattern into a loop.

if you want to see the operating pattern instead of reading about it, watch the demo — it's the loop running end to end, receipts and all. and if you're a builder making ai operate across terminal, browser, files, and agents — not a prompt-dumper — the paid discord is where the first hundred founders are working this out in the open. it's hand-approved, so come in and say what you're building.

the model keeps changing. which agent is sharpest this month doesn't matter much. where the work lives, and whether you can supervise it without losing the plot — that's the part worth getting right.

written by firaz fhansurie