Chaining and Multi-Agent Orchestration

From the free book Delta: Closing the Specification Gap (Dhuri, 2026). The PDF is the canonical edition — figures, tables, and code formatting are simplified online.

How complex features get built right — and why they fall apart when the specification doesn’t travel

“One agent with a perfect specification produces one correct result. Five agents with a drifting specification produce five consistent results, all based on the same wrong assumption.” — The agent did not go rogue. It followed the specification it was given. The problem was the specification it was given was not the specification you wrote. In This Chapter

1. The Four-Stage Pipeline: Domain Model Contracts Implementation Tests
2. Why humans must own Stages 1-2 and agents can safely execute 3-4
3. Specification drift: the dominant multi-agent failure with an illustrative incident
4. Law 9: agents and vague specifications produce systems of bugs
5. Six multi-agent patterns, their failure modes, and defenses LAW 9 OF ENTERPRISE AI PROMPTING

An agent given a vague specification does not produce one bug. It produces a system of bugs. A human given a vague specification writes one class, gets confused, and asks for clarification. An agent given the same vague specification writes fifteen files, a test suite, a migration, and a deployment manifest — all internally consistent, all based on the same wrong assumption. The cost of specification vagueness multiplies by every file the agent autonomously creates.

10.1 The Four-Stage Pipeline Complex features have four logical stages. AI assistance adds value at every stage. Human expertise is non-replaceable at the first two. Most teams get this backwards — they use the AI to help think through the domain model (Stage 1) and let the agent autonomously execute the contracts (Stage 2). The model is terrible at Stage 1 and very good at Stages 3-4. The discipline is keeping the humans where they belong. Stage

Input

Output

Review Gate

AgentExecutable?

1 — Domain Model

User story + business rules

Entities, aggregates, invariants, events

Are the invariants correct for your domain?

No — requires domain expertise.

2— Contracts

Stage 1 output

Service interfaces, commands, all error cases

Is every business failure named?

No — requires domain expertise.

3 — Implementation

Stage 2 + codebase context

Handler/service implementations

Does it honor the contracts?

Yes — Claude Code, Cursor Agent.

4 — Tests

Stage 3 output

Unit tests, edge cases, coverage

Critical paths covered?

Yes — Claude Code, Cursor Agent.

ANTI-PATTERN — Skipping Stage 1-2 and Delegating to the Agent AVOID: ”Build the insurance policy issuance feature. Validate inputs, persist the policy, send a confirmation email.”

USE: Run Stage 1 (domain model) and Stage 2 (interface contracts) with human review. Only then delegate Stage 3 implementation to the agent. Why: Without Stages 1-2, the agent invents the domain model and the error cases. At Stage 4, the tests pass — against the invented domain, not yours. The code ships. The incident is four months later when an edge case in the invented domain meets your actual business rules.

10.2 Specification Drift — The Silent Killer PATTERN — The Agent That Renamed Everything

PATTERN-4074

A development team used a two-agent pipeline: a design agent produced the domain model (Stage 1-2), an orchestrator summarized it and passed it to an implementation agent (Stage 3). The design agent described the aggregate as ’PolicyIssuance’. The orchestrator summarized it as ’PolicyCreation’ when constructing the implementation prompt — the terms sounded equivalent. The implementation agent built a consistent, well-tested ’PolicyCreationService’ with ’CreatePolicyCommand’ and ’PolicyCreatedEvent’. The team’s actual domain used ’PolicyIssuance’ throughout — in the database schema, in existing events, in the audit log, in the compliance documentation. The integration failed in eleven places. The fix took four days. The root cause: an orchestrator summary had silently renamed a domain concept.

THE COST OF THIS MISTAKE Incident: Specification drift: orchestrator renamed domain concept ,→ from PolicyIssuance to PolicyCreation Total cost: 4 days integration failure + 11 broken integration points ,→

+ compliance documentation inconsistency

Time to resolve: 4 days to identify and refactor, 1 additional sprint ,→ for compliance review update

Prevention: "Pass original specification verbatim as immutable XML. ,→ Never summarize. Never reformulate."

BEFORE — Tier 1 (What most developers type) "ORCHESTRATOR SUMMARY: The system should create insurance policies ,→ with validation and events." AFTER — Tier 3 (Specification Frame) "<original_specification>[verbatim copy of Stage 2 interface ,→ contracts and domain invariants — unchanged, unformatted, ,→ exactly as written by the domain expert]</ ,→ original_specification>
Complete the task in <

,→ original_specification> exactly as written. Do NOT interpret, ,→ summarize, or reformulate it." Result: Orchestrator summary loses domain vocabulary and collapses ,→ nuance. Verbatim XML preserves every term, invariant, and ,→ constraint exactly as the domain expert specified them.

10.3 Six Multi-Agent Patterns Pattern

Use Case

Primary Failure

Prevention

Sequential Pipeline

DomainContractsImplTests

Specification drift

Pass verbatim spec as immutable XML

Parallel Fan-Out

Simultaneous independent sub-tasks

Style inconsistency

Add shared constraints to every worker

CriticGenerator

Generator + adversarial Critic + refinement

Non-termination

Max 3 iterations + explicit acceptance criteria

OrchestratorWorker

Domain-specialist workers

Worker ignores original intent

Worker always receives original spec as immutable context

Human-in-theLoop

High-risk or irreversible decisions

Too many checkpoints

Gate only irreversible actions: DB writes, deploys

Verification Agent

Second agent validates first

False confidence (shared blind spot)

Use different framing for validator; different instruction set

QUICK WIN — 15 minutes

Look at your last multi-agent workflow. Does the implementation agent receive your original interface specification verbatim, or does it receive a summary? Change any summary to a verbatim XML block this week. Measure the quality difference in the first output.

Key takeaways

• The Four-Stage Pipeline: AI adds value at all four

stages, but humans must own Stages 1-2. Agents can safely execute 3-4 when Stage 2 contracts are complete and precise. + Law 9: agents + vague specs = systems of bugs. All consistent. All based on the same wrong assumption. + Specification drift is the dominant multi-agent failure. Fix: pass original specification as verbatim immutable XML. Never let the orchestrator summarize. + Human review gates belong only at Stage 1-2 output. Reviewing every agent-generated file defeats the productivity advantage. + Six patterns, six failure modes. Know which pattern you are using and which failure mode to design against.

TRY IT NOW

1. Map your team’s most recent complex feature to the Four-Stage Pipeline. At which stage did specification precision most degrade? What was the cost of that degradation?
2. If your team uses multi-agent workflows: audit one for specification drift. Does the implementation agent receive the original spec or a summary?
3. Design the Stage 2 review checklist for your domain. What three questions must a domain expert answer before an agent can proceed to Stage 3?

UP NEXT — Chapter 11: Prompt Files — Treat Your Prompts Like Code

The prompt that took your team two months to get right is currently in someone’s chat history. Chapter 11 shows you how to versioncontrol it, test it, and make it available to everyone on the team.

80