What an AI Agent Actually Is, and What It Is Not

"AI agent" now describes a chatbot on a shopping site, a coding tool that opens pull requests, and a research assistant that reads a hundred documents. Those are not the same thing, and treating them as one is why so many conversations about agents go nowhere.

The distinction that matters

A model answers. An agent acts.

For a vendor-side perspective, Monitask also has a page on productivity vs efficiency.

A language model on its own produces text. You give it input, it returns output. It cannot look anything up, change anything, or find out whether it was right.

An agent is a model given tools and a loop. It can call a search, read a file, query a database, send a message, run code — and then look at the result and decide what to do next.

The loop is the essential part. Not one response, but: decide what to do, do it, look at what came back, decide again. That is what separates an agent from everything before it.

A working definition

An agent has four properties. Something missing several of them is probably not an agent, whatever it is called.

Goal-directed. Given an objective rather than a script. "Find out why this invoice is unpaid" rather than "run these six steps".

Tool-using. Can take actions in real systems, not only produce text.

Iterative. Observes the result of each action and adjusts. Handles the case where the first attempt failed.

Bounded autonomy. Makes decisions within limits someone set — which tools, which data, what requires approval.

That last one is doing a lot of work, and it is where most real-world difficulty lives. See permissions.

What gets called an agent and is not

Not pedantry. The categories have different costs, different risks and different failure modes.

A chatbot. Answers questions from a knowledge base. No tools, no actions, no loop. Useful, and not an agent.

A workflow automation. Fixed steps in a fixed order, triggered by an event. Deterministic, predictable, and it does not decide anything. Frequently the better choice — see when an agent is the wrong answer.

A single model call in a wrapper. One prompt, one response, presented in a product interface.

A recommendation system. Predicts and ranks. Does not act.

"Agentic" as an adjective on an existing product. Increasingly attached to software that has not changed. Ask what it can actually do and what happens when the first attempt fails.

The test: can it take an action in a real system, see the result, and try something different? If not, it is not an agent, and it may be entirely adequate for your purpose.

Why this became possible when it did

Three things had to arrive together, and they did around 2024–2025.

Models became reliable enough at tool use. Deciding which tool to call, with which arguments, and interpreting the result. Below a certain reliability an agent compounds its own errors and produces nothing usable — small error rates multiply across multi-step processes.

A standard way to connect tools. The Model Context Protocol gave agents a common interface to enterprise data and systems, replacing bespoke integration for each pairing.

Enough failed pilots to learn from. Organisations now have institutional memory about what scoping actually requires, which is unglamorous and is a genuine input.

Degrees of autonomy

Not a binary, and the level determines nearly everything about cost and risk.

Suggests. Proposes an action; a person carries it out. Lowest risk, most human effort, and frequently the right starting point.

Acts with approval. Prepares the action; a person approves before it executes.

Acts within limits. Executes autonomously inside a defined scope, escalating outside it.

Acts freely. Rare in production, for good reason.

Most deployments that work sit in the middle two. The marketing describes the fourth. See human oversight.

What this means for you

If you run a business: the question is not "should we use agents" but "which specific task, and what happens when it gets that task wrong". Most value so far is in scoped, repetitive, high-volume work where an error is recoverable. For broader independent background, see NIST AI Risk Management Framework.

If you work alone or in a small team: you are already using agents if you use a current coding assistant or research tool. The practical questions are cost and what you let them touch. See agents for a one-person business.

If you are technical: the difficult part is not the model. It is integration, permissions, observability and cost. See integration is the hard part.

The vocabulary, briefly

Tool call — the agent invoking something external.

Context — everything the model can see when deciding. Finite, and managing it is a real constraint.

Orchestration — coordinating several agents or steps.

Guardrails — limits on what the agent may do.

Human in the loop — a person approving or reviewing actions.

Multi-agent — several agents with different roles working together. Currently more discussed than deployed successfully.

The honest summary

Agents are genuinely new in a way that previous automation was not: they handle situations nobody scripted.

They are also less capable than the marketing suggests, and the gap between "an agent is embedded in this product" and "an agent reliably does this job" is large. See where agent projects fail.

And a great deal of what is sold as agentic is not. The four properties above are a usable filter.

The short version

A model answers; an agent acts — with tools, in a loop, adjusting based on results.

Four properties: goal-directed, tool-using, iterative, with bounded autonomy.

Chatbots, fixed workflows and single model calls are not agents, and are frequently the better choice.

Autonomy is a spectrum, and the deployments that work sit in the middle.

And "agentic" attached to an existing product usually means nothing — ask what it does when the first attempt fails.