One agent or several? A decision guide

Start with one agent

The default answer is one. Keep a single agent whenever the steps share the same information, permissions, and owner. Different steps are not a reason to add agents; different boundaries are.

One agent is easier to explain, review, and improve, and it leaves one activity trail to read in the dashboard when something looks off. The industry advice points the same way: start with the simplest design and add complexity only when it demonstrably helps.

How to judge it: if you can describe the whole job in one sentence and point to one place to check the result, one agent is right.

The failure case is splitting by task step—a “research agent” handing to a separate “writing agent”—when both read the same sources under the same permissions. The writer can no longer see why the researcher trusted a source, so it drifts off-topic, and now you debug two logs instead of one. The real trade-off to watch is the opposite risk: a single agent’s permissions can quietly creep broad over time. When they do, that is your signal to reconsider—not the number of steps.

Split when boundaries are real

Add a second agent when the work crosses a boundary you can name in one sentence. In practice, a real boundary is one of four things:

• Access—one half must reach data or tools the other should never touch.
• Action risk—one half does something public, irreversible, or under your name; the other only reads and drafts.
• Schedule—one half runs on a different cadence or trigger.
• Evaluation—one half produces a result you need to judge on its own terms.

Why it matters: separation buys real containment. A read-only research agent that can never publish, paired with an approval-gated publishing step, means a research mistake can never reach the public by accident. That is a boundary worth the coordination it costs.

How to judge it: finish the sentence “this half must never ____.” If you can fill the blank with something concrete, split there. If the blank stays vague, keep one agent. The failure case is splitting on a boundary you cannot name—a “summary agent” feeding a “formatting agent” that share the same data and permissions—which buys a handoff and a second log for zero containment.

Compare the trade-off

Every split trades simplicity for specialization. The table shows what moves in each direction so you can decide with eyes open rather than by which diagram looks more capable.

How to judge it: a split earns its place only if the specialization column solves a problem you actually have. Cost is the trap most founders miss—more agents mean more runs and more context to reprocess. One published engineering account put a multi-agent job at roughly fifteen times the token use of a single chat, worthwhile only when the task genuinely parallelizes. The failure case is copying an architecture because it scored higher on someone else’s benchmark, then paying that overhead on work that was never parallel to begin with.

Use the handoff test

Before you split, write the exact note one agent would hand the next. If that handoff fits in a short, structured brief—a source list and a draft, say—the boundary is real and the split will hold. If the only way to make the second agent work is to copy the entire prior conversation into it, that is not a boundary; it is a leak, and you have two agents pretending to be one.

Why it matters: agents that cannot see each other’s reasoning make confident, conflicting choices. One writes for a formal audience while the next assumes a casual one, and the final result reads like two people who never met. A clean handoff prevents that by carrying its own context.

How to judge it: could a person read only the handoff brief and continue the work correctly, without the first agent’s full history? If yes, split. The trade-off: designing a crisp handoff sometimes takes more thought than simply keeping one agent—and if it does, that is often your answer.

A practical rule

Keep one agent until one of three things happens: its permissions grow uncomfortably broad, its context becomes confusing to follow in a single trail, or a specialist step can be judged independently and needs to be. Split for that measurable reason, not because “multi-agent” sounds advanced.

One rule holds no matter how many agents you run: accountability does not split with them. You remain the single owner of the workflow’s result, and the dashboard should always show you one place where the buck stops. If a split ever blurs who answers for an outcome, it has cost you more than it bought.

How to judge it: revisit the decision on a fixed schedule, not on impulse. If none of the three triggers has fired, the simpler design is still winning.