AI agent

An AI agent is a system that perceives an environment, decides what to do, and carries the decision out. The definition is broad enough to cover a thermostat, a chess program, and a warehouse robot; what changed after 2022 is that language models made it possible to build agents for open-ended tasks in ordinary software 1.

An agent differs from a chatbot in that it acts. A chatbot answers; an agent books, edits, searches, runs code, or sends the message. That difference moves the problem from producing good text to controlling a sequence of actions with consequences, and it is why agent design is as much about permissions and feedback as about model quality 2.

This entry covers definitions, the emergence of language-model agents, their architecture, levels of autonomy, documented uses, and the reliability and security questions they raise.

The classical literature describes an agent as anything that perceives its environment through sensors and acts on it through actuators, with a decision function mapping percepts to actions. That taxonomy distinguishes reflex agents, which respond to current input; model-based agents, which maintain an internal state; goal-based agents, which plan; and utility-based agents, which weigh outcomes 1.

Contemporary usage is narrower. An AI agent usually means a language model placed in a loop with tools, memory, and an objective, able to choose its own next step. Anthropic's engineering guidance draws a further line between workflows, where a model and tools are orchestrated along code paths the developer wrote, and agents, where the model directs its own process and tool use 1.

Both senses are legitimate, but they predict different things. A system that fills in a form with a fixed sequence of model calls is a workflow by the narrow definition and an agent by the classical one. Much of the disagreement about whether agents work turns on which definition the speaker is using 3.

The idea of a software agent that perceives, plans, and acts is older than the language model. Classical planning systems searched over actions; expert systems encoded rules for narrow domains; software agents in the 1990s coordinated tasks across networks; and robotic process automation, from the 2000s, scripted repetitive back-office work. Each could act, but none could handle open-ended language or unfamiliar interfaces.

The turning point was the realisation that a language model could serve as the decision function. ReAct, published in 2022, interleaved reasoning traces with tool calls: the model wrote a step, took an action, observed the result, and revised its plan. That loop made it possible to use the same model for search, calculation, and API calls without training a separate policy for each task 2.

By 2023, function calling and open-source agent frameworks had turned the pattern into a product category. Coding agents became the most visible application because a repository provides a readable environment, a test suite provides feedback, and version control makes mistakes recoverable. SWE-bench, released in 2023, gave the field a common measure by asking models to resolve real GitHub issues and checking the result against the project's tests 4.

A typical agent has four parts. A model interprets the task and decides what to do next. Tools give it actions: search, code execution, file access, an API call, a browser. Memory holds the task state and relevant context, either in the prompt or in an external store. A control loop runs the cycle until the task is finished or a limit is reached 1.

The engineering is mostly in the scaffolding rather than the model. Tool descriptions determine whether the model chooses the right action; error handling determines whether it recovers or loops; context management determines whether it remembers the instruction it was given twenty steps earlier. These are software problems, and they account for much of the difference between a demonstration and a reliable product 3.

Guardrails sit around the loop. Input filters screen for prohibited requests, output filters check for sensitive data, and permission checks decide which tools the agent may call. Human checkpoints can pause execution before an irreversible action 5.

Multi-agent designs add a layer of delegation: a planner assigns subtasks to specialised agents, and a supervisor combines the results. This can help when tasks genuinely parallelise, but it also multiplies the opportunities for miscommunication. OpenAI's guidance recommends starting with a single agent and adding complexity only when a specific limitation requires it 3.

Autonomy is a spectrum, not a property. At one end, the agent proposes an action that a person must approve. In the middle, it acts within narrow permissions and reports afterwards. At the other end, it pursues a goal for hours without supervision. Each step up trades oversight for throughput, and the trade is only reasonable when errors are cheap or reversible 1.

Many deployed systems sit in the middle, with permitted tools, a budget, and a log. A coding agent may edit files and run tests but not deploy to production; a customer-service agent may issue refunds below a threshold and escalate above it. These boundaries are product decisions as much as technical ones, and they determine the blast radius of a mistake 5.

NIST's risk-management framework treats the boundary of an agent's authority as something to specify and document before deployment rather than discover in operation. In practice that means deciding in advance what the agent may read, what it may change, and whom it must ask 5.

The harder oversight problem is competence. A human reviewer who approves dozens of actions an hour stops reading them carefully, and an agent that is usually right trains its supervisor to trust it. Oversight therefore depends on sampling, anomaly detection, and periodic independent review, not only on a confirmation button 5.

The clearest successes are in software. Coding agents read a repository, propose patches, run tests, and iterate; they are useful because the environment is instrumented, the feedback is immediate, and mistakes are recoverable through version control. SWE-bench was built to measure exactly this loop, and performance on it has risen quickly, though the benchmark measures a curated distribution of issues rather than the full job 4.

Research and analysis agents search, read, and synthesise documents, with citations that a person can check. Customer-service agents handle multi-step requests that span several systems, escalating when confidence is low. Computer-use agents operate graphical interfaces intended for people, which is powerful and fragile in equal measure: the interface was not designed for them, and a small change in layout can break a workflow 1.

