# Not everything needs an agent

A while back I sat in a kickoff for a project that would triage incoming service request, work out how urgent each one was and which team it should land with. Around two thousand a day. The client wanted agents. Several of them, talking to each other, with a supervisor on top.

So I asked what the priority actually depended on. Someone shared their screen and pulled up a spreadsheet. Eleven rows. Four predicates were doing most of the work: service tier, whether the affected system was customer-facing, region, and time of day — and the remaining rows handled escalation paths and on-call rotation.

That spreadsheet is a decision table. It has eleven rows, it can be checked mechanically for gaps and overlapping conditions, it evaluates in microseconds, it diffs in a pull request, and when somebody asks in March why a ticket paged an engineer at 3am, you can point at the row and the version it was on. We were three weeks from replacing it with a system that had none of those properties.

I should say what kind of post this is, because the title can be read the wrong way. I build agentic systems for a living, across a few industries, some of them regulated to the millimetre. Agentic AI is the most interesting thing to happen to this work in a long time. It absorbs input nobody could have anticipated. It takes on tasks whose shape you don't know until you're inside them. It goes and finds the next step instead of waiting to be told what the next step is. None of that was really available before, and I have no interest in going back.

The trouble is the other half of that sentence. Agentic AI is very good at a specific set of things — and somewhere in the last year, we collectively stopped checking whether the problem in front of us was one of them. So this isn't a post about whether agents work. It's about where they belong, what they guarantee, and what it costs when they end up somewhere else.

**TL;DR**

*   **Agentic is a dial, not a switch.** The same problem can be built anywhere on a line from hard-coded logic to a fully autonomous agent. Almost every project I see is set further right than the problem calls for.
    
*   **The properties of the problem should pick the technique.** Determinism, data, volume, reversibility, and whether you know the steps in advance. Not the name of the funding line.
    
*   **If you can write the procedure down, write it down.** A prompt is the least reliable place to keep a requirement.
    
*   **The systems that survive are mixtures** — a model at the edges where the input is messy, ordinary code in the middle where the decision has to hold up, and a person on anything you can't take back.
    

* * *

## Agentic is a dial, not a switch

That line turned up in passing at the end of a post a few months ago, and it's the part I've kept coming back to since.

The idea is simple enough. Almost any problem you're handed can be built at several different points along one line, and picking the point is the real architectural decision — whether or not anyone makes it on purpose.

