What is an AI agent?

The one-sentence definition

An AI agent is a language model given three things it does not have on its own: a job, tools, and a stopping condition. The model supplies judgment; the job says what to work on; the tools let it act on something other than the chat window; and the stopping condition — what counts as done — turns an open-ended conversation into a piece of work that finishes.

That is the whole definition. Everything else you read — autonomy, planning, memory, multi-step reasoning — is a property some agents have to some degree, not the thing that makes an agent an agent.

What separates an agent from a chatbot

A chatbot and an agent can be the exact same model. The difference is who carries the loop.

With a chatbot, you are the loop: you ask, it answers, you read the answer, decide what to do with it, ask again. The model never acts and never decides it is finished — you do both, one message at a time.

An agent carries the loop itself. Given “find out whether this vulnerability affects us and say whether we have to act today,” it looks the identifier up, pulls the scores, applies the rubric it was hired with, and reports a verdict. You read the result, not the seventeen intermediate steps.

Tools are what make the loop real

A model with no tools can only tell you things. An agent’s tools — search, page fetching, DNS lookups, an API for the system it works on — are declared, named capabilities, and a well-run agent has a short list of them. The narrow list is a feature: an agent that can call four search actions and nothing else cannot quietly do something you never intended. (For real rosters and their exact action lists, see AI agent examples.)

The stopping condition is the part that matters

The under-discussed half of the definition is the done-state. Work without one never ends — it just stops when you stop asking. An agent with a done-state can be wrong, and you can see that it is wrong, because there is a defined thing it was supposed to produce. “A sourced report on what changed this week, or an explicit statement that nothing did” is a done-state. “Keep an eye on the competition” is a wish.

This is why serious agent setups talk about jobs that run to done rather than agents that are simply “autonomous.” Autonomy describes how little you watch; done describes whether anything finished.

What an AI agent is not

• Not an employee. An agent does not own outcomes, learn your politics, or take responsibility. The person who assigns the work still owns the result — which is why review is part of the definition of using agents well, not an admission of failure.
• Not a smarter chatbot. The upgrade is structural (job, tools, done-state), not intelligence. A brilliant model with no stopping condition is still just a conversation.
• Not magic automation. Trigger-action tools like n8n or Zapier execute known steps reliably. Agents handle work where the steps are not known in advance. The two are different shapes, and sometimes the automation is the right pick — see workflow automation vs an agent workforce.

The anatomy of a working agent

Strip any honest agent system to its skeleton and you find the same five parts:

1. A role. A job description narrow enough to be checkable: “Web Researcher — a vague reference becomes concrete URLs and page text.”
2. A model. The reasoning engine behind the role — usually one you already subscribe to, connected with your own key.
3. Actions. The named tools the role may call, and nothing else.
4. Missions with done-states. The unit of work: an assignment that either reaches done or fails visibly.
5. A record. A receipt for every run — what was asked, what was done, what came back — kept whether the run succeeded or not.

Miss any of the five and the failure mode is predictable. No role: the agent wanders. No actions: it can only opine. No done-state: it never finishes. No record: you cannot trust what it says it did.

Where agents actually earn their keep

Agents are at their best on work that is real but nobody’s actual job: the weekly look at what competitors shipped, the brief before a sales call, the triage pass over an inbox, the check that DNS still matches what the internet resolves. Each has a clear done-state, needs judgment mid-task, and gets skipped when humans are busy — which is most weeks. The use-case library walks through seven sectors of this kind of work, each with the before-pain and what the person reviews at the end.

How to evaluate any agent claim

The word “agent” is doing heavy marketing duty right now, so a working test is worth more than the definition alone. When a product, a demo, or a colleague says agent, ask three questions of it:

1. What is the job? If the answer is a capability (“it can browse! it can code!”) rather than an assignment with an owner, you are looking at a feature, not an agent.
2. What can it touch? If nobody can enumerate the tools, the honest answer is “anything,” and “anything” is not a scope you can review.
3. How does it know it is done? If the demo ends when the presenter stops it, there is no stopping condition — and without one, the impressive middle never becomes a finished thing.

Systems that answer all three cleanly tend to be boring in the demo and useful in the third week. Systems that answer none of them tend to be the reverse.

Seeing the definition run

Ahel is one implementation of exactly this definition: agents are roles with named actions, hired onto a live map; work is missions with done-states; every run leaves a receipt in an append-only log. The models come from subscriptions you already pay for — you connect your own keys, and the security page describes factually what happens to them. Nothing on this page requires Ahel, though: the definition is the industry’s, and it should survive any vendor’s framing, including ours.

Questions people actually ask