MULTI-AGENT WORKFLOW DESIGN
How many agents, who holds which tool, and where the run has to stop.
Most automation briefs do not need agents at all — they need a scheduled script and a database query. Workflow design is where that gets decided honestly. I map the steps, mark which ones involve judgement and which are deterministic, and only the judgement steps get a model. Everything else gets plain code, because code does not hallucinate and costs nothing per run.
When the work genuinely needs several agents, the shape matters more than the prompts. I have built a five-agent fleet behind a gateway orchestrator, where each agent holds only the tools its role justifies, and a twenty-agent mesh where the hard part was not intelligence but routing — which agent gets the request, what it may pass on, and what the orchestrator does when one stalls.
The deliverable is a document and a diagram, not a running system. It names every agent, its tools, the format each handoff must take, the approval points, the retry and timeout policy, and the expected cost per run at three volume levels. You could hand it to any competent developer to build. Usually that ends up being me, but it does not have to be.
WHAT I DO
- Workflow map — every step marked deterministic code, model judgement, or human decision, with the hours each one costs today
- Agent roster with role-scoped tool lists, so no agent holds a credential its job does not need
- Handoff contracts — the exact payload shape passed between steps, so one agent rewording its output does not break the next
- Orchestration pattern chosen on purpose: single gateway, sequential chain, or parallel fan-out with a join step
- Failure policy — retries, timeouts, what happens to a half-finished run, and which failures are allowed to interrupt a person
- Build-vs-buy comparison with real numbers per step, like a managed per-minute API against a self-hosted open-source model on a VM started and stopped on a schedule
- Cost model per run at low, expected and worst-case volume, so a traffic spike is not a surprise invoice
HOW I WORK
- 01
AUDIT
I sit with the people doing the work and count the steps, the handoffs and the hours, before proposing anything.
- 02
CUT
I delete steps that should not exist and move everything deterministic out of the model layer into plain code.
- 03
ARCHITECT
I draw the agent roster, tool scoping, handoff formats and approval gates, then price every step at three volumes.
- 04
REVIEW
I walk the design through against your worst edge cases and revise it until nobody in the room is guessing.
BEST FOR
- Work that spans three or more systems and currently lives in one person’s head
- A failed automation attempt where nobody can say which step actually broke
- Buyers who want the architecture priced and written down before committing to a build
- A genuine volume problem — the same decision made hundreds of times a week
NOT THIS
- Not the build itself. This page is the design document; writing a single agent is the custom agents page, and the content-specific pipeline has its own page as well
- Not a drag-and-drop automation canvas. I design systems that run as code on a server you own — slower to change, far easier to debug at 2am
- Not a multi-node cluster design. Honest scale: solo, one VM, one tenant. If your volume needs a platform team, the audit will say so instead of quoting you
THE PROOF
Published case studies from ai orchestration work. Each one names the client and shows what was delivered.
STRAIGHT ANSWERS
REST OF AI ORCHESTRATION
MAKE A
WISH.
Tell me what you're building. I'll tell you how loud it can get.
- /01
YOU WRITE
Tell me what you're building and what's in the way. Two lines is enough.
- /02
WE TALK
A 30-minute call, booked within 7 days. Real questions, no pitch theatre.
- /03
YOU GET A PLAN
Scope, timeline and an honest number, usually within a week.