Robotic process automation is the ancestor. It scripts repetitive tasks with deterministic rules; the newer systems add the ability to handle variation, at the cost of predictability. That trade explains why agents often start in back-office work with reversible errors, and why regulated industries adopt them more slowly than software companies 3.

Away from software, the evidence is thinner. Agents that book travel, manage calendars, or negotiate purchases are demonstrated regularly and deployed rarely, because the environments are adversarial, the APIs are inconsistent, and the cost of a wrong action falls on the user 6.

Agents fail differently from chatbots. A single wrong answer is an inconvenience; a wrong action can delete a file, send an email, or make a purchase. Errors also compound, since each step depends on the state left by the last. A model that succeeds 95 per cent of the time at each of twenty steps completes the sequence less than 40 per cent of the time, which is why long-horizon reliability is the binding constraint 7.

Prompt injection is the characteristic vulnerability. An agent that reads web pages, emails, or documents can encounter text instructing it to ignore its task and do something else, and the model has no reliable way to distinguish data from instructions. OWASP lists prompt injection as the first risk for large language model applications, and the defences available, including content filtering and privilege separation, reduce the risk without eliminating it 8.

Over-permissioning is the other recurring problem. An agent given broad credentials to be useful also has broad scope to cause harm, and least privilege is often sacrificed for convenience. The combination of injection and broad permissions is what turns a malicious web page into a data breach or an unauthorised transaction 5.

Monitoring is the practical backstop. Logs of tool calls, inputs, and outputs allow an operator to reconstruct what happened and to detect patterns that individual checks miss. They also create a privacy problem, because a trace may contain everything the agent read, including material the user did not intend to store 5.

Evaluating an agent is harder than evaluating a model, because success depends on the environment, the tools, and the task distribution. Benchmarks exist for coding, browsing, and computer use, and they are useful for comparing approaches, but they tend to reward narrow optimisation and to saturate quickly. A high score on a benchmark with a fixed tool set may not transfer to a different set of APIs 4.

METR's time-horizon metric offers a complementary view. Instead of asking whether a model can complete a task, it asks how long a task the model can complete with 50 per cent reliability, measured in the time a skilled human would take. In early 2025 the frontier was about 50 minutes, doubling roughly every seven months since 2019. The authors caution that the trend may not generalise to real-world work, but the metric captures reliability and persistence in a way that single-task accuracy does not 7.

Production evaluation relies on traces: recorded sequences of actions, with outcomes and human judgements. Traces reveal where an agent went wrong, which summary scores hide. They also raise privacy questions, since a trace may contain everything the agent read. The field's open problem is specification: a task stated in a sentence rarely determines which actions are acceptable, and agents that optimise the stated objective may violate the unstated one 5.

Agents are expensive in a way that chatbots are not. A single request may involve dozens of model calls, each carrying the accumulated context, and a long-running task can consume millions of tokens. Inference cost, latency, and human supervision all scale with the length of the trajectory, so the economics improve only when the task is valuable enough to justify the compute and the oversight 1.

Vendors have an incentive to describe products as agents because the label signals autonomy and justifies higher prices. Buyers have an incentive to deploy them because the labour being automated is expensive. The result is a market with strong promotional pressure and weak public evidence on return on investment. Gartner forecast in 2025 that more than 40 per cent of agentic AI projects would be cancelled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls 6.

That forecast may prove wrong, but it points to a real pattern: the projects that succeed tend to be narrow, measurable, and integrated into an existing workflow, while the projects that fail attempt broad autonomy without a clear owner. The economics favour augmentation of a specific task over replacement of a role 3.

The labour effects are similarly uncertain. Agents can substitute for routine cognitive work, particularly in software, customer service, and document processing, and they can complement workers by handling the parts of a job that are repetitive. Which effect dominates depends on the task, the institution, and the pace of adoption, and the evidence base is still thin 6.

The definition is contested. Some practitioners reserve agent for a system that chooses its own steps, and call everything else a workflow. Others use agent for any model that calls a tool. The first definition is analytically useful; the second is commercially useful, because it lets a product join the category. Most disagreements about whether agents are overhyped are really disagreements about which definition is in play 1.

Autonomy is contested in the same way. One camp argues that reliability improves only when agents are given more freedom to recover from errors; another argues that the safest path is to constrain the action space and keep a person in the loop. The evidence supports both at different scales: narrow autonomy works today, and broad autonomy remains a research problem 5.

The value of the category is contested. Vendor case studies emphasize successful deployments; Gartner's forecast emphasizes cancellation rates; academic benchmarks emphasize task success under controlled conditions. None of these is a neutral measure of whether agents are useful, because each selects a different population of tasks and a different definition of success 6.

Safety is the sharpest disagreement. One view holds that prompt injection is an unsolved vulnerability that makes open-ended agents unsuitable for sensitive work. Another holds that defence in depth, least privilege, and monitoring make the residual risk manageable for many applications. Both positions can be defended from the same evidence, which is why deployment decisions turn on the value of the task and the cost of the worst case rather than on a general verdict about agent safety 8.