Multi-Agent Workflows Beyond Prompt Chains

A prompt chain has three chronic weaknesses. First, error propagation: a slightly wrong classification in step one becomes a confidently wrong action in step four, with no checkpoint in between. Second, opacity: when the chain misbehaves, you have a wall of concatenated text instead of a trace showing which step diverged. Third, everything is runtime improvisation — the model decides what happens next, so two identical inputs can take different paths.

The fix is to stop encoding structure in prose. A workflow is an executable graph: agents, conditions, loops, and approvals as explicit nodes, with edges defining exactly how execution flows. The model still does the intelligent work inside each node, but the shape of the process is deterministic, versioned, and auditable. That distinction — improvised versus declared structure — is the whole argument.

Most business processes map to a directed graph: classify the ticket, then enrich it, then act on it, with branches where judgment forks. In a workflow, each step is a dedicated agent with only the tools that step needs, and a Condition node handles the branch — deterministically, based on the prior step’s output.

The practical win is scoped failure. When enrichment breaks, you see the enrichment node fail in the trace; the classifier and the writer are untouched and individually testable. Compare that to debugging one mega-agent whose prompt does all three jobs. Smaller agents also mean smaller privileges — the classifier needs read access, only the final node needs write access, and policies can enforce that split per agent rather than granting the whole chain the union of all permissions.

Some work is the same judgment applied many times: score 500 leads, summarize 100 tickets, review every file in a release. A prompt chain handles this by stuffing the list into one context window — which degrades quality as the list grows and gives you a single opaque output.

The MapReduce pattern runs a mapper agent over each item in parallel, then collapses the results with a reducer agent. Each item gets full attention and its own trace entry, so when lead #347 is scored strangely you can inspect exactly that invocation. Parallelism also changes the economics: a batch that would take an hour sequentially finishes in minutes, and per-item cost is visible instead of buried in one giant run. If a batch job has you tuning prompts to “be thorough with every item,” that is the signal to reach for fan-out instead.

Open-ended tasks — investigate this incident, research this account — resist a fixed graph because you cannot enumerate the steps up front. The manager-worker pattern handles this: a manager agent decomposes the task at runtime and dispatches sub-tasks to specialist workers, then assembles the result.

The trade-off is real and worth naming. You give back some determinism — the manager chooses the decomposition — in exchange for flexibility. What you keep is everything else: each worker is still a scoped agent with its own tool list and guardrail profile, every delegation still lands in the trace, and policies still bound cost and time for the whole run. Use manager-worker when the task genuinely varies; use it as a default and you are paying determinism for flexibility you did not need.

Two unglamorous features do the most production work. Approval nodes pause execution until a human reviews — the difference between an agent that drafts a refund and one that issues it. Because approval is a node, not a convention, the pause is enforced by the platform and recorded in the run history as Awaiting approval.

Versioning is the other. Every publish creates a new workflow version, and rollback is one click — so a bad change is a five-minute incident, not an evening. Combined with trace inspection in Monitor, this gives multi-agent systems the operational properties you expect from any production service: deployable, observable, reversible. Prompt chains offer none of these. That, more than any benchmark, is why orchestration wins.