What agentic AI actually means

A plain language model answers once: text in, text out. An agentic system runs a loop — it decides on an action, takes it, observes what happened, and decides again, until it judges the task done or something stops it.

The load-bearing word is decides. If your code fixes the sequence — retrieve, summarise, email — that is a pipeline with a model in it, no matter what the marketing says. It becomes agentic when the model chooses which step comes next, and can choose differently based on what it just saw.

This is worth being pedantic about because the two have completely different engineering profiles. A pipeline is testable, repeatable and cheap to debug. An agent is none of those, and adopting one where a pipeline would do is a decision that costs months.

Every agent framework is a variation on the same four parts. Knowing them makes it much easier to read any product claim and work out what is really being offered.

Most of the engineering effort goes into the last two. Deciding what to do is what models are good at; doing it reliably, safely and within a budget is what the surrounding system has to provide.

Frameworks differ mainly in how much of that surrounding system they supply. That is worth checking before adopting one, because the parts they leave to you — state persistence, idempotency, budget enforcement — are the parts that determine whether the thing survives production.

• A goal, stated once by the user
• A set of tools, each with a description the model selects from
• A loop that feeds each result back as the next input
• Stopping conditions — success, a step limit, a budget, or a human saying no

In a single-shot system a mistake is contained: you get one wrong answer and you can see it. In a loop, step three is built on step two, so a small early error becomes the premise for everything after it. Agents fail by drifting confidently rather than by stopping.

This is why agent reliability is discussed in terms of trajectories rather than outputs. An agent that reaches the right answer after forty tool calls and two destructive mistakes has not succeeded, even though the final message looks fine.

The arithmetic is worth internalising. A step that is right 95% of the time is right about 60% of the time across ten dependent steps and about 36% across twenty. That single calculation explains most of the gap between agent demos and agent deployments.

Given that arithmetic, the systems that succeed do one of two things: they reduce the number of dependent steps, or they verify each one so an error cannot become the next premise.

Coding agents are the clearest success because the environment verifies them for free. A test suite reports failure at the step that caused it, which breaks the compounding chain — the agent is corrected immediately rather than building on a mistake.

That generalises into the most useful question you can ask of any proposed agent use: does the environment tell the agent when it is wrong? Where the answer is yes, agents work far better than the raw numbers suggest. Where it is no, they fail invisibly.

Agentic design pays off when the number of steps cannot be known in advance and the cost of a wrong step is low or reversible. Research across an unknown number of sources, triaging a queue of varied items, exploring a codebase to answer a question — these have no fixed script, so letting the model choose is a real gain.

It pays off badly when the task is already well defined. If you know the steps, write the steps. A deterministic pipeline is cheaper, faster, testable and debuggable, and choosing an agent instead buys you unpredictability you will spend months managing.

A reasonable default is to build the pipeline first and let it fail. The places where it cannot cope — where the right next step genuinely depends on what the last one returned — are exactly where an agent belongs, and you will have identified them from evidence rather than from enthusiasm.

Demos are far ahead of deployments, and the gap is not about model capability. It is that autonomy multiplies the consequences of being wrong, so anything touching money, messages or permanent records ends up with a human in the loop — at which point much of the promised time saving goes back.

The systems working in production today are narrow: a bounded task, a handful of tools, tight limits, and a person approving anything irreversible. That is less exciting than the pitch and considerably more useful, and it is the version worth learning to build.

The right posture is neither dismissal nor enthusiasm. Agents are a genuine capability with a well-understood failure mode, and teams that design around the failure mode rather than hoping it improves are the ones shipping things that work.

• Narrow scope beats general autonomy in every shipped system so far
• Fewer, well-described tools outperform many granular ones
• Step and cost ceilings are features, not limitations
• Human approval gates are where most real deployments draw the line