How to manage a team of AI agents as one person: the operator's playbook

One agent feels like magic. The third one turns into a mess. Here are the seven ways a small fleet of AI agents goes wrong for a solo operator, the habit that kills each one, and a first week to get from one agent to a team you can actually trust.

Published August 8, 2026 · By Dmitry Tolstoi · 9 min read

The first time you hand a task to an AI agent and it comes back done, it feels like you hired someone for free. So you start a second. Then a third. Somewhere around the third one, the magic quietly turns into a management problem you did not sign up for.

The hard part of running several agents is not talking to them. Prompting is the easy half. The hard half is the job any manager has: handing out work you can check, catching what went wrong before it ships, and knowing which worker to trust with what. I run a content operation this way, one person with a bench of agents, and almost everything that has bitten me falls into a short, repeatable list. This is that list, and what I do about each item.

Why the third agent is where it breaks

In short: with one agent your limit is how fast it produces; with several, your limit is how fast you can trust what they hand back.

With a single agent, you watch it work. You see the output land, you read it, you move on. The bottleneck is production, the agent removed it, and you feel ten feet tall.

Add more and the shape of the work changes under you. You cannot watch three windows at once. Two agents reach for the same file. One finishes in ten seconds and you have no idea whether those ten seconds were real. The scarce thing is no longer output. It is your attention and your judgement, and neither got cheaper when the writing did. Every failure below is a version of that one shift: generation got cheap, and checking did not.

The seven ways a fleet of agents goes wrong

In short: nearly every multi-agent mess is one of seven failures, and naming the one you have is half the fix.

Keep this list where you can see it. When something feels off, it is almost always one of these seven, and spotting which one tells you what to do next.

1. The confident "done" that isn't. The agent reports success it never achieved. The log says finished; the artefact is missing or broken.
2. Two agents on the same file. Parallel edits to one file, and whoever saves last wins. The other agent's work vanishes with no warning.
3. The silent money loop. One agent quietly retries the same failing step, burning tokens and dollars while you are looking at a different window.
4. The task that was a wish. "Improve the onboarding" has no finish line, so the agent drifts, invents scope, and hands back something you cannot check.
5. The over-privileged agent. An agent that can spend money or publish or delete on its own will eventually do one of those at the wrong moment.
6. The agent that forgot. A long session fills its context, the earliest instructions fall out, and it starts cutting corners it was told not to cut.
7. The model mismatch. Your most expensive model doing mechanical busywork, or a cheap one making a judgement call it was never good enough to make.

The rest of this guide is one habit per failure, in the order I would put them in place.

Give each agent a job, not a wish

In short: size every delegated task so you can verify it in under a minute; if you cannot, split it until you can.

"Improve the form" is a wish. It has no edge, so the agent guesses where to stop, and you get back a diff you have to study for ten minutes to trust. "Add validation to this one function so an empty email is rejected" is a job. You can read it and know in seconds whether it did what you asked.

My rule is plain: if I cannot check the result in under a minute, the task is too big, and I break it down before I hand it over. Small, checkable jobs also carry their own blast radius. When a tight task goes wrong, it goes wrong inside one function you are already looking at, not across half the codebase while you were away.

You are the verification gate now

In short: with a fleet, your real job stops being production and becomes deciding what is good enough to keep.

This is the mental switch most people miss. You are no longer the person who makes the thing. You are the person who says yes to it. Five agents produce more drafts in an hour than you could in a week, and every one carries your name if it ships.

Treat review as the work, not the interruption to the work. That means reading what came back properly, instead of skimming because it looks plausible. Plausible is exactly what a language model is built to produce, and plausible-but-wrong is the failure that costs you later. Slowing down at the gate is the whole point of having a gate.

Write down what no agent may do alone

In short: keep an explicit written list of irreversible actions that always need your sign-off, and give each agent the least access its job requires.

Some actions cannot be taken back. Money leaves. A message reaches a real person. A file is deleted. A page goes public. A key is exposed. For those, no agent acts on its own, and the list lives in a file, not only in your head, so it survives a tired night and a fresh agent that never read your mind.

