-
Notifications
You must be signed in to change notification settings - Fork 4
Choosing What To Build
Deploying an agent to do rule-based lookup is hiring a neurosurgeon to take your blood pressure.
The most expensive error in these programmes is picking the wrong tool for the job, and it goes wrong in both directions.
An agent doing deterministic lookup is slow, expensive, non-repeatable and impossible to audit, for work a script did correctly. A rules engine handed an unstructured appeal letter fails spectacularly and expensively, because there was never a rule to write.
Neither failure is a technology failure. Both are classification failures, and both are cheap to avoid with three questions.
This page assumes you already have a candidate. Finding the work is how candidates are found and scored; this is how you decide what shape the answer takes.
Every candidate passes through them in order, and the first "no" ends the sequence.
| The question | Yes | No | |
|---|---|---|---|
| Gate 1 · Structure | Is the process fully structured, with deterministic rules? | Go to gate 2 | Skip to the model track. There is no rule to encode |
| Gate 2 · Judgement | Does it require human-like judgement or interpretation? | Go to gate 3 | Traditional automation. Do not put a model on it |
| Gate 3 · Complexity | Does it need multi-step reasoning, memory, or tools across systems? | An agentic system | A single model step in a workflow |
Gate 2 is the one that saves the most money and gets skipped the most. A structured process that needs no judgement is an automation problem that has been solved for twenty years, and putting a model on it converts a deterministic, auditable, cheap process into a probabilistic, expensive one.
Gate 3 is the one people get wrong in the other direction. Most work that clears gate 2 does not need an agent. It needs one model call inside an ordinary workflow, which is faster to build, cheaper to run and vastly easier to reason about when it breaks.
Once the gates give you a track, this is what you are committing to.
| Traditional automation | Model in a workflow | Agentic system | |
|---|---|---|---|
| Input | Structured, predictable | Unstructured or variable | Unstructured, multi-source |
| Decision logic | Deterministic rules | Pattern-based, probabilistic | Reasoning and planning |
| Memory | None, or session only | Single-session context | Persistent and cross-session |
| Tool use | One system | One model, one or two tools | Multi-tool orchestration |
| Human oversight | Exception handling | Review before action | In the loop by design |
| Setup time | Weeks | A month or two | A quarter or more |
| Risk profile | Low to medium | Medium | Medium to high |
| Governance | Standard change control | Tier review | Tier review plus a risk charter |
| Example, finance | Payment reconciliation | Drafting a dispute response | End-to-end dispute resolution across three systems |
| Example, logistics | Order status lookup | Interpreting a damage report | Exception resolution across carrier, warehouse and customer |
Read the setup-time row as a commitment, not an estimate. The gap between the first column and the last is not a scheduling difference, it is a difference in what you are agreeing to operate afterwards. Nothing in the last column is ever finished, because it needs a registry entry, a drift check and a rung on the ladder for as long as it runs.
The oversight row is the honest one. Traditional automation is supervised by exception. An agentic system is supervised by design, which means the human cost does not go to zero. It changes shape.
The gates are a decision procedure. The axis underneath them is worth naming separately, because it is how experienced people make the same call in ten seconds.
High determinism: clear rules, fixed outcomes, one right answer. Put it on rails. You are building a train, and a train that leaves the rails is a disaster rather than a variation.
Low determinism: nuance, empathy, negotiation, judgement. You are flying a helicopter. It goes where a train cannot, and it needs a pilot the whole time.
Most real work sits in the middle, and that is exactly where the mistakes are made, because a process that is eighty percent deterministic looks deterministic in a workshop.
The practical move for the middle: split it. Put the deterministic eighty percent on rails, and route the remainder to the model track with the human oversight the last twenty percent actually needs. That is almost always cheaper and more auditable than treating the whole process as low-determinism, and it is the shape most successful systems here have taken.
| Answers | Where | |
|---|---|---|
| Opportunity score | Is there work here worth automating at all? | Finding the work |
| Three gates | What kind of thing should we build? | This page |
| BXT | Should this candidate be funded ahead of the others? | The framework spine |
| Three proof gates | Have we proved it before scaling it? | The three proof gates |
Running these out of order is the common failure. Funding a candidate before classifying it means committing a budget shaped like automation to a problem shaped like an agent, and the overrun is discovered at gate 3 of the proof model rather than in the first conversation.
Adapted from the AI CoE and Agent Factory Playbook, based on The Augmented Enterprise framework. The split-the-process recommendation and both example rows are the author's own.
The thinking
Operating model
Frameworks
Governance
Playbooks
Value and people
Reference
In the repository
The courses
Reviewed 2026-08.