AI agent
Last verified: June 2026· definition
An AI agent wraps a model in a loop: it reasons about a goal, calls a tool, observes the result, and decides the next step — repeating until the task is done. The model drives its own trajectory rather than answering once.
Agents are the right tool when a task is multi-step and hard to fully specify in advance, the outcome justifies the cost, and errors can be caught and recovered. For simple, well-specified tasks, a single call or a fixed workflow is cheaper and more reliable.
Production agents need guardrails: scoped tool permissions, human-in-the-loop checkpoints for risky actions, observability, and evals — otherwise they’re hard to trust and debug.
The loop is what makes it an agent
A single model call that returns a response is not an agent, however sophisticated the prompt. An agent decides on an action, takes it through a tool, observes the result, and decides again — repeating until it judges the goal met or a limit stops it. That loop is the source of both the capability and the difficulty: the system can accomplish multi-step work without being told each step, and it can also loop, drift from its objective, or take an action nobody anticipated.
Verification determines where agents work
Agents perform best where success is checkable by the agent itself. A coding task with a test suite gives a clear signal to iterate against, which is why agentic coding works as well as it does. Tasks with no automatic verification — anything where good is a matter of judgement — leave the agent optimising for whatever proxy it can measure, which is where confident, plausible, wrong output comes from. Assessing verifiability is the most useful early question about any proposed agent.
Permissions are the design problem
An agent acts, so what it is allowed to do bounds what can go wrong. Because it may read untrusted content, its actions can be influenced by material you did not write, which makes least-privilege scoping and approval gates on irreversible operations the load-bearing controls. Tool permissions should be enforced by the services exposing them using session identity, not by arguments the model supplies — anything the model can set is influenceable.
Bounded runs and graceful failure
An agent with no iteration or token budget can consume resources indefinitely when stuck, and stuck is a normal state rather than an exceptional one. Budgets are a necessary backstop, but a budget alone produces a run that stops without explanation. Pairing it with an explicit way for the agent to declare it cannot proceed converts a silent runaway into a useful report, which often names exactly the missing tool or permission.
Common misconceptions
MythAny LLM feature with tools is an agent.
RealityA single call that may invoke a tool is tool use. What distinguishes an agent is deciding and acting repeatedly in a loop toward a goal, without each step being specified.
MythMore autonomy makes an agent more useful.
RealityAutonomy is valuable in proportion to verifiability. Where success cannot be checked, greater autonomy mostly produces more confident output that nobody can efficiently review.
MythAgent reliability is mainly a model problem.
RealityTool design, error messages, verification signals, and permission scoping usually matter more. A strong model with poor tooling loops just as readily as a weaker one.
Frequently asked questions
What is the difference between an AI agent and a chatbot with tools?
Control flow. A chatbot with tools responds to each message, possibly calling a tool along the way, with a human driving every turn. An agent takes a goal and runs its own loop — planning, acting, observing results, and deciding what to do next — until it believes the goal is met. The human moves from directing each step to specifying the objective and reviewing the outcome.
When is an agent the wrong approach?
When the task has no automatic way to verify success, when the steps are known and fixed, or when the consequences of a wrong action are severe and hard to reverse. A fixed sequence of steps is better expressed as a workflow, which is cheaper and predictable. Agents earn their complexity when the path genuinely varies by input and the result can be checked.
How do I stop an agent doing something harmful?
Constrain what it is permitted to do rather than relying on it choosing correctly. Scope each tool to the narrowest capability its job needs, require explicit human approval for anything irreversible, enforce permissions in the services exposing the tools using authenticated session identity, and log every call. The aim is that even a fully misled agent cannot cause serious damage, because prompt-level instructions can be overridden by content it reads.