Assistant or agent? The distinction that decides your budget

A useful way to tell an assistant from an agent: an assistant is judged on its answer, an agent is judged on its outcome. That sounds like a semantic distinction. It is actually the difference between a tool you can adopt in an afternoon and a system that requires design, testing and oversight.

What an assistant is

An assistant responds. You provide context, it produces something — a draft, a summary, an explanation — and a person decides what to do with it. The person remains the operator throughout. If the output is poor, the cost is a few wasted minutes and mild irritation.

Assistants are underrated. They are cheap to deploy, they fail visibly, and applied to the right work they are quietly transformative. For a great many businesses the correct AI strategy for the next year is a well-chosen assistant, properly integrated into two or three workflows, with people trained to use it well. That is not an exciting recommendation. It is frequently the right one.

What an agent is

An agent is given an objective rather than a prompt. It decides what steps to take, uses tools to take them, evaluates what came back, and continues until it judges the objective met. Nobody walks it through the middle.

This is a genuine change in kind. Consider a task like: identify companies in this sector meeting these criteria, check each against our exclusions, pull their most recent filings, and produce a briefing note. An assistant helps with each of those steps if you ask it to. An agent does the sequence.

The moment a system takes actions between your instruction and its result, you have stopped buying a tool and started operating a process.

Why agents cost more than they appear to

The build cost of a simple agent is modest. The cost that surprises people sits in four places, none of which are visible in a demonstration.

• Evaluation. An assistant is checked by the person using it. An agent completing forty tasks overnight needs a way to know whether those forty tasks were done correctly — which means a test set built from your real cases, and a standard agreed in advance.

• Boundaries. Every tool an agent can use is a decision about what it is permitted to do. Read from the CRM, yes. Write to it, perhaps. Send an email to a client, almost certainly not without review. These decisions cannot be deferred.

• Failure behaviour. Agents fail differently from software. They do not usually crash; they produce a confident, plausible, wrong result and carry on. Designing for that is a discipline in itself.

• Observability. When an agent produces something unexpected, somebody has to be able to reconstruct why. Without traces and logs you have an unauditable process, which in most regulated contexts is unacceptable.

A reasonable test

Before commissioning an agent, write down what the work is, then answer two questions honestly. Could you write the procedure a new starter would follow? And could you check their work afterwards without redoing it?

Two yeses is a strong candidate. The task is repeatable and verifiable, which is precisely what agents need. Two noes means the work depends on judgement that has not been articulated, and an agent will simply automate an unexamined process at speed.

One of each is the interesting case, and usually the answer is a narrower agent than first imagined — one that prepares the work rather than completing it, with the judgement left where it belongs.

The honest position

Agents are the most oversold capability in the current market and also one of the most genuinely valuable, which is an uncomfortable combination for a buyer. The uncomfortable part is that both statements are true at once, and telling them apart requires looking closely at your specific work rather than at anybody's demonstration.

The right question is not whether agents work. They do. It is whether the work you have in mind is the kind they work for.