An AI agent is a language model placed in a loop, given tools it can call and a goal to pursue, left to decide its own next action until it judges the task complete. That is the whole concept. The interesting questions are not definitional — they are about where this actually works.
The loop
A conventional model call is one exchange: prompt in, response out. An agent restructures this. The model receives a goal and a set of available tools. It decides which tool to call, the harness executes it, the result is appended to the context, and the model decides again. This repeats until the model stops requesting tools — or until a budget is exhausted.
The shift that matters is control flow. In conventional software a developer specifies the sequence of operations. In an agent, the model chooses it at runtime. That is what makes agents capable of handling tasks nobody enumerated in advance, and it is also the root of every reliability problem they have.
Most of the engineering difficulty lives not in the model but in the harness — the surrounding code that defines tools, enforces limits, manages context as it fills, handles failures, and decides what the model is allowed to do unsupervised.
Where agents demonstrably work
Coding is the strongest category by a wide margin, and the reason is structural rather than incidental: software has fast, automatic, objective feedback. Code compiles or it does not. Tests pass or they do not. An agent can attempt something, observe a real failure, and correct — without a human in the loop. Few other domains offer that.
Research and synthesis works reasonably well for the same reason inverted: the output is a document a human will read and judge anyway, so imperfect reliability is tolerable.
Computer and browser use — agents operating a screen or a browser directly — has improved sharply and is genuinely useful for bounded, repetitive tasks. It remains meaningfully below human reliability on open-ended desktop work.
How capability is actually measured
Headline benchmark percentages are close to useless for agents, partly because the best-known ones are saturated and contaminated — see AI benchmarks explained.
The more informative framing is task horizon: how long a task, measured in the time it takes a competent human, can a model complete with some given success rate? This captures the thing practitioners actually care about, which is not whether an agent can do a task but how far it can go before it goes off the rails. Published estimates put current frontier models in the range of a few hours of human work at a fifty per cent success rate, with that horizon roughly doubling on a timescale of several months.
Two honest caveats on that figure. It is measured on software and technical tasks, which are agents’ best domain. And a fifty per cent success rate on a multi-hour task is not a standard most businesses would accept unsupervised.
How agents fail
- Context exhaustion. The agent takes on more than fits, fills its window mid-task, and loses the thread. The standard mitigation is scaffolding outside the model — progress files, structured task lists, version control history — so state survives independently of the conversation.
- Premature completion. The agent declares success without verifying. Mandatory end-to-end checks before a task can be marked done are the standard answer.
- Compounding error. A small early mistake becomes the basis for later steps. Long chains amplify rather than average out errors.
- Cost unpredictability. A loop with model-chosen length has model-chosen cost. Approaches reaching similar accuracy can differ in cost by more than an order of magnitude.
The security problem is the real blocker
The most serious limitation on agent deployment is not capability. It is that prompt injection remains structurally unsolved.
An agent reads web pages, documents, emails and tool results. All of that arrives as tokens in the same stream as its instructions. There is no reliable mechanism separating “this is data I am processing” from “this is an instruction I should follow”. An attacker who can place text anywhere the agent will read can attempt to redirect it.
Security analyses of agentic systems consistently find prompt injection implicated across the majority of top risk categories, and it is not a patchable bug — it follows from how these models consume input. The practical response is architectural: constrain what agents can do irreversibly, require confirmation for consequential actions, and assume any content the agent reads may be adversarial.
How to read agent claims
When evaluating an agent product, the questions that separate substance from demo are consistent: what is the task horizon, not the benchmark score? What happens when a step fails? What can it do without asking? How does cost vary across runs? And what is the plan for untrusted input?
Related: tool use and MCP, and context windows explained.
Last reviewed: September 2026.
