Build an AI Agent, Stage 2: Decide Whether Each Step Needs an Agent at All
Updated: 3 hours ago
Stage 2 asks which steps of a process need an agent, one step at a time. For most steps the honest answer is a rule, a lookup or a person.
The example in this series is a composite scenario, built from patterns common to requirements intake in regulated organisations. It is not a single real organisation, and its figures are illustrative. The code is real: every output block below was produced by running it.
The week-one prototype at the mid-sized insurer did everything. It read the mailbox, filled in the request record, labelled the type, looked for related requirements, merged what it judged to be duplicates, drafted questions, emailed them to the requester and picked a product owner. The analysts ran it in a sandbox against 30 past requests, then ran it again the next morning on the same 30 to see whether it was stable.
On the second run, three of the thirty went to a different product owner than on the first. All three sat near the boundary between two product lines, and the model had reasoned its way to a different side each time. The owner for every request was already defined in a 42-row routing table the analysts maintained: request type by product line, reviewed every quarter. The model was re-deriving a lookup, and getting it slightly different each day. In the same sandbox run it had merged two requests about claims letters that weren't duplicates. One was about wording and the other about delivery channel, and the merge kept only the older record's fields.
Stage 1 produced eleven workflow steps. Stage 2 asks, for each step, what the least autonomous design is that still does it.
Why one agent for the whole workflow is the default
A single agent that does the whole job is the easiest thing to demonstrate and the easiest thing to ask for. It looks like a colleague. Splitting the work into rules, model steps and a smaller agent looks like engineering overhead, and a sponsor who asked for "an agent" may hear "less than I asked for".
The cost of the whole-workflow agent doesn't show up in a demo. It shows up in testing, where every decision handed to the model needs test cases that cover it, and in operations, where a step that should be a lookup varies from run to run. Anthropic's guidance on building agents draws the same line: "We recommend finding the simplest solution possible, and only increasing complexity when needed" (Anthropic, 2024).
Ask the five questions per step, with evidence
The decision tree is the one from Agent, Workflow, Automation or RPA?, and this stage applies it rather than re-teaching it. For each step, ask the questions in order and stop at the first yes. Two rules make it work on a real workflow:
One step at a time. "Intake" isn't a step. "Route to the product owner" is.
Every answer quotes its evidence. A procedure, a count from the Stage 1 trace, an API document, a policy. An answer without evidence is a discovery task, not a design decision.
The series keeps the answers in workflow.json and a short script, agent_or_not.py, walks the questions for every step. Here is its first run on the insurer's workflow:
$ python agent_or_not.py workflow.v0.json
requirements-intake triage: 11 steps
step stops at design model?
S1 Receive via web form q1 automation no
S2 Receive via mailbox q3 workflow + model step yes
S3 Acknowledge the requester q1 DISCOVERY TASK no
S4 Check required fields q1 automation no
S5 Classify request type q3 workflow + model step yes
S6 Screen for regulatory content q1 automation no
S7 Find related requirements q5 AGENT yes
S8 Draft clarifying questions q4 person decides and acts drafts
S9 Route to the product owner q1 automation no
S10 Merge duplicate records q5 NOT AN AGENT: keep the person no
S11 Accept or reject the request q4 person decides and acts no
design summary:
4 automation
2 workflow + model step
2 person decides and acts
1 DISCOVERY TASK
1 AGENT
1 NOT AN AGENT: keep the person
agent actions to carry into Stage 3: search_requirements, get_requirement, propose_relation
discovery tasks before build:
S3: q1 answered 'yes' with no evidence
The discovery task is real and typical. Everyone assumed the acknowledgement email was one template, and nobody had checked. One message to the BA practice lead confirmed it: one template for every business unit. With that evidence recorded, the rerun ends with five automation steps, two model steps, two person steps, one agent step and one step that fails question 5, and the script exits cleanly.
The test: for your own workflow, count the steps whose first "yes" has no evidence written next to it. Each is a decision someone made from the meeting room.
Walk the one step that needs an agent
Step S7, find related requirements, is the only step that reaches question 5 with a yes. Here is the walk, with the evidence the team recorded:
Known steps, structured input? No. In the five traced requests that had a related item, the analysts searched a different way each time: by system name, by product line, by following a requirement up to its parent.
Screen-only system? No. The requirements repository and the backlog both have search APIs.
Uncertainty only in reading the input? No. What to search next depends on what the last search returned: a parent requirement, an earlier version, a sibling product line.
Does a person decide every case? No. The analysts want to review the finding, not each search, and no policy requires a person per search.
Can each action be constrained, checked and reversed? Yes, because the step has three actions and each one is listed with its check and undo: two reads (search, get a requirement), which change nothing, and one draft (propose a relation between the request and a requirement). A proposal's quotes can be verified in code, an analyst confirms it, and deleting it leaves the request untouched.
This is the shape Anthropic describes for work that suits an agent: "open-ended problems where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path" (Anthropic, 2024). It is also small. The agent investigates and proposes. Everything it produces lands in front of an analyst, which is Level 2 on the autonomy ladder at most.
The step that failed question 5
Merging duplicates went down the same path as S7 for four questions. Whether two requests are the same is a judgement, the backlog has an API, and no policy requires a person to merge. Then question 5: the backlog tool's merge has no undo and keeps only the older record's fields. That is the merge that lost a regulatory deadline in Verification-First Agent Design, and the one that combined two unrelated claims-letter requests in the prototype sandbox.
So merging isn't an agent action. The agent proposes a "possible duplicate" relation in S7, with both records quoted, and an analyst decides whether to merge. The judgement the model is good at stays with the model. The irreversible act stays with a person. OWASP names this risk excessive autonomy, one of the three root causes of excessive agency in LLM applications, and its mitigation is to "require a human to approve high-impact actions before they are taken" (OWASP, 2025).
The test: for every step that reaches question 5, write the undo for each action and when it was last run. An undo nobody has run is a hope, not an answer.
Five steps became rules, and two became bounded model steps
The other results matter as much as the agent, because each one moves work out of the model's hands and into something with a deterministic test.
Routing (S9) became a table lookup. The 42-row routing table was the evidence for question 1. Routing in code ends the run-to-run variation in the opening story, and its test is a unit test over the table rather than a sample of model runs. When the classifier's label is wrong, the request goes to the wrong owner, so classification accuracy still matters. But the failure now has one cause, and the cause has a test.
The regulatory screen (S6) became rules plus a second signal. A regulator-reference pattern and a deadline inside 90 days are written rules. The classifier's regulatory label is a second signal, and either one sends the request to compliance. Neither can clear a request alone.
Mailbox intake (S2) and classification (S5) are workflow steps with one model call each. Extraction fills nine fields from an email, and code validates them before anything acts on them. Classification picks one of six types, and from that point the routing table decides what happens. Both outputs are bounded, so a labelled sample tests them.
Drafting clarifying questions (S8) stopped at question 4. BA practice is that only an analyst contacts a requester. So the agent drafts the questions as part of its S7 output, because the right question depends on what it found, and the analyst edits and sends them.
The whole-workflow agent from week one would have needed test cases for routing, merging, emailing and field extraction, each run several times because each was a model decision. The Stage 2 design moves seven of those decisions into code or to a person. What is left for the agent is one investigation with two read tools and one draft tool.
How to check your own workflow
Take the workflow from your Stage 1 problem definition and fill in a row per step:
Column | What goes in it |
Step | One action, small enough that a person could do it in one sitting |
First yes | The first of the five questions answered yes |
Evidence | The document, count, API or policy behind that answer |
Design | Automation, RPA, model step, person, agent, or "not an agent" |
Actions (agent steps only) | Each action with its side effect, its check and its undo |
Then count. If more than one or two steps come out as agents, check the evidence on each: the usual error is answering question 3 "no" because the input is messy, when the next steps after reading it are in fact fixed.
Tradeoffs and exceptions
Design | Gains | Costs | Best suited for |
One agent for the whole workflow | Fastest demo; one component | Every step needs model-level tests; lookups vary between runs; irreversible actions inside the loop | A spike to learn what a model can do |
Per-step design (this stage) | Most steps tested deterministically; agent scope small enough to verify | More components and seams to own; orchestration code to write | Anything that writes to a system of record or another team's queue |
No agent at all | Cheapest and most testable | Investigation steps stay manual | Workflows where no step reaches question 5 |
Exceptions. A read-only research assistant that answers one person's questions doesn't need this split: its outputs are advice and the person is the check. And per-step design has a cost the table understates. Every boundary between a rule, a model step and the agent is a place where data can be lost in hand-off, so each seam needs a contract. That is Stage 9's subject.
How Stage 2 goes wrong
Deciding for the process, not the step. One label for "intake" hides that most of it is a lookup.
Answers without evidence. The tree is only as good as the evidence column. The script refuses to design a step whose answer has none.
Question 5 answered for the step, not each action. A step can be mostly reads with one irreversible write hidden in it. List every action.
Keeping the prototype's tools. The prototype could merge and email. Stage 3 starts from the actions this stage approved, not from the tools that already exist.
What to do next
Run your Stage 1 workflow through the five questions, one row per step, with evidence. Then read Stage 3: Define Responsibilities, which takes the one agent step and its three actions and turns them into the agent's responsibilities, permissions, hand-over cases and full blueprint.
Final takeaway
The least autonomous design that does the job is usually several designs, one per step. At the insurer, eleven steps produced one agent with three actions, and the routing that varied between runs became a table nobody has to evaluate.
Sources
Anthropic (Schluntz, E. and Zhang, B.), Building effective agents, 19 December 2024. "The simplest solution possible"; agents for open-ended problems where the steps can't be predicted or hardcoded.
OWASP GenAI Security Project, LLM06:2025 Excessive Agency, 2025. Excessive autonomy as a root cause; human approval for high-impact actions.
Series navigation. Previous: Stage 1: Define the Problem. Next: Stage 3: Define Responsibilities. The full stage list is on the Build an AI Agent From Scratch hub.
Frequently Asked Questions
How do you decide which parts of a process need an AI agent?
Ask the five agent-or-not questions for each step of the workflow, not for the process as a whole, and stop at the first yes: known steps with structured inputs, a screen-only system, uncertainty only in reading input, a person deciding every case, and finally whether each action can be constrained, checked and reversed. Only steps that reach the fifth question with a yes get an agent.
What if a step's path can't be known but its actions can't be undone?
Then it is not an agent step yet. Keep the person in that step, and let the agent prepare what the person needs, for example by proposing a link instead of merging two records. Narrow the action until it can be checked and reversed, or leave it with a person.
Why does an answer to the decision tree need evidence?
Because an answer without evidence is an opinion about the work, usually from someone who doesn't do it. Evidence (a procedure, a count from traced cases, an API document, a policy) can be checked by someone else, and a step whose answer has none is a discovery task to finish before building.
Part of the Agent Engineering curriculum: eight paths from prompts and context to testing, evaluation and governance.
