The 6-Stage Pipeline
Stage 1: Strip the Assumed Solution
Clients describe solutions because describing problems is hard. Your first job is to reverse the compression. Remove the technology nouns ("agent," "LLM," "AI") and recover the actual process.
Ask three critical questions :
1."Walk me through the last five times a person did this." (Recovers the real process and undocumented exceptions)
2."What varied between them?" (Separates the deterministic spine from judgment)
3."What happens today when someone gets it wrong?" (Recovers the real error tolerance)
Exit Test: You can state the problem in a paragraph with no technology nouns in it.
Stage 2: Decompose into Units of Work
Break the stripped problem statement down into specific units of work. Each unit must have a verb, a defined input, and a defined output . For example, instead of "handle onboarding," a unit might be "Extract company and banking details from documents to create a structured record."
Exit Test: Every unit could be handed to a different person without a conversation.
Stage 3: Classify Each Unit
This is where the most value is created. Tag each unit into one of four classes to determine the AI model's role :
•Deterministic: A rule or lookup produces the answer. (No model needed; code it)
•Retrieval: The answer exists somewhere; the work is finding it. (Tool use; model locates and reads)
•Judgment: Requires weighing ambiguous evidence against criteria. (Core model competence)
•Generative: Producing new text for a human to read. (Model drafts, human reviews)
Exit Test: You have removed at least one unit from the model's scope. If everything is labeled "judgment," you haven't classified properly.
Stage 4: Attach Constraints
Constraints turn a generic design into a specific one. Collect constraints per unit, not globally. The most critical and often under-collected constraint is Error Asymmetry-which error direction is worse, and by how much? (e.g., A false positive on a sanctions screen is vastly worse than a false negative) .
Exit Test: For every unit, you can state which error direction is worse and roughly by what factor.
Stage 5: Run the Twelve Decisions
Run these architectural decisions in a fixed order, as later decisions depend on earlier ones . Key decisions include:
•Control Topology: Is it a workflow, an agent, or a conversation? (Default to workflow; agency is a cost you justify, not a starting point).
•Decomposition: Does a unit need to be a separate subagent due to context isolation, specialization, or parallelism?
•Tool Surface: Define boundaries-when to use a tool, and crucially, when not to use it.
•Verification Strategy: Match verification strength (deterministic check, independent model review, human review) to the error asymmetry.
•Autonomy Ceiling: Set hard escalation triggers that confidence scores can never override.
Stage 6: Emit the Specification
Finally, translate these decisions into six buildable artifacts :
1.Architecture Decision Ledger: Why this shape, and what was rejected.
2.Agent Roster: What exists and what each thing is for.
3.Tool Contracts: What the system can and cannot do.
4.Output Schemas: What comes out, and what null means.
5.Policy Documents: When it acts and when it stops.
6.Acceptance Criteria: How we know it works.