When Multi-Agent Is Wrong

If a script can read a manifest, transform it, and write an output, write the script. Our blog pipeline is a good example: JSON content goes through renderers and a generator. An agent does not improve a deterministic sitemap emission; it only makes the path harder to audit.

• Known inputs and a stable schema: use code.
• A one-off mechanical edit: use an editor or script.
• A short task with one clear owner: use one agent, if an agent helps.
• A decision requiring taste, context, or tradeoffs: keep a human in the loop.

The burden of proof belongs to orchestration. It should buy something measurable: independent work, a shorter critical path, or a review boundary that catches errors a single pass would miss.

• Context fracture: each worker sees a plausible slice and misses the constraint that matters.
• Handoff loss: a summary drops the exception, so the next worker confidently repeats the wrong assumption.
• Merge conflict: parallel edits are individually valid but incompatible in the real tree.
• Review theatre: a reviewer checks formatting while the architecture is already wrong.
• Supervisor bottleneck: workers finish faster than one person can validate their outputs.

We have seen enough of these patterns to treat a handoff as a risk surface, not a productivity statistic. A worker that is waiting on one decision is not parallel progress; it is a queued question.

In our own studio, a task earns orchestration when it has separable acceptance criteria and a useful validation boundary. One worker can inspect a code path while another writes an isolated change; a reviewer can then test the result against the brief. The separation is valuable because the work is genuinely separable.

A content batch can fit that shape when each article is an independent artifact and the generated output is checked afterward. A tiny copy correction does not. Neither does a bug whose cause is still unknown and requires one uninterrupted chain of evidence.

This is not an argument for a particular runtime. It is an argument for matching topology to the problem: one path for one path, branches for independent branches, and a human decision where the branches meet.

1. State the smallest correct outcome.
2. List the context every contributor must share.
3. Identify whether the work actually decomposes without shared mutation.
4. Name the validation that can reject a bad result.
5. If the answers are weak, use one agent or plain code.

Orchestration is an implementation detail, not a virtue.

The best architecture is the one that leaves the fewest invisible decisions between input and verified output. Sometimes that is a fleet. Often it is a function, a single agent, or a person with a terminal.