Mine is short and blunt: anything that touches spend, send, delete, publish, keys stops and waits for a human yes. Everything else the agent runs freely. This is the oldest rule in security under a newer name, least privilege: give each agent exactly the access its job needs and nothing more. An agent that only writes drafts never holds the publish button, so it can never push one by accident.

Match the model to the job

In short: put a cheap fast model on mechanical work and your strongest model on judgement and the final review, and never swap those two.

You would not run the whole orchestra for one note. Renaming files, reformatting data, wiring up boilerplate: that is work a small fast model does well and cheaply, and paying premium rates for it is money on fire. The reverse mistake is worse. A weak model making a real decision, or writing the copy that represents you, fails in ways you notice only after it has shipped.

So I split by kind of work. Mechanical, high-volume work goes to the cheap model. Judgement, architecture and the last read before anything leaves go to the best model I have. That final review in particular is never delegated down; it is the seat where quality gets decided.

Give each agent its own room

In short: stop parallel agents from touching the same files by giving each one an isolated copy to work in.

Two agents editing one file at the same moment is a data-loss bug waiting to happen. Whoever writes last overwrites the other, and there is no error and no conflict, just work that silently disappeared.

The fix is boring and reliable: separation. Give each agent its own working copy, its own branch or its own directory, so their changes never land on top of each other. When two streams of work need to meet, they meet through a merge you can see and review, where a real conflict shows up as a conflict instead of a vanished afternoon. If two agents must share one resource, only one gets write access and the other reads.

Make "done" mean checked, not claimed

In short: never trust an agent's status report; trust the artefact it was supposed to produce.

The most expensive lesson I have learned running agents is that the report and the reality are two different things. An agent will tell you the tests pass, the file is written, the job is finished, and mean it, while the actual output is empty or broken. It is not lying to you. It lost the thread and filled the gap with a confident summary.

So I check the thing, never the claim. Did the file actually change on disk? Does the page actually return two hundred rather than a redirect to an error? Did the render actually contain the block, or a placeholder where the block should be? Build the habit of looking at the artefact, because a status line costs nothing to fake and an artefact cannot fake being there. This one habit catches more silent failures than any other on the list.

Your first week, from one agent to a small fleet

In short: add one agent at a time, and only widen access after each new habit is holding.

You do not get from one agent to five in an afternoon without recreating every failure above at once. Grow the team the way you would grow a real one, one hire at a time, with the guardrails in place before the headcount.

1. Day one, one agent, tight tasks. Run a single agent and only give it jobs you can check in under a minute. Get a feel for how it reports done versus what it actually did.
2. Day two, write the stop list. Put spend, send, delete, publish, keys in a file and decide that nothing on it happens without your yes. This is the guardrail everything else leans on.
3. Day three, add a second agent in its own room. Give the new one a separate working copy so the two can never collide. Practice reviewing two streams instead of one.
4. Day four, split the models. Move mechanical work to a cheap fast model and keep your best model for judgement and the final read.
5. Day five, verify by artefact. For every "done", look at the real output before you believe it. Make this a reflex before you scale, because it is the reflex that saves you at scale.
6. The weekend, add the third only if the checks held. If you spent the week reviewing more than firefighting, add one more agent. If you spent it firefighting, stay at two until the habits are automatic.

A fleet you can trust gets built one checked handoff at a time. The operators who run ten agents calmly did not start with ten. They started with one and never once skipped the gate.

Where this playbook comes from

This is drawn from running a real content operation on a bench of AI agents, one operator with no team, and from the failures that cost me time. Two shaped it most: agents that reported success they had not delivered, which taught me to check the artefact and never the log; and an agent that acted on something irreversible with no gate in front of it, which put the stop list in a file.

The security idea underneath the stop list, least privilege, is a standard practice worth reading up on in its own right. If you want the surrounding system, I have written up how one person runs a whole content factory without an agency and how to make the output look like a studio built it.