Agentic behaviour means the model chooses the next step

The short version

• Agentic behaviour means an AI model chooses its own next action, instead of following steps fixed in code.
• An agent runs in a loop: choose an action, call a tool, read the result, choose again, until it stops or a limit stops it.
• How agentic a system is depends on which tools it can call and which actions need human approval, both set by whoever deploys it.
• Every extra step is another chance for error, so agents become less reliable as tasks get longer.
• If the steps of a task are known in advance, a fixed workflow is cheaper, faster and easier to test than an agent.

What is agentic behaviour?

Agentic behaviour is when an AI system chooses its own next step. Given a goal and a set of tools, it decides what to do, does it, looks at the result and decides again. The sequence of actions is not written in advance by a developer. It comes from the model's choices, one turn at a time.

Mechanically, it is a loop. The application gives the model a goal and a description of the tools it may call, such as a search, a database query or an email send. The model replies with either an answer or a request to call a tool. The application runs the tool, adds the result to the conversation and asks the model again. This repeats until the model says it has finished or a limit set outside the model ends the run.

Everything else people mean by the term follows from that loop. Planning is the model choosing a sequence. Tool use is the model reaching outside its own text. Self-correction is the model reading a failed result and trying something different. These are not separate components bolted on. They are what the loop looks like when it works.

How is an AI agent different from a chatbot or a workflow?

The difference is who decides what happens next. A chatbot answers one message and waits. A workflow runs steps a developer fixed in code, with a model filling in parts such as classifying an email or drafting a reply. An agent picks its own steps, and may pick different ones each time it runs.

So the useful test for any product sold as agentic is simple. If you ran the same request twice, could it take a different path? If not, it is a workflow with a model inside it. That is not a criticism. For many business tasks it is the better design, because a fixed path can be tested, costed and explained.

How do chatbots, workflows and agents compare?

What does an AI system need to show agentic behaviour?

At minimum it needs a goal, tools it can call, a loop that feeds each result back to the model, and a way to stop. Remove any one and the behaviour stops being agentic. Without tools it can only talk. Without the loop it acts once. Without a stop condition it has no reliable way to know when to quit.

A production agent also needs permissions: a decision, made in code, about which tool calls run on their own and which wait for a person. That part is what separates an agent you can deploy from one you can only demonstrate.

What are the parts of an agent loop?

• •Goal: the task in plain language, often with constraints on scope, time or budget.
• •Tools: functions the model may call, each with a name, a description and defined inputs. The tool list is the outer boundary of what the agent can do.
• •State: the running record of what has been tried and what came back, usually the conversation itself, sometimes backed by a separate memory store.
• •Stop condition: the model declaring it has finished, plus hard limits on steps, time and spend that the model cannot override.
• •Permissions: which tool calls run automatically and which need human approval first.

Is agentic behaviour all or nothing?

No. It is a matter of degree, set by two dials the deployer controls: how many decisions the model is allowed to make, and how much it may do before a person checks. The same model can be a cautious assistant that only suggests actions or a system that sends emails and edits records unsupervised. What changes is the tool list and which calls need approval.

A practical scale has four rungs. The agent suggests and a person acts. The agent acts, but a person approves each consequential step. The agent acts freely within narrow limits, such as read-only tools or a spending cap. The agent acts freely across everything it can reach. For anything that touches money, customers or records, the second and third rungs are the sensible place to start.

Autonomy can be observed rather than asserted. Anthropic studied agent autonomy in practice using a random sample of 998,481 tool calls from its public API and 500,000 interactive Claude Code sessions. The lesson for anyone running an agent is in the method, which looks at what agents actually did rather than what they were designed to do. Your own logs support the same exercise: which tools were called, how often a person stepped in, and what ran with no review at all.

Why does agentic behaviour fail in ways a demo does not show?

Because every step is another chance to be wrong, and errors compound. A demo shows one run of a task chosen because it works. Production runs the agent again and again on inputs nobody chose, and a small error rate per step becomes a large one per task once enough steps are chained together.

The failures have recognisable shapes. The agent calls the right tool with the wrong input and carries on as if it worked. It loops, retrying an action that keeps failing. It decides it is 'done' when it is not. It reads a web page or document that contains instructions and follows them, because to the model, text in a tool result looks much like text from the user.

None of these appear when you check whether the right answer came back on a good day. They appear when you read the full trace of a bad one. That is why building an agent is mostly evaluation and limits, and comparatively little prompt writing.

How is an AI agent's capability measured?

One useful way is to measure how long a task an agent can complete, judged by how long the same task takes a skilled person. METR's Time Horizon 1.1 does this with a suite of 228 software and reasoning tasks timed against skilled humans, and reports the task length frontier models complete with 50% reliability.

The framing suits agentic behaviour because it tests the loop directly. Longer tasks need more steps, more tool calls and more recovery from mistakes, so the length of task a model can finish is a fair proxy for how well the loop holds together.

Read the reliability threshold carefully. Half is the right bar for tracking progress between models. It is not a bar for deployment. A system that finishes a task half the time is a research result. A business process needs to know what happens on the other half.

When is agentic behaviour worth building?

When the steps cannot be known in advance. If the right next action depends on what the last one found, such as investigating a support issue across several systems, an agent can earn its extra cost. If the steps are the same every time, a workflow is cheaper, faster and far easier to test.

The common mistake is reaching for an agent because a task sounds complicated. Complexity is not the test. Variability of the path is. Processing an invoice has many steps, but they are the same steps every time, so code should own the sequence and the model should handle only the parts that need language, such as reading the document.

A sound rule is to give a system the least autonomy that does the job. Start with a workflow. Let the model choose a step only where a fixed rule keeps breaking. Widen its freedom when the logs show it is safe to, not before.

How do you keep an AI agent under control in production?

By limiting what it can reach and recording everything it does. The model's judgement is the part you control least, so the safeguards belong in the code around it: the tool list, the approval gates, the hard limits and the logs.

What controls should every production agent have?

• •Only the tools the task needs, each with the narrowest permissions it allows.
• •Human approval for anything hard to undo, such as payments, deletions and messages to customers.
• •Hard limits on steps, run time and spend, enforced in code the model cannot change.
• •A rule that everything a tool returns is untrusted data, never instructions.
• •A log of every tool call with its inputs and outputs, so any run can be replayed and explained.
• •A set of real failure cases, rerun whenever the prompt, the model or the tools change.