AI Agents: When Do They Actually Make Sense?

An AI agent is a system where a model decides which action to take next, rather than following a fixed sequence. It can call tools, read results, and choose what to do based on what it finds.

That’s a genuinely powerful pattern. It’s also the most oversold idea in business AI at the moment, because the demo is spectacular and the production behaviour is not.

The honest trade-off

A fixed pipeline does the same thing every time. You can test it, reason about it, and explain any individual run.

An agent adapts. It handles cases you didn’t anticipate — and it also takes paths you didn’t anticipate. The same request can produce different sequences of actions on different days. That flexibility is the feature and the problem.

For most business processes, predictable beats adaptive. You want the invoice processed the same way every time, not creatively.

When an agent is a reasonable choice

The path genuinely varies per case, and the variation can’t be enumerated. Research tasks, triage across many systems, investigations that depend on what’s found.

The action space is safely bounded. The agent can read from five systems and write to one, inside permissions that make the worst case acceptable. If it can send email to customers or move money, you need a person approving, not a better prompt.

Mistakes are cheap and visible. A draft nobody sends. A shortlist someone reviews. A summary with citations.

A human is in the loop at the point of consequence. The agent prepares; a person decides.

The alternative is nobody doing the task. Investigative work that would take a person two hours and therefore never happens.

When it isn’t

When you could write the steps down. If the process is "fetch, extract, validate, post", that’s a pipeline. Wrapping it in an agent adds cost, latency and non-determinism for no benefit.

When consistency is a requirement. Anything regulated, financial, or customer-facing at scale.

When the failure is expensive or public. Agents fail in more interesting ways than pipelines, and interesting is not what you want in production.

When you can’t observe what it did. If you can’t reconstruct the sequence of actions afterwards, you can’t debug it and you can’t defend it.

What production agents actually need

If you do build one, these are not optional:

• Tightly scoped tools. Each with its own permissions. Read-only wherever possible.
• Hard limits. Maximum steps, maximum cost per run, maximum time. Agents loop; assume yours will.
• Full tracing. Every tool call, input and output, retained and inspectable.
• Approval gates before anything irreversible.
• An evaluation set. Fifty real cases with known good outcomes, re-run whenever anything changes — prompt, model version, tool.
• A kill switch that someone non-technical can use.

If that list sounds like more engineering than the agent itself, that’s because it is. This is why "just add an agent" projects stall at the demo.

A more useful pattern

Start with a fixed pipeline. Log the cases it can’t handle. If those cases share a shape, extend the pipeline. If they’re genuinely varied and there are enough of them to matter, that’s your evidence for an agent — and you’ll have real cases to evaluate against.

This is slower than starting with an agent, and it’s how you end up with something still running in a year.

Where they’re working well today

• Research and enrichment. Given a company name, gather public information from defined sources and produce a structured summary. Bounded, verifiable, useful.
• Multi-system triage. Look up a customer across several systems and summarise the situation before a person joins the call.
• Developer tooling. Bounded, reviewable, with a human accepting every change.
• Investigation. "Find every record affected by this problem." Read-only, and the output is checkable.

Notice the pattern: read-heavy, write-light, human-reviewed.

Our position

We build agents where the conditions above are met, and we’ll tell you when a pipeline would serve you better — which is more often than the market currently suggests. The engineering that makes an agent trustworthy is the same engineering that makes any AI system trustworthy: bounded actions, real evaluation, and a human at the point of consequence.

Got a process you think needs one? Describe it and we’ll give you a straight answer.