Agentic AI vs generative AI vs AI agents

The short answer

These three terms are used interchangeably in vendor material, on conference stages, and in a great many board decks. They are not interchangeable, but the reason they get confused is not laziness — it is that the industry never agreed on the boundaries, and the largest vendors publish definitions that quietly conflict with one another. This page gives the distinctions that hold up, then shows exactly where the official definitions diverge.

Generative AI

The important property is containment. A generative model that hallucinates a statistic has produced a wrong sentence on a screen. A human reads it, and either catches it or does not. The failure is bounded by the fact that nothing happened — the model has no hands.

This is also why the evaluation problem is comparatively simple. You can assess generative output by looking at it. The artefact under review is the entire behaviour of the system.

AI agents

Two components make an agent an agent, and both are required. The first is tools: functions that reach outside the model into real systems — query a database, issue a refund, book a slot, send a message. The second is the loop: the agent sees the result of its own action and chooses the next one based on what actually happened rather than what it predicted would happen.

Remove the tools and you have a model that reasons at length and produces text — impressive, but generative. Remove the loop and you have tool calling: one action in service of one answer. Neither is an agent, and the difference is not pedantic, because the loop is precisely where both the capability and the danger live.

Why the loop changes the risk profile

A single wrong tool call is a bounded error. A loop compounds: the agent acts on a mistaken belief, observes a world that now reflects its mistake, concludes something further, and acts again. By step six the original error is buried under five plausible-looking steps that all followed logically from it. This is why agent failures are so much harder to diagnose than model failures — the transcript looks reasonable the whole way down.

Agentic AI

Grammatically, “agentic” is an adjective meaning goal-directed and capable of acting. It is a perfectly good word. The problem is what happened when it was nominalised into a product category: because the adjective admits of degree — a system can be somewhat agentic — the noun has no floor. Anything can be described as agentic AI if you squint, and in 2026 almost everything is.

Used precisely, the term points at something real: multi-agent systems with a coordination layer, where specialised agents are dispatched by an orchestrator, share state, and hand work between each other. That is a genuinely distinct architecture with genuinely distinct failure modes. Used as most vendors use it, it means “our product does something after you press the button.”

The two questions that actually resolve it

The bottom-right quadrant is what people mean when they say agentic, and it is the only one of the four that requires a genuinely different operating discipline. Everything above and to the left of it can be governed by reviewing output. Only the bottom-right needs authority boundaries, approval gates, and an audit trail — because it is the only one that does things.

Note what the grid also tells you: a single product can occupy different quadrants depending on the request. That is not a flaw in the taxonomy. It is the actual situation, and it is why “is X agentic?” is usually the wrong question. Ask what a given request causes the system to do.

Why the official definitions conflict

This is worth naming plainly, because a reader who finds these terms slippery usually assumes the fault is theirs. It is not. Each vendor drew the boundary where their existing product sits just inside it. An RPA company defines agentic AI as smarter automation; a cloud platform defines it around reasoning and orchestration; a model provider defines it around tool use. Every definition is a positioning statement wearing a lab coat.

The practical consequence for a buyer: do not evaluate a vendor’s claim to be agentic. Evaluate the two questions directly. Ask what actions the system can take without a human, what happens on the third consecutive failure, and who is accountable when it acts wrongly. Those questions have answers that cannot be positioned.

Why the distinction matters operationally

The testing shift is the one teams underestimate. For a generative system, a set of prompts and expected outputs gets you most of the way. For an agent, the same final answer can be reached through a safe path or an alarming one, and only one of those is acceptable. You are no longer evaluating answers; you are evaluating the sequence of decisions that produced them.

The authority question is the one that stalls deployments. Every organisation has an implicit map of which decisions a machine may make alone, and it is almost never written down. Discovering it late — in production, after an agent has done something defensible but unwelcome — is the single most common way an otherwise working pilot gets shut down.

Which one do I actually have?

A note on the second row, because it is where the RPA comparison usually comes up. Robotic process automation follows a fixed script: when the screen changes, it breaks, loudly and immediately. An agent decides at each step, which means it can absorb variation the author never anticipated — and can also take actions the author never contemplated. RPA fails predictably. Agents fail creatively. The second is more useful and considerably harder to test.

If you take one thing from this page, make it this: the label a system carries is a marketing decision, and the controls it needs are a function of what it can actually do. Establish the second and you can stop arguing about the first.