Stop Building Agent Soup: Use Compiler-Style Agent Workflows
“Agent soup” is not a criticism of multi-agent systems. It is a failure to define what moves between agents, which transformations are legal, and how the system rejects invalid work.
The useful part of the compiler analogy is not that product work can become perfectly deterministic. It is that ambiguous intent can be lowered into a typed intermediate representation, checked in stages, and executed only when its contracts hold.
Conversation pipeline versus compiler pipeline
| Conversation pipeline | Compiler-style pipeline |
|---|---|
| Each agent receives prose and reinterprets it | Agents exchange a versioned workflow specification |
| Roles imply authority | Capabilities and policy grants define authority |
| “Looks good” is the acceptance test | Named checks evaluate explicit acceptance criteria |
| Retries repeat the entire conversation | Failed stages resume from an effect journal |
| Errors are natural-language apologies | Errors are typed, attributed, and routed |
| More agents mean more interpretation | More workers can share the same contract |
The pattern: Agent Workflow Compiler
Intent + context
│
▼
[1 Parse & normalize] ──syntax error──▶ clarify with owner
│
▼
[2 Type & policy check] ──invalid────▶ deny or require approval
│
▼
[3 Lower to workflow IR]
│
▼
[4 Plan & schedule] ─────no route────▶ unsupported capability
│
▼
[5 Execute stages] ───────tool error──▶ bounded retry/recovery
│
▼
[6 Verify artifacts and effects]
│
├──fail──▶ repair within scope or stop
▼
[7 Commit + attest]The workflow IR—the intermediate representation—is the center of the design. Prompts may create or explain it, but execution consumes the structured form.
What belongs in the intermediate representation
A useful workflow spec needs more than a goal and an agent name:
- Intent: the owner, objective, success definition, and immutable constraints.
- Inputs: typed references, data classification, provenance, and freshness requirements.
- Capabilities: required operations and the policy scope under which they may run.
- Stages: dependencies, tool contract, expected artifact, timeout, and retry policy.
- Acceptance: deterministic checks, evaluators, thresholds, and required human decisions.
- Effects: idempotency keys, preview/apply split, rollback reference, and receipt.
- Failure semantics: which errors stop, retry, degrade, repair, or escalate.
- Telemetry: trace fields, cost budget, retention, and redaction policy.
The specification does not have to contain every runtime detail. It must contain enough to prevent an executor from inventing authority or success criteria.
A concrete before-and-after workflow
Consider an agent that handles a customer refund request.
Agent-soup version: “Read the email, ask the billing agent what happened, decide whether the customer deserves a refund, process it, and send a friendly response.” This hides identity, limits, sources, concurrency, approval, and what happens if the payment succeeds but email fails.
Compiler-style version:
- Normalize the email into a request with customer and order references. Treat message content as untrusted data.
- Resolve identity from the account system; never trust identifiers supplied only in the email.
- Load the refund policy version and calculate the maximum automated amount.
- Produce a proposed decision with cited transaction evidence.
- Require human approval when amount, age, fraud signal, or policy ambiguity exceeds a threshold.
- Preview the payment mutation and bind approval to its exact hash.
- Apply once using an idempotency key; store the provider receipt.
- Send the response only after the payment result is known. If messaging fails, queue delivery without repeating the refund.
The model can help classify the request and draft the explanation. It cannot grant itself refund authority, redefine policy, or declare an external effect successful without a receipt.
The validation passes
| Pass | Question | Failure output |
|---|---|---|
| Schema | Are required fields present and typed? | invalid_spec with field path |
| Capability | Can the selected worker perform every operation? | unsupported_capability |
| Policy | May this principal perform the operation in this context? | denied or approval_required |
| Dependency | Is the graph acyclic and are all inputs produced? | invalid_graph |
| Effect | Are mutation, idempotency, and rollback semantics defined? | unsafe_effect |
| Acceptance | Can success be evaluated before commit? | unverifiable_outcome |
Fail early. A clarification before execution is cheaper than a reviewer reconstructing intent after five agents have acted.
Typed errors are part of the architecture
“The agent failed” is not actionable. A compiler-style workflow distinguishes:
invalid_spec: the owner must clarify intent.unsupported_capability: route to another worker or stop.policy_denied: do not retry with different wording.transient_tool_error: retry within the declared budget.verification_failed: repair the artifact without expanding scope.effect_unknown: reconcile with the external system before any retry.
The last case prevents one of the most dangerous workflow bugs: repeating a mutation because the acknowledgement was lost.
Where agents still use judgment
The pattern does not reduce every task to a static DAG. Agents remain useful for research, decomposition, implementation, critique, and recovery. The contract defines the envelope within which that judgment is allowed.
Open-ended discovery may need iterative specs. Creative work may use qualitative rubrics and human selection. Novel incidents may have no known recovery transition. In those cases, the correct compiler output can be “human decision required,” not fabricated certainty.
Adoption path
- Choose one costly multi-agent workflow and record its handoffs.
- Replace prose handoffs with one versioned JSON object.
- Add schema, capability, and policy validation before execution.
- Separate preview from external mutation.
- Add typed terminal outcomes and effect receipts.
- Only then add parallel workers or more specialized agents.
For direct agent-to-agent coding delegation, see the ACP handoff protocol. For the surrounding production controls, use the five-layer infrastructure model and the execution attestation design.
Download the workflow contract
I published a vendor-neutral JSON Schema plus a concrete refund-workflow example. Use them as a starting contract, not as a universal runtime.