What AI agents are, and what they change

A chatbot responds to what you send it. An agent is given a goal and takes multiple steps toward it on its own — calling tools, reading results, deciding what to do next, and continuing until it finishes or fails.

The important word is steps. Once a system acts repeatedly without checking in, small errors compound. A model that is right 95% of the time per step is right about 60% of the time across ten dependent steps, which is why agent demos impress and agent deployments disappoint.

That arithmetic is the single most useful thing to carry into any conversation about agents. It explains why the impressive five-step demo does not survive being turned into a twenty-step workflow, and why serious deployments spend most of their engineering effort on verification rather than on reasoning.

Stripped of marketing, the definition needs only three properties. The system has a goal rather than a prompt. It can act on the world through tools, not just emit text. And it decides its own next step from what the last one returned.

Remove any one and you have something simpler with a clearer name. No tools and it is a chatbot. No self-direction and it is a workflow, which is usually better — workflows are deterministic, testable and cheaper. No goal and it is an autocomplete.

This matters commercially because a great deal of software is currently marketed as agentic when it is a workflow with a model in one step. That is not a criticism of the software; a workflow is frequently the right design. It is a reason to read what a product does rather than what it is called.

• A goal, not a single instruction
• Tools that change something outside the model
• Its own choice of next step, based on the last result

Agents work well where the environment is constrained, mistakes are cheap or reversible, and a human reviews the result. They work badly where a wrong step is expensive and nobody is watching.

Coding is the clearest success because the environment supplies its own verification. A test suite tells the agent immediately whether the last step was wrong, so errors are caught at the step that produced them rather than compounding silently through the next nine.

That generalises into a rule worth applying to any proposed agent use: does the environment tell the agent when it is wrong? Where the answer is yes, agents work far better than the step-count arithmetic alone predicts. Where it is no, they fail in ways nobody notices until later.

• Coding assistants that run tests and iterate — errors surface immediately
• Research and summarisation across many documents, with a human reading the output
• Data pulling and report drafting inside a fixed set of systems
• Triage and routing, where a mistake is corrected downstream

The failure modes are consistent enough to list. Agents lose the thread on long tasks as context fills. They act confidently on a misread instruction rather than asking. They cannot tell a temporary failure from a permanent one, so they retry things that will never work.

And they are vulnerable to what they read. An agent that browses the web or reads documents is consuming text written by people who may be addressing the agent rather than the reader — which is a genuine security problem, not a theoretical one, once the agent can also take actions.

None of this makes agents useless. It makes the boundary clear: the more consequential and irreversible the action, the more the design should route it through a person.

The realistic near-term effect is not replacement of roles but compression of the routine middle of them. The gathering, collating and first-drafting that occupies large parts of many jobs is exactly what agents do acceptably.

What that leaves is deciding what should be done, checking whether the output is right, and being accountable for it. That is a genuine change in the shape of the work, and it disproportionately affects roles built mostly from the routine middle.

It also changes what junior work looks like, which is the part worth watching. Much of the routine middle was how people learned a domain, and compressing it removes the training ground along with the tedium.

Almost every agent demo works, and almost every agent demo is chosen to work. The task is short, the environment is clean, the failure path is never shown, and the person running it knows which phrasing succeeds. None of that is dishonest, but none of it tells you whether the thing survives contact with a real workload.

The questions that separate the two are boring and diagnostic. How many steps does a typical real task take, and what is the success rate at that length rather than at three steps? What happens when a tool returns an error — does it retry forever, stop, or invent a result? Who sees the output before it reaches anything irreversible?

Ask what it costs per completed task, not per call. Agents that look cheap per model invocation frequently take thirty invocations to finish one job, and the retries on failure are the part nobody counts. A deployment that cannot answer the cost-per-completed-task question has not been run at volume.

• Success rate at realistic task length, not at demo length
• Behaviour on tool failure: stop, retry, or fabricate
• Cost per completed task, including retries
• What a human sees before anything irreversible happens
• How a bad run is detected after the fact

The people gaining from this are the ones who direct these systems well and check their output critically — which requires enough domain knowledge to recognise a plausible-looking wrong answer. That judgement is the scarce part, not the tooling.

If you work in engineering, data or operations, being the person who can build and evaluate agent workflows is a genuinely marketable skill right now, and there are far fewer people who can do it than the discussion volume suggests.

The most transferable specific skill is evaluation: deciding what correct means for an open-ended output and building something that measures it. Very few people can do this well, every team deploying agents needs it, and it is largely independent of which model or framework is current.