What Is an AI Agent? A Definition That Excludes Things
5 min read · updated August 3, 2026
A definition that includes everything defines nothing. “AI agent” currently covers a chatbot with a search box, a cron job that summarises tickets, and a process that opens pull requests unsupervised. Those three have almost no engineering problems in common, which is a sign the word has stopped carrying information.
Why the word stopped meaning anything
The pressure is commercial: “agent” sells and “pipeline” does not, so every pipeline was renamed. The cost is that engineering advice no longer transfers. Advice about stopping conditions is meaningless for a system that runs a fixed three-step chain, and advice about prompt templates is nearly useless for a system that will take forty unplanned actions against a live repository.
The technical lineage is much narrower than the marketing. The pattern almost everyone means was described in ReAct (Yao et al., 2022), which showed that interleaving reasoning traces with actions against an external environment outperformed either on its own across question answering and text-game benchmarks. Thought, action, observation, repeat. Everything since has been engineering around that loop — better tools, longer horizons, budgets, sandboxes — rather than a different idea. Which is useful to know, because it means a system that never observes the consequences of its own actions is not a weaker agent. It is a different thing wearing the name.
A definition earns its keep by excluding. Here is one that does.
The three-part test
A system is an agent to the extent that all three of these hold. They are deliberately about control flow, not about intelligence.
- 1. The model chooses the next step. Not which branch of a branch you wrote — which action, from a set, in an order you did not fix in advance. If you can draw the sequence of calls before the run starts, the model is not choosing anything; your code is, and the model is filling in text.
- 2. It loops on its own output. The result of the action goes back into the context and influences the next decision. One model call followed by one function call is a function call. The loop is what makes the number of steps a runtime property rather than a source-code property.
- 3. It can fail in ways you have to handle at runtime. It can loop forever, spend more than you budgeted, take an action you cannot undo, or stop while claiming success. If none of those are possible, you have a workflow, and you should be pleased — workflows are cheaper to operate and you should prefer them.
Note what is absent. Nothing about planning, reasoning, autonomy, goals, or memory. Those are implementation choices inside the loop. The test is about whether control flow is decided at runtime by a stochastic process, because that is the property that changes what you have to build around it.
Applied to six systems
| System | Description |
|---|---|
| Chat + retrieval | Retrieve, then answer. Fixed order, one hop, no branch the model picks. Fails the test on all three counts. Calling it an agent buys nothing. |
| Classify → route → template | The model picks a branch, but from a set you enumerated, and the run ends. Passes (1) weakly, fails (2) and (3). This is a workflow, and it is the right shape for most production tasks. |
| Chat with tools, one turn | Model may call get_weather then answer. Chooses an action, but the loop depth is capped at one round trip in most implementations. Borderline — and the borderline is where most product features actually live. |
| Coding agent on a repo | Reads, edits, runs tests, reads the failure, edits again. All three hold, emphatically: unbounded steps, irreversible writes, and a real chance it declares victory on a red build. |
| Nightly triage job | Depends entirely on whether it can act. Reads issues and posts a summary: workflow. Reads issues, decides to close some, and re-reads to check: agent, with a blast radius. |
| Computer-use browsing | Passes all three and adds a fourth problem — the environment supplies untrusted text straight into the context. The most agentic and the least predictable. |
Agency is a dial, not a badge
The useful version of the test is not binary. Each part has a magnitude, and the magnitudes are what you should be quoting in a design review:
- Branching factor — how many tools are available at each step. Two is nearly a workflow. Forty is a search problem.
- Horizon — the step budget. A three-step cap is a different system from a fifty-step cap even with identical code, because at fifty the context and the cost both grow into new failure modes.
- Blast radius — what the worst single action can do. Read-only against a staging copy and “can send email to customers” deserve different review, different gates and different on-call expectations.
- Recoverability — whether a wrong step is observable to the agent and undoable by it. An agent working in a git worktree can watch a test fail and revert; an agent that has already sent the message cannot. This dial decides how much of your engineering goes into recovery rather than prevention.
Two systems with the same architecture diagram can sit at opposite ends of all three dials. The diagram is not the design; those numbers are.
Why the distinction is operational
Every hard problem in this cluster is downstream of the three-part test, and none of them apply to a workflow. If the model chooses the next step, you need tool descriptions good enough to choose from and a catalogue small enough to choose within. If it loops, you need a stopping condition that is not the model’s opinion and a budget that is checked before each call rather than after. If it can fail at runtime, you need per-step traces, because “it did something weird on Tuesday” is unanswerable without them.
So the test has a practical payoff in both directions. Run it on a system that passes and you have a checklist of what you still owe it. Run it on a system that fails and you have permission to stop building agent infrastructure for something that will never need it — which, for the majority of production LLM features, is the correct outcome. The most common expensive mistake in this area is not a badly built agent. It is a well-built agent doing a job a three-step chain would have done more cheaply, more predictably, and with a stack trace when it broke.