When not to use AI agents, and what wins instead
When not to use AI agents: when the task is deterministic, when a wrong answer is expensive and unverifiable, when latency is the product, or when the real blocker is a missing integration. Pexon builds agent systems and turns down roughly as many, because the question is whether the work needs judgement at all.
The classification
Four shapes where an agent loses
| Problem shape | What wins instead | Why the agent loses |
|---|---|---|
| Steps are known in advance | A script | Non-determinism buys nothing and costs debuggability |
| Wrong answers are expensive and unverifiable | A person, or a form | Nobody can check it cheaply enough to catch the bad one |
| Latency is the product | A cached lookup | Multi-step reasoning is slow by construction |
| The blocker is a missing API | Fix the integration | An agent in front of a broken interface is a slower broken interface |
What this costs us to say
We build agent systems, so arguing against them narrows our own market. It is worth it because the alternative is worse: a project that should have been a script is a project that fails visibly, and the reference we lose is more expensive than the engagement we turned down. The multi-agent system we did build publishes its accuracy as a split — 100% on single-shot standard definitions, 70 to 80% on queries spanning several standards — precisely because a blended number would have hidden which half is trustworthy.
The question underneath all four
Can you write down the steps? If you can, you do not have an agent problem. You have an automation problem, and automation is faster, cheaper and inspectable. The value of an agent is entirely in the cases where the next step depends on what the previous one found — and that is a much smaller class of work than the current market implies.
The second question is who checks the answer. An agent that is right eight times in ten is useful when a human can spot the two in seconds and expensive when they cannot. That is not a model quality issue; it is a property of the task, and it does not improve when the model does.
The fourth row of that table is the one we see most. A team wants an agent to read data from a system that has no usable interface, and the agent becomes an elaborate wrapper around the actual problem. The integration was always the work. The agent was the part that looked like a project.
Where an agent genuinely earns its cost
For symmetry, because a piece that only says no is not useful. The pattern is consistent across the ones that worked.
- The path is not knowable in advance: the query decomposes into sub-questions that depend on what the first lookup returns.
- Verification is cheap: a test, a schema, a second source, or a human who can judge in seconds rather than minutes.
- The work is currently done by an expensive person doing something tedious, which is where the economics are least ambiguous.
- The accuracy can be reported by query class rather than as one average, so the buyer knows which questions to trust it with.
- Somebody owns the failure mode. An agent with no named owner for its wrong answers is a pilot that will not become production.
Related
- Multi-agent standards assistant at an automotive supplier — the case where the answer was yes, with the accuracy split published
- Claude in your own cloud tenant — where an agent has to run once the answer is yes
- What a forward deployed engineer actually does — why the negative answer usually arrives in week two
Questions this raises
When should you not use an AI agent?
When the steps are known in advance, when nobody can check the output cheaply, when the response has to be immediate, or when the actual obstacle is that a system has no usable API. In the first case write the script; in the last, fix the integration, because an agent in front of a broken interface is a slower broken interface.
What is the single question that decides it?
Can you write down the steps? If yes, the work is deterministic and a script will be faster, cheaper and debuggable. An agent earns its cost only where the path depends on what it finds along the way, and where a human can tell quickly whether the result is right.
Is a workflow tool better than an agent for most business processes?
For most, yes. A defined process with branches is a workflow, and workflows are inspectable, testable and cheap to run. Agents suit the cases where the branch set is not knowable in advance, which is a much smaller class of work than the current market suggests.
How do you tell whether an agent is actually working?
By publishing the accuracy split rather than one blended figure. Our own multi-agent case study reports 100% on single-shot standard definitions and 70 to 80% on queries spanning several standards. A single averaged number hides which class of question the system can be trusted with, which is the only thing a buyer needs to know.
Do you turn down agent projects?
Regularly, and it is usually the most useful thing we do in the first fortnight. Telling somebody their planned architecture cannot work against their actual source systems costs them two weeks. Discovering it in month six costs them a budget cycle.
Next step
The cheapest outcome is finding out in week two
A two-week blueprint answers whether the work needs an agent at all, and whether your source systems can support one. If the answer is a scheduled script and a fixed integration, that is what the blueprint says, and it is the least expensive report we sell.