Multi-agent workflows need boring boundaries
Why useful AI agent workflows depend less on clever orchestration and more on scope, handoffs, and evidence.
The phrase “multi-agent workflow” makes the whole thing sound grander than it usually needs to be.
Most of the time, the useful version is not a swarm of digital specialists dramatically solving the future. It is three or four small tasks with clean boundaries, sensible handoffs, and enough evidence that a person can decide what to trust.
That is less exciting. It also works better.
Parallel is not automatically better
Running several agents at once feels powerful. One can audit the code. One can draft the copy. One can check SEO. One can run QA. Everyone is busy. The dashboard looks alive.
But parallel work only helps when the lanes are genuinely independent.
If every agent needs the same unresolved decision, you have not created a workflow. You have created duplicated confusion. If two agents can edit the same files without coordination, you have created a merge conflict with better branding. If nobody knows which report owns the truth, you have created a meeting.
The boring question comes first: can this work be split cleanly?
Give each agent a lane
A good agent lane has a job title and a stop sign.
Audit this route. Compare these files. Draft this one post from this supplied material. Check metadata and redirects. Review accessibility risks. Do not fix unrelated issues. Do not rename slugs. Do not invent facts. Report blockers instead of guessing.
The stop sign is the important part. Without it, agents tend to be helpful in the least helpful way: by expanding the task until the output is difficult to review.
Specialisation is useful because it reduces context, not because it makes the agents sound like a tiny consultancy.
Handoffs need evidence
A handoff that says “looks good” is not a handoff. It is a vibe in a raincoat.
Useful handoffs include paths, checks, assumptions, risks, and the exact thing the next worker needs to know. If an agent says a file uses a certain pattern, it should name the file. If it says a command passed, it should name the command. If it softened a claim because it could not verify it, that should be visible.
This matters because multi-agent workflows can hide uncertainty. One agent makes an assumption, another builds on it, a third summarises the outcome, and suddenly the original wobble has been laundered into confidence.
Evidence keeps the chain honest.
The human still owns the integration
The more agents you use, the more important integration becomes.
Someone has to notice that the SEO recommendation conflicts with the brand voice, that the QA concern is real but out of scope, that the content draft is good but too close to an existing article, or that two correct suggestions create a worse whole when combined.
That someone is not a rubber stamp. They are the editor of the system.
I like multi-agent workflows when they make that editing job easier. They can collect context, test alternatives, find risks, and reduce the cost of trying things. They are less useful when they create a pile of plausible outputs and call the pile strategy.
Simple workflows survive contact with real work
The agent workflows I trust are usually plain.
One agent investigates. One implements. One reviews the narrow change. The commands are listed. The unresolved questions are named. The final decision stays with the person responsible for the work.
That shape is not glamorous, but it respects the reality of production work. Real projects have constraints, history, taste, technical debt, client context, and edge cases with names. A good workflow carries those constraints forward instead of sanding them off.
Multi-agent work is not about making the process more elaborate. It is about putting the right kind of attention in the right place.
The boundaries are the feature.
Designing for uncertain answers gets at the same habit from the interface side: trust improves when uncertainty is handled clearly.