![figure-1-v3 - Agentic is a dial, not a switch. A left-to-right line from hard-coded logic, through rules engines, statistical models and language models in a fixed sequence, to agents with tools and fully autonomous agents. Moving left buys predictability and low cost; moving right buys tolerance for messy input](https://cdn.hashnode.com/uploads/covers/6a008fa5e3eebc2e2087c6a4/7f9458fe-b471-441f-8006-3da822ac2000.png align="center")

*Figure 1 — The same problem can be built at any point on this line. The question is which point it belongs at.*

Nothing on that line is better than anything else. Moving right buys you tolerance for mess — input you couldn't anticipate, tasks whose shape you don't know until you're inside them. Moving left buys you predictability, cost, and the ability to explain a decision to someone eighteen months later who is unhappy about it.

You're always paying for one with the other. The mistake isn't picking the right-hand side. The mistake is picking it without noticing there was a trade.

## Why everyone reaches for the agent anyway

Before the criticism, the honest part: the pull toward agents is not irrational, and most of the reasons are good ones.

**The money has a name on it.** Budget gets approved for an *AI initiative*, not for *we are going to clean up the approvals workflow*. I've watched an architecture get chosen by a line item. Nobody in that chain is being dishonest. The funding is real, and it arrived with a label attached.

**Demos.** An agent demo is theatre — you watch it think, change its mind, go and fetch something. A rules engine demo is a person scrolling through a table. Guess which one gets the follow-up meeting.

**Prototypes lie about how finished they are.** Five prompts and an afternoon gets you something that works most of the time. The remaining slice is where the year goes. Meanwhile, writing a proper specification is slow at the start and fast at the end, which is exactly the wrong shape for a culture that judges progress by demos.

**And the real one:** people have seen agents do genuinely new things, and they want that. That instinct is correct. It's just been generalised past its evidence.

I should name my own conflict here too. I get hired to build agents. Nobody has ever called me to write a decision table. When I tell a client they don't need the thing they asked for, I'm arguing against my own invoice — which is either a sign I mean it, or a sign that I'm not very good at business.

## The old toolbox didn't go anywhere

None of the previous approaches were retired. They just stopped being interesting to talk about, which isn't the same thing.

![figure-2-v3 — Four ways to make a decision, compared by what each is good for, how each fails, and what each costs: rules and solvers, statistical models, agentic AI, and people.](https://cdn.hashnode.com/uploads/covers/6a008fa5e3eebc2e2087c6a4/c6064e4a-4283-4f20-9cdb-1eeed6ef546b.png align="center")

*Figure 2 — None of these was retired. Each is still the best answer to some questions.*

Two of these get skipped more than the others.

**Statistical models.** If you have a hundred thousand past cases with known outcomes and you want to score the next one, that is not a language problem. Asking a model to reason its way through each transaction is slower, more expensive by orders of magnitude, and — the part that actually matters — you can't back-test it the way the risk team will want to. Gradient boosting on a table of features is unglamorous and it will beat the agent on every axis anyone measures.

**Solvers.** This is the one I see missed most, and it's the one that stings. If you're assigning shifts, routing vehicles, packing a warehouse, allocating operating rooms — hard constraints, something to minimise — that's a solved problem with fifty years of literature behind it. A solver returns an answer that is provably good and that does not violate a hard constraint, because it can't. An agent returns a plausible schedule that has somebody working a double because the roster ran long and it lost the thread around row 40.

Both produce a schedule. Only one of them produces a schedule you can publish.

## Six questions I ask before choosing anything

These aren't clever. They're just the ones that turn out to settle the argument.

![figure-3-v3 — Six questions asked before choosing an architecture: can you write the rule down, must the same input give the same answer, do you have thousands of past examples, do you know the steps before you start, can you undo a wrong answer, and how often does it run and how fast.](https://cdn.hashnode.com/uploads/covers/6a008fa5e3eebc2e2087c6a4/78456ed3-0ea8-4c6f-82b4-1fd1c02e0248.png align="center")

*Figure 3 — Answer these about the problem and the architecture mostly picks itself.*

**Can you write the rule down?** If someone in the business can state the policy in a sentence, and it doesn't change every week, then write it down and run it. Don't ask a model to hold it in mind.

**Does the same input have to produce the same answer?** Not *usually* the same. The same. If there's an appeals process, an audit, a regulator, or a customer who will ask why — the decision belongs in code that you can point at.

**Do you have history?** Thousands of past examples with known outcomes is a very valuable asset and a prompt is a poor way to spend it.

**Do you know the steps before you start?** This one separates workflows from agents more cleanly than anything else. If the order is fixed, you have a sequence. Agents earn their cost when the next step depends on what the last step found.

**Can you undo a wrong answer?** A wrong summary is an annoyance. A wrongly rejected claim, a wrongly closed account, a wrongly ordered test — those have a person on the other end and a paper trail. Costly and permanent means a human decides, with the machine preparing the evidence.

**How often does it run, and how fast?** Fifty million events a day at ten milliseconds each is not a conversation. Volume and latency settle more of these arguments than architecture ever does.

Two of those questions do most of the work, and you can put them on a pair of axes:

![figure-4-v3 — A two-by-two grid with input messiness on one axis and reversibility on the other. Messy and hard to undo goes to people; messy and easy to undo goes to agentic AI; clean and hard to undo goes to rules; clean and easy to undo goes to models and plain code.](https://cdn.hashnode.com/uploads/covers/6a008fa5e3eebc2e2087c6a4/489e4c02-b413-4037-a73f-0e78db1f2671.png align="center")

*Figure 4 — How unbounded the input is, and whether you can take a wrong answer back.*

Three of those four squares are not an agent. That's not a rhetorical trick — it's roughly the distribution I see in the field.

## Signs you built a sequence and called it an agent

Some of these I've caught in other people's systems. Some of them I've shipped.

**Your prompt has turned into a policy document.** If your system prompt contains *ALWAYS check that the amount is under 5,000*, you have written an if-statement in the least reliable language available to you. Prompts are a fine way to describe a job. They're a bad place to store a requirement.

**The tools always fire in the same order.** Go and look at a hundred runs. If the sequence is identical in ninety-eight of them, you don't have an agent. You have a pipeline that occasionally has a bad day.

**Temperature zero, one tool, output pinned to a schema.** You've spent a great deal of money and latency to get a function call. Wanting a function call is completely reasonable. Write a function.

**Most of your effort goes into stopping it from varying.** Retries, validators, self-critique, majority voting across three runs. Every one of those is a legitimate technique and I use all of them. But when they add up to most of the system, step back and look at what you've built: you selected the tool whose defining property is variability, and then constructed a large apparatus to suppress the variability.

**Nobody can explain a specific past decision.** *Why was this one rejected in March?* is a question that gets asked in every domain I've worked in, and it always gets asked at the worst possible moment. If the honest answer is that the model saw it differently that day, you don't have a decision system. You have something that produces decisions, which is not the same thing.

![figure-5-v3 — The same system drawn two ways. On the left, an orchestrator freely calling a reader, a lookup and a writer in any order. On the right, the four steps it actually ran in the same fixed sequence every time. ](https://cdn.hashnode.com/uploads/covers/6a008fa5e3eebc2e2087c6a4/a40dae46-cd72-43e7-aae4-e87c41283c7f.png align="center")

*Figure 5 — Left: what it was designed as. Right: what a hundred runs actually looked like.*

## Why long chains degrade faster than people expect

This one deserves its own section because the arithmetic is unintuitive and it explains a lot of failed pilots.

If a chain has *n* steps and each step is independently correct with probability *p*, the whole run is correct with probability *pn*. That exponent does brutal work. At 95% per step — which sounds like a system in good health — ten steps land at 60%. At 90% per step, ten steps land at 35%.

![figure-6-v3 Figure 6 — A line chart showing end-to-end reliability falling as chain length grows, for per-step reliability of 99%, 95% and 90%. At ten steps these reach roughly 90%, 60% and 35% respectively.](https://cdn.hashnode.com/uploads/covers/6a008fa5e3eebc2e2087c6a4/151c8abc-cafd-4ba9-97c7-3b2332e81749.png align="center")

*Figure 6 — Per-step reliability, raised to the power of the number of steps.*

Two things make the real picture worse than the curve.

Steps aren't independent. An early misreading gets carried forward as context and conditions everything downstream, so failures cluster rather than distributing evenly. The independence assumption behind that curve is optimistic.

And per-step reliability is usually estimated on an eval set that under-represents the tail — which is precisely the region where you introduced an agent in the first place, because the input was unbounded. So the *p* you measured is likely higher than the *p* you're operating at.

This is also the clearest argument for the composite architecture, and it isn't an aesthetic one. Every step you move out of the chain and into deterministic code sets that factor to 1. Not 0.99. Exactly 1, for that step, permanently. Shortening the probabilistic chain is the single highest-leverage reliability move available, and it costs nothing but the willingness to specify.

## Where agents genuinely win

I'd rather not be read as a sceptic, because I'm not one. There are jobs where nothing else comes close, and they share a structure.

Input variety you can't enumerate — arbitrary phrasing, arbitrary formats, a long tail nobody will ever standardise. Work where the next step depends on what the last step found, which covers most of research, triage of genuinely novel cases, investigation, and debugging. Tasks where writing the specification costs more than doing the work, which is most one-off analysis. And integration against systems with no stable contract, where a brittle mapping breaks weekly and a model absorbing the drift is cheaper than maintaining it.

The common structure: the branching factor is too large to enumerate, or the path can't be known until you're partway down it. That's the whole test. If the procedure can be written down, write it down. If it can't, that's what agents are for — and that's a real and valuable category, not a consolation prize.

## The composite is the architecture, not the compromise

Take that triage problem from the top of this post. The version that works looks like this.

A model reads whatever arrives — an email with the real problem buried in the third paragraph, a half-filled form, a pasted stack trace — and emits a structured record against a fixed schema. That record crosses a boundary into a decision function: the eleven-row table, evaluated deterministically, same answer every time, versioned and diffable. A model then drafts the acknowledgement that goes back to the requester. Anything expensive or irreversible — the 3am page — stops at a person.

![figure-7-v3 — A composite architecture. A language model reads messy input, a deterministic core of rules, models and plain code makes the decision, a second language model explains the result, and a human gate catches anything costly and permanent. ](https://cdn.hashnode.com/uploads/covers/6a008fa5e3eebc2e2087c6a4/f98aca86-c267-483b-8cc5-2e14c9bc06eb.png align="center")

*Figure 7 — Put the agent where the ambiguity is. Put the code where the accountability is.*

Notice what the model does there. It reads, and it writes. It does not decide. The decision sits in the middle, in ordinary code, where it can be covered by tests, explained from stored inputs, and changed deliberately rather than by rewording a paragraph and re-running an eval.

The boundary between those regions is the part worth designing carefully. It's a schema, and it should be strict — every field typed, every enum closed, out-of-range values rejected loudly rather than coerced. The model's job is to hit that schema; the decision function's job is to assume nothing beyond it. Get that contract right and you can change models without touching decision logic, and change decision logic without re-running a single eval.

There's a regression test hiding in that. Swap the model — different vendor, smaller variant, next quarter's version — and re-run your decision corpus. Extraction quality will shift. Your decisions should not. If they do, the model was making them, and you now know that on a Tuesday afternoon rather than during an audit.

None of this is elegant the way a single agent is elegant. It's four components with contracts between them, and the contracts are a real share of the work. That's normal. Most systems that survive contact with production look like that — several separate pieces, each doing what it's good at, connected deliberately.

## What this sounds like in the room

I don't refuse the request. That never goes well, and more importantly it's usually not right — the client understands their problem better than I do on day one.

What I do is ask the six questions, out loud, with whoever knows the process best. Most of the time the answers do the arguing for me. The room reaches "oh, that part's just the policy table" without my having to say it, which is a much better outcome than me saying it.

Then I show them the mixture, and I point out that the agentic parts are still agentic parts. This matters more than it should. The word *agent* is often load-bearing for reasons that have nothing to do with architecture — someone promised it upward, it's in a board deck, it's what the funding said. And that's fine, because the honest description of the system I want to build is still *an AI system*. It just has its AI in the places where AI is the right answer.

The other thing I've learned to say early: the mixture usually ships sooner. Not always — I don't want to oversell that — but usually, because the deterministic middle is the part you can actually finish. I've never once had a client disappointed that something arrived in March rather than November.

## What it costs to get this wrong

The money is the smaller loss.

A pilot that doesn't reach production makes the next three proposals harder. I've watched an organisation conclude that AI *doesn't work for us* on the strength of a single project that was mis-scoped in its first week — a project where the technology was never the problem, the match was. Everything anyone tries there for the next two years now starts from behind.

That's the real reason I've become fussy about this. Every problem handed to the wrong technique burns credibility that the right problems needed.

## Three things I'd keep

1.  **Let the problem pick, not the project name.** Determinism, available history, volume, reversibility, and whether you know the steps in advance will tell you what to build. None of those questions is about which model you use.
    
2.  **Agents are for the parts you can't specify.** If you can write the procedure down, write it down — and keep it somewhere more reliable than a paragraph of English.
    
3.  **Aim for a mixture.** Model at the edges where the input is messy, ordinary code in the middle where the accountability lives, a person on anything you can't take back.
    

The industry spent a couple of years finding out what agents can do, which was necessary and mostly fun. The next stretch is less exciting and more valuable: working out where they belong.

* * *

*The views, opinions, and technical perspectives expressed in this article are entirely my own and do not represent, reflect, or imply the positions, strategies, or endorsements of my employer or any organization I am affiliated with.*