What is an AI agent?

The difference isn’t tools, loops, or intelligence. It’s authority, what a system is permitted to decide, and what it is permitted to do.

Ask ten people what makes an AI agent different from a chatbot and you’ll hear the same three answers: agents can call tools, agents run in a loop, agents execute things instead of just talking. All three are true of agents. None of them defines one.

Modern chat interfaces call tools fluently: they run code, search the web, query databases. Yet we hesitate to call every chat turn “agentic.” Meanwhile, a payments pipeline at a bank loops over transactions and executes actions all day without a human in sight, and nobody calls it an agent.

A sharper answer says: an agent chooses its actions at run time, while automation merely executes what a developer wrote in advance. Closer, but still not right. Ordinary algorithms choose at run time constantly: a chess engine selects moves in positions no developer ever enumerated; an optimiser searches spaces no human has seen. And from the other side, a model’s weights, tools, prompts and permissions were all fixed at design time too. Saying the model “authors” its control flow while the algorithm merely “executes” one can end up describing similar computation with different verbs.

So if it isn’t tools, loops, execution, or even run-time choice, what is it?

Authority over the method

Two ideas do the real work.

Put together, the definition is short:

And agency is the degree of decision and action authority delegated to a system over the means of pursuing an objective.

Notice what’s absent from both ideas: intelligence. The most capable model in the world, wired in as a classification step inside a scripted pipeline, has zero agency. A modest model on a long leash has plenty. Competence measures how well a system chooses; agency measures which choices it is authorised to make. They are different axes, and a badly performing agent is still an agent.

Three configurations, not three species

It helps to stop thinking of assistants, automations and agents as kinds of software, and start thinking of them as configurations: three ways of dividing the work between a human, pre-written code, and a model.

The tell is what crosses the interface:

One caution: the handover is never grammatical. People give assistants goal-shaped prompts and give agents detailed procedures. What varies is not the sentence form but the authority that travels with it. With that understood, the mnemonic can stand:

You give an assistant instructions and keep the method; you give an agent an objective and delegate the method.

One task, three ways

Take a job every bank knows: a client file flagged in periodic KYC screening, with the objective “resolve this alert within policy.”

Same task, same objective, three configurations. What changed is who owned the method, and what the system was authorised to execute.

Three questions to diagnose any system

When you meet a system in the wild, three questions locate it quickly:

These are heuristics, not laws, and they lean on a judgement call hidden in the word material: selecting one of three predetermined routes is a sliver of discretion, not command of the method. Where the questions give a clear answer, the label is fair. Where they don’t, read the settings instead of arguing about the label.

Classify episodes, not products

Because the labels blur exactly where modern products live. Ask a chat product to reconcile two spreadsheets and watch it write code, run it, hit an error, fix it, and re-run: a ninety-second agentic episode (high discretion, short horizon, sandboxed authority) delegated by an assistant-style outer loop. A workflow with a model-based router is an automation with one learned branch. Neither product “is” an agent or “isn’t” one.

So ask the well-formed question: in this episode, how was the work divided? Agency is a dial, not a badge: how far the system may run between checkpoints, what it may execute rather than recommend, how much of the method is its to decide, and how consequential and reversible its actions are. Those settings, not the noun, are what a design review should read.

The stage everyone forgets

Mechanically, an agentic episode is a control loop: sense, plan, act, and then reassess (the stage that gets skipped in most diagrams), where the system re-reads the situation in light of what just happened.

(To be precise about who does what: the model proposes, interprets and revises; the harness around it stores state, enforces permissions and executes actions. A bare model call retains nothing.)

Reassessment is where agents fail in practice. Ignoring a tool result. Retrying an action that already failed. Drifting off-objective over a long run. These characteristic failures usually involve a failure to incorporate feedback, and state that accumulates correctly across iterations is what makes a loop cumulative rather than circular. When an agent seems to go in circles, look there first.

Delegation has a paper trail

If this framing sounds familiar to readers in financial services, it should. The industry has been delegating authority over the means for a century: the difference between an advisory and a discretionary mandate is, to a useful approximation, the difference between an assistant and an agent. Under the first, the client receives recommendations and authorises each step; under the second, the client hands over an objective with constraints and the manager decides the method. The analogy is partial (it’s mostly about execution authority), but the machinery transfers: objectives, constraints, limits, reporting, review. Institutions that already write discretionary mandates own most of the vocabulary an agent deployment needs.

And the mandate tradition carries one more lesson, worth adopting as a governance principle for AI:

The short version

This is Part I of a three-part series: Part II unpacks the loop every agent runs, and Part III locates where agency and accountability actually live.