AI Agent

An AI agent is what you get when you stop asking the model for one answer and instead let it run in a loop: it decides on an action, takes it through a tool, observes the result, and decides again, repeating until the goal is met. Anthropic's "Building effective agents" frames the core building block as the augmented LLM, a model given tools, retrieval, and memory. An agent is that block placed inside a loop where the model, not your code, chooses the next step. The lineage runs back to the 2022 ReAct paper, which showed that interleaving reasoning ("the test failed on a null check") with actions ("open that file and look") beats either alone, and the ReAct pattern is still the skeleton inside most production agents.

Model, tools, loop, stopping condition#

Four parts make an agent. A model that decides what to do next. A set of tools it reaches through tool calling, both to act on the world and to read ground truth back from it: run a query, edit a file, hit an API. A loop that runs think, act, observe over and over. And a stopping condition that ends the run: task complete, an unrecoverable error, a human checkpoint, or a hard cap on iterations.

The loop is the defining feature, because it lets the system handle tasks where you cannot script the steps in advance. Ask an agent to "make the failing payment test pass" and there is no fixed pipeline that gets you there. It runs the test, reads the stack trace, opens the implicated file, notices a currency rounding bug, edits, reruns, and repeats until green. Each tool result changes what it does next. That feedback-driven adaptivity is the thing a predefined sequence of LLM calls cannot give you.

Workflow or agent: pick the cheapest thing that works#

Not everything that calls an LLM is an agent. A workflow orchestrates models and tools along code paths you wrote: classify the ticket, then draft a reply, then check the tone. An agent lets the model direct its own path. Anthropic's published workflow patterns, prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer, cover a surprising share of real systems with your code firmly in control.

The selection rule is boring and correct: use a workflow when you can enumerate the steps, and an agent when you cannot. Invoice extraction is a workflow, the same five steps every time, and predictability is the feature. "Figure out why signups dropped 18% last week" is agent-shaped: the answer might live in analytics, a deploy log, or a broken email template, and the path only reveals itself as evidence comes in. Both Anthropic's guidance and OpenAI's agent guide say to reach for the agent last: start with a single well-built prompt, add retrieval or a fixed workflow, and only accept an open-ended loop when the simpler designs measurably fall short. Agents trade predictability, latency, and cost, often 5 to 20 times the tokens of a single call, for flexibility you should be sure you actually need.

Why autonomy multiplies error#

A single LLM call that is right 95% of the time feels solid. Put that reliability inside a loop and the arithmetic turns against you, because success has to compound across every step. At 95% per step, a 5-step run finishes clean about 77% of the time, a 10-step run about 60%, and a 20-step run just 36%. By 50 steps you are at roughly 8%.

And it is worse than the raw numbers suggest, because agent errors are not independent coin flips. One wrong step changes the context for every later step: an agent that misreads a database schema at step 3 writes confident, well-formed, wrong queries from step 4 onward. Errors do not just accumulate, they steer. That is why agent reliability work focuses less on making any single step smarter and more on making bad steps detectable and recoverable: ground truth the agent can check itself against (does the test pass, does the page render), and evals that score whole trajectories rather than single answers.

Guardrails that make agents shippable#

Production agents are loops wrapped in distrust. The non-negotiables:

Hard-cap the loop. Always set a maximum iteration count and a token or dollar budget, so a confused agent fails fast and cheap instead of grinding forever. A cap of 10 to 30 steps covers most tasks; work that legitimately needs more should checkpoint and resume rather than run unbounded.

Least-privilege tools. Give the model the fewest tools that can do the job, read-only by default, with credentials scoped to the task rather than the system.

Sandbox the blast radius. Coding agents work on branches, not main. Anything touching production data runs against replicas or behind feature flags until it has earned trust.

Human gates on one-way doors. Reversible actions can be autonomous; irreversible ones (sending money, deleting records, emailing customers) pause for approval.

Trace everything. Log every step, tool call, and result. You cannot debug a 20-step trajectory you did not record, and traces are the raw material for your evals.

What changed in 2025 and 2026#

Agents went from demos to defaults in about two years, in three visible waves. Coding agents matured first, because code gives the loop free ground truth: compilers and test suites tell the agent when it is wrong. Tools like Claude Code, Codex, and Cursor converged on the same loop-plus-tools architecture and now run plan, edit, test cycles for hours. Computer use extended agents beyond APIs: models can operate browsers and desktops by reading pixels and clicking, slower and less reliable than an API call, but it covers the long tail of software that has no API. Long-running agents are the current frontier: METR, which measures the length of software tasks agents can finish at 50% reliability, has watched that horizon double roughly every four to seven months, and by mid-2026 frontier agents complete tasks that take human experts most of a working day. Underneath all three, the Model Context Protocol became the cross-vendor standard for plugging tools into agents, and harder problems are increasingly split across multi-agent orchestration, where a lead agent decomposes the goal and delegates to focused sub-agents.

Practical takeaway#

An agent is a model, tools, a loop, and a stopping condition; everything else is engineering around that sentence. Build the workflow first and graduate to an agent only when the task genuinely resists scripting. When you do, respect the compounding math: cap the loop, shrink the toolset, gate the irreversible, give the agent ground truth it can check itself against, and measure whole trajectories, not single answers. Autonomy is a budget you spend deliberately, not a feature you switch on.