Do you need an agent? Walk the tree

Lesson 4 of 4 in When NOT to Build an Agent.

Everything so far compresses into one walkable decision. Bring a real task — the one someone in your organisation wants to “agentify” — and answer honestly at each fork. The tree is deliberately biased: every early exit lands somewhere cheaper, and the agent outcomes sit at the far end, behind every question that could have disqualified them. That is the correct bias.

Do you need an agent?

Interactive decision tree — outcomes:

Write a script
Enumerable steps, no language anywhere: this is ordinary software. Deterministic, testable, auditable, free. Nobody gets a conference talk out of it, and it will still be running correctly in five years.
Build a workflow
Freeze the step graph in code; let LLM calls handle the fuzzy steps inside it. You keep flat costs, predictable latency, and a testable skeleton — and you eval only the fuzzy steps, not the control flow. Most systems sold as “agents” should have landed here.
Build the agent
Unenumerable variability, viable economics, survivable failures — the honest case for model-directed control flow. Now pay properly: budget all five cost lines, build the eval suite before launch, and set the autonomy dial per action, not per product.
Agent — with gates
The model chooses the path; the runtime owns the consequences. Every consequential action goes through an approval gate, a parameter cap, or a sandbox — and reviewer time goes in the budget as a real cost line. If the gates ever start rubber-stamping, you are silently in the row above without having earned it.
No agent belongs here
The task is real, but a probabilistic loop is the wrong tool: hot-path latency, penny margins, or unrecoverable-and-ungateable actions. Redesign instead — precompute with models offline and serve results from code, shrink the task until its actions become gateable, or keep humans in the seat. Revisit when a constraint changes; do not prompt your way past physics.

The over-engineering hall of fame

Four patterns you will meet in the wild, each a tree exit ignored:

The agent-for-a-cron-job. An agent prompted nightly to “check whether the backup succeeded and email me.” Fixed steps, one condition, zero variability — a cron job and ten lines of code, now with a token bill and a failure mode that invents backup statuses.
The single-tool agent. A loop whose every iteration calls the same API. Signal 2 in production: a retry loop paying rent to a model for decisions it never gets to make.
The flowchart re-deriver. An agent that, on every run, “plans” the same five steps a workflow would have frozen in code — paying the model each time to rediscover a diagram the team drew in the kickoff meeting and then abandoned.
The regex with a PhD. An LLM extracting order IDs that match ORD- plus eight digits. The pattern is the spec; the model adds cost, latency, and the occasional hallucinated order.

Notice what the hall of fame has in common: none of these failed because the model was weak. They failed because nobody walked the tree. The teams shipped an agent loop where a script would do — and inherited the eval suite, the trace debugging, and the retry bill for a problem that never demanded any of it.

The punchline of this module is not “avoid agents.” It is: make the agent earn its place. When a task genuinely survives the whiteboard test, the economics check, and the error budget, an agent is not over-engineering — it is the only design that works, and the rest of this academy teaches you to build it properly. Restraint first is what makes the word agent mean something when you finally say it.

Key terms: agent, workflow, approval gate, blast radius, over-engineering

Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.

Tool: Architecture Advisor — Put the tree to work: feed the Architecture Advisor a real task from your backlog and see whether it recommends a script, a workflow, an agent — or tells you to walk away.