Worked Decision Table: Seven Pipeline Archetypes
Here is how the WOS plays out across seven real-world agent pipeline types. Scores are based on typical production configurations, not theoretical best cases.
The deep research agent technically scores above 60 because several of its factors simultaneously peg at 10. The framework caps at 60; any archetype scoring above 50 should be treated as a strong model-driven signal with no further deliberation needed.
The CI/CD release note generator lands exactly at 18 — the boundary. That is intentional: this is a genuinely ambiguous case. A simple one-liner template (pure deterministic) works fine for most releases, but a large breaking-change release often benefits from a model generating a prose summary. The WOS guides you toward a hybrid: script the structure, model the prose sections.
The Three Hybrid Patterns
The 18–30 band is the most difficult to implement correctly. Three patterns cover virtually all hybrid cases.
Pattern 1: Scripted Spine, Model-Filled Leaves
The orchestration code controls all routing, branching, retries, and tool dispatch. The LLM only generates content at terminal nodes — it does not decide what to do next. This is the right pattern when F2 (branch count) scores high but F1 (task ambiguity) scores low. The code writer can enumerate all branches; they just cannot write the prose or extracted value at the end.
Example: a regulatory compliance checker with 40 enumerable rules. The code checks each rule, calls the LLM only to generate a plain-language explanation for each violation, and assembles the report deterministically. The model never sees the routing logic.
Pattern 2: Model-Planned, Script-Executed
The LLM produces a structured plan at the start of a task: a JSON array of steps with tool names and parameters. The code then executes that plan deterministically, step by step, without further model calls unless a step fails. On failure, the model is re-invoked to revise the plan from the failure point.
This pattern works when F3 (error recovery) is the primary driver of complexity. The code can execute a known plan reliably; the model handles the judgment calls about what to do when things go wrong. The key implementation requirement: the plan schema must be strictly typed, and the code must reject any plan that references a tool not in the registered toolset.
A code review bot fits here. The model generates a list of specific checks to run (linting rule X, security pattern Y, test coverage threshold Z). The code runs each check, then returns results to the model only if one fails, asking for a revised plan or a final severity judgment.
Pattern 3: Model-Gated Routing with Deterministic Branches
All branches are implemented in code. But the routing decisions at branch points are made by a lightweight model call that classifies the current state into one of a finite set of labels. The code then dispatches to the correct branch based on that label.
This is the pattern to reach for when F6 (domain novelty rate) is the primary driver. The branching logic itself stays stable in code. Only the classification at each gate is model-driven, so when the domain shifts, you retrain or reprompt the gate — you do not rewrite routing logic.
Use a small, fast model for the gate (Haiku-class or equivalent): it only needs to output a label, not prose. Gate latency should be under 300ms in the 95th percentile. If your gate model is slower than that, the pipeline feels synchronous and the user experience degrades.
Factor Deep Dives
F1: Task Ambiguity
The practical test: can you write a JSON Schema for the output before the pipeline runs? If yes, score 0–4. If you can write a partial schema (known fields, variable additional fields), score 5–7. If you cannot predict the output shape at all, score 8–10.
Teams underestimate this factor because they conflate “the domain is clear” with “the output is specifiable.” A customer support domain is clear; the output of a support conversation is not specifiable in advance. That is a 9 on F1, regardless of domain familiarity.
F2: Branch Count & Depth
Count every conditional in your pipeline design document. Include error branches, retry paths, and early-exit conditions. A pipeline with 5 happy-path branches and 15 error-handling branches has an effective branch count of 20. Depth matters too: a tree that is 4 levels deep with 3 branches at each level has 81 possible paths, which means your integration test surface is enormous even if each individual branch is simple.
The threshold at which deterministic branching becomes unmaintainable is around 25–30 enumerable branches. Below that, code; above that, you will be adding branches every sprint and the code becomes a maintenance liability.
F3: Error Recovery Complexity
Ask: when step N fails, does the recovery strategy depend on the content of the error, or just the error type? Typed exceptions (HTTP 429, tool timeout, schema validation failure) can be handled deterministically. Semantic failures (“the model returned a plan that will not converge”, “the retrieved document does not answer the query”) require model-driven recovery.
A common mistake is assuming that wrapping everything in try-catch covers F3. It does not. Retry-with-backoff on a 429 is deterministic recovery. Asking the model “you just returned an unexecutable plan; revise it given this error” is model-driven recovery. If your pipeline has both, it is a hybrid on F3 regardless of everything else.
F4: Latency & Cost Budget
This factor does not measure whether model-driven is possible, but whether it is affordable. A high-volume, low-margin workflow running 50,000 times per day at 3,000 tokens per run costs roughly $1.50/day at current frontier model prices — acceptable. The same pipeline at 30,000 tokens per run costs $15/day and may require a business case. Estimate your token budget before scoring F4.
Latency matters for synchronous, user-facing pipelines. An agent that calls five tools sequentially, each requiring a 1,500-token model call at ~600ms, gives a total latency of 3 seconds minimum before any tool execution time. For a background batch job that is fine. For a real-time assistant it is not.
F5: Auditability Requirement
Regulated industries (finance, healthcare, legal) often require that every decision be reproducible from a deterministic log. Model-driven orchestration can log its inputs and outputs, but two runs with identical inputs may produce different outputs if temperature > 0, which means the log does not fully explain the decision. If your compliance team or legal counsel requires reproducibility, set temperature to 0 and document this as an architectural constraint.
Score F5 a 2 if you need full reproducibility, a 6 if approximate auditability (logging inputs/outputs/tool calls) is sufficient, and a 9 if you operate in a context where outcome accountability matters but reasoning transparency is not legally required.
F6: Domain Novelty Rate
How often does your pipeline encounter input patterns that were not present when you wrote the code? A tax calculation pipeline that handles a new deduction category once a year scores a 2. A news summarization pipeline that encounters new event types daily scores a 9. Domain novelty rate is the strongest argument for model-driven orchestration: models generalize to novel input; code does not.
The practical signal is your bug tracker. If a meaningful fraction of your production bugs are “new input type not handled,” you have high domain novelty. If your bugs are “edge case in existing logic,” you have low domain novelty and deterministic code is appropriate.
Common Scoring Mistakes
Teams tend to make four systematic scoring errors when first applying the WOS framework.
Anchoring on the happy path. F2 and F3 should be scored based on the full branching tree including error paths, not just the success path. A pipeline that has 3 happy-path steps but 12 error-recovery branches scores 7–8 on F2, not 2.
Conflating domain clarity with task ambiguity (F1). Described above: clear domain, ambiguous output shape — still a high F1 score. Score F1 based on output specifiability, not domain expertise.
Underpricing model-driven systems on F4. Teams model costs for the happy path and forget that planning agents often issue multiple model calls before settling on a valid plan. A ReAct-style agent on a complex task commonly issues 8–15 LLM calls per task, not 1–3. Multiply your per-call token estimate by the 90th-percentile call count, not the median.
Ignoring temporal drift on F6. A pipeline built in January might score a 2 on F6 because the domain is stable. By June, after three regulatory updates and a product line change, it might score a 7. Revisit F6 quarterly for any long-running pipeline. A rising F6 score is the early warning signal that your deterministic pipeline is accumulating technical debt.
Applying the WOS to an Existing Pipeline
Most teams are not building from scratch. They have an existing pipeline that is causing pain and need to diagnose whether the architecture is the problem.
Score the pipeline as it exists today. Then score it as it was designed to handle. If the current WOS is 28 but the original design assumed a WOS of 12, the architecture did not anticipate the complexity that accumulated — that is the root cause of the pain, not any individual bug.
The intervention depends on which factor(s) drove the gap:
- F1 jumped (output ambiguity grew): refactor terminal nodes to use structured output parsing with a validation model. Do not try to specify the full output schema — specify the critical fields and let the rest be freeform.
- F2 jumped (branch count grew): extract the routing logic from code into a model-gated routing layer (Pattern 3). Freeze the code branches at the current count; new cases go into the classification model.
- F3 jumped (error complexity grew): introduce a model-driven recovery step that interprets semantic failures and either replans or escalates to human review. Keep typed exception handling in code.
- F6 jumped (domain novelty grew): the most common scenario. The fastest fix is Pattern 1 — add a model-filled leaf that handles novel input shapes and returns a structured representation the deterministic spine can consume.
Decision Anti-Patterns to Avoid
Two architectural choices produce disproportionate downstream pain.
The Universal Model Router. Some teams, after building their first model-driven agent, route every single pipeline decision through a model — including decisions that are trivially deterministic, like “is this a PDF or a CSV?” This adds latency and cost with zero benefit. Reserve model-driven routing for decisions that genuinely require semantic reasoning. Structural checks (file type, schema validity, field presence) belong in code, always.
The Mega-Prompt Deterministic Hack. The inverse problem: teams with a high WOS score try to force the pipeline into deterministic code by writing a 4,000-token system prompt that encodes all the routing rules. This creates a prompt that nobody can debug, that breaks on distribution shift, and that costs more per call than a properly structured model-driven pipeline would. If your WOS is above 30, the answer is architecture change, not prompt engineering.
Integration with Agent Frameworks
The WOS framework is framework-agnostic but maps cleanly onto existing tooling. For pipelines scoring below 18, a straightforward function chain with retry logic is all you need — no agent framework required. For pipelines scoring 18–30, frameworks that support mixed deterministic/model-driven steps (LangGraph-style state machines, Prefect with AI tasks, or a custom step runner) are the right fit. For pipelines scoring above 30, a fully agentic runtime is appropriate: ReAct, plan-and-execute, or a multi-agent orchestrator where subagents own discrete domains.
One practical note on framework selection at WOS >30: the framework’s observability story matters more than its API ergonomics. You will spend more time debugging agent behavior than writing agent code. Choose a framework where every tool call, model call, and state transition is logged with a correlation ID. Without that, debugging a failed 15-step agent run is guesswork.
You can browse the WOWHOW tools collection for structured output validators, JSON schema generators, and agent debugging utilities that pair with this framework. For a broader look at AI agent architectures and prompting patterns, the WOWHOW knowledge base includes templates and starter kits built around these orchestration patterns. If you’re running production agent pipelines and want access to the full WOWHOW scoring worksheet plus worked examples for financial and compliance domains, check Pro Vault.
Score your most painful pipeline today. If F6 has doubled since you built it, that is your answer.
People Also Ask
What is the difference between deterministic and model-driven agent orchestration?
Deterministic orchestration hard-codes all routing, branching, and retry logic in code; the model only fills in content at terminal nodes. Model-driven orchestration lets an LLM decide what to do next, which tools to call, and how to handle unexpected input. The distinction matters because deterministic pipelines break silently on out-of-distribution input, while model-driven pipelines break expensively when the planner misreasates.
How do I decide whether my AI agent pipeline should be scripted or model-driven?
Apply the WOWHOW Orchestration Score: rate six factors — task ambiguity, branch count, error recovery complexity, latency budget, auditability requirement, and domain novelty rate — on a 0–10 scale with their weights. A total below 18 points means go deterministic; above 30 means go model-driven; 18–30 calls for a hybrid pattern.
What is the hybrid pattern for AI agent pipelines that score in the middle band?
Three patterns cover the 18–30 WOS band. “Scripted spine, model-filled leaves” keeps all routing in code and only calls the model at output nodes. “Model-planned, script-executed” generates a typed JSON plan once, then runs it deterministically. “Model-gated routing with deterministic branches” uses a fast classifier model at each branch point while all branch logic stays in code.
When does deterministic agent orchestration fail in production?
Deterministic pipelines fail when task ambiguity rises (the output schema can no longer be fully specified), when branch count grows past roughly 25–30 enumerable cases, or when domain novelty increases so that new input types arrive faster than engineers can write handling code. The F6 domain novelty factor is the most common driver of deterministic pipeline collapse in long-running production systems.
How do latency and token cost affect the choice between scripted and model-driven orchestration?
Deterministic pipelines can execute individual steps in under 10ms; model-driven pipelines add at least 300–600ms per LLM call, and ReAct-style agents commonly issue 8–15 calls per task. At high volume, this compounds: a pipeline running 50,000 times per day at 30,000 tokens per run costs roughly 15x more than the same pipeline at 3,000 tokens. Score F4 based on your 90th-percentile call count, not the median.
Comments · 0
Beta: comments are stored locally on your device and not visible to other readers.
No comments yet. Be the first to share your thoughts.