Blog

What is agentic AI?

10 min read

The short answer

Agentic describes a property, not a product. A system is agentic to the degree that it decides its own next step instead of following a sequence you fixed in advance.

It is a spectrum, not a category. A workflow where the model picks one of three branches is slightly agentic. A system that plans, calls tools, evaluates results and revises its approach is strongly agentic. Both get sold with the same word.

Which is why the useful question is never whether something is agentic. It is how much autonomy it has, and whether that amount is justified. We covered the artifact itself in what an AI agent is; this is about the property.

Agentic versus a single call

A single model call is a function: input, output, done. It is predictable, cheap, easy to test and easy to reason about when it goes wrong.

An agentic system introduces a loop. It acts, observes what happened, and decides again. That loop is what lets it handle tasks whose steps cannot be known in advance, and it is also what makes it harder to predict, more expensive, and slower.

Everything difficult about agentic systems comes from the loop. Everything valuable does too.

The loop is the definition

Strip the vocabulary and the pattern is always the same. The system receives a goal. It chooses an action. Something happens. It reads the result. It decides whether it is done, and if not, chooses again.

What varies is how much freedom it has at the choosing step, and how many times it is allowed to go round. Those two dials, not the framework you use, determine the behaviour and the risk profile.

Turn them down and you have a reliable workflow with a little judgment in it. Turn them up and you have something that can solve problems you did not anticipate, and also fail in ways you did not anticipate.

Where it genuinely pays off

When the path cannot be enumerated in advance. Diagnosing an issue where the next check depends on what the last one returned. Research where the follow up question emerges from the answer. Reconciliation where the discrepancy determines which source to inspect next.

The shared trait is that a fixed flowchart would have to be enormous to cover the real cases, and would still miss most of them. If you can draw the flowchart on one page, you do not need autonomy, you need the flowchart.

Where it is the wrong shape

When the process is known and stable. Wrapping a deterministic sequence in an agent adds cost, latency and nondeterminism, and buys nothing. This is the most common overreach and it usually happens because agentic sounded more impressive in the proposal.

When correctness must be exact every time. Reconciliation that has to balance, calculations, anything where being creative is a defect rather than a feature.

And when latency is part of the product. A loop that runs eleven steps to answer something a user is waiting on will lose to a single call that is slightly less thorough.

Errors compound

This is the property that surprises teams, and the arithmetic is unforgiving. A step that is right ninety five percent of the time is excellent in isolation. Chain ten of them and you are at roughly sixty percent for the whole task.

Worse, failures are not independent. A wrong conclusion early becomes the input to everything after it, so the system proceeds confidently in the wrong direction and produces a coherent, well argued, entirely incorrect result.

The mitigations are checkpoints that verify intermediate state rather than only the final answer, hard limits on iterations, and designing the task so a wrong step is detectable before it is built upon.

Cost and latency multiply

Each iteration is a model call with its own input, and the input grows as the history accumulates. A task that takes twelve steps does not cost twelve times a single call, it costs more, because later steps carry the whole conversation with them.

This is where the difference between an impressive demo and an affordable product usually appears. Ten demo requests cost nothing. Ten thousand production requests, at twelve steps each with growing context, is a real line item. We covered the arithmetic in what it costs.

Cap iterations, budget tokens per task, and log both. A system that can loop without a ceiling will eventually find a case where it loops for a long time.

How to constrain it

The autonomy has to be bounded by engineering rather than by instruction. Limit the number of iterations. Scope the tools narrowly, so the set of possible actions is small and every one is safe for the role. Make writes idempotent, because a retried action should not create a duplicate.

Require confirmation for anything irreversible, and make the system explain its intended action before it executes rather than after.

This is the same permission and action layering described in guardrails, and it matters more here because an agentic system takes many more actions per request than a single call does.

How to tell if you need it

Three questions. Can you write down the steps in advance? If yes, write them down instead. Does the next step genuinely depend on what the previous one returned? If not, you have a pipeline, not an agent. And can you tell, from the outside, whether the system did the right thing?

That last one is the filter most proposals fail. If nobody can evaluate the intermediate steps, you cannot debug it, cannot improve it, and cannot defend it when it goes wrong. Autonomy without observability is not a capability, it is an exposure, which is why we start from the decision and the measurement when we build production AI, end to end.

If a vendor is selling you agentic and you cannot tell what it buys you, thirty minutes will settle it. You leave with a price range and a clear next step.

Book a call Or send the details in writing
Back to blog