Agentic AI describes a capability, not a product

Ask ten people in operations what agentic AI means and you will get ten answers, most of them hedged. It is a term that has arrived quickly, is being used confidently by people selling things, and is rarely defined by anyone in a way that helps you decide what to do about it.

It is worth saying up front that it is not a marketing invention. Something genuinely did change in how this software works, and the word is a reasonable attempt to describe it.

But it describes how the software behaves. It does not describe anything you can actually buy.

What the word is pointing at

For the last few years, the thing most people had in mind when they said AI was a system that answers. You give it something, it gives you something back. A question and a response. A document and a summary. Useful, but bounded: it does one thing, once, and then waits for you.

Agentic describes software that does more than respond. It can take an objective, work out the steps needed to reach it, use other systems along the way, and carry on through those steps without being prompted at each one. It can check its own output, notice when something does not look right, and change approach rather than producing a confidently wrong answer and stopping.

That is the whole of it. Not intelligence in any meaningful sense. Not autonomy in the way the word tends to be heard. Just the difference between software that answers a question and software that completes a task.

Why that difference matters more than it sounds

Automation has existed in operational businesses for years, and most of it has been disappointing for the same reason every time.

Earlier tools worked by following a fixed path. If this arrives, do that. They were reliable when the inputs were reliable, which in a controlled test they always are. In an operational business they are not. An invoice arrives as a photograph taken on a site office phone. A purchase order comes through as a PDF one month and pasted into an email body the next. A delivery note is filled in by hand and scanned at an angle. A supplier changes their document layout without telling anyone.

Every one of those variations breaks a fixed path, and when it breaks, a person steps in to sort it out. Which means the process is still manual, just intermittently, and now with the added work of noticing that it failed.

Software that can plan and adapt handles that variation the way a person handles it. It reads what actually arrived rather than what was supposed to arrive, works out what to do with it, and carries on. That is not a marginal improvement on the previous generation of tools. It is the difference between automation that survives contact with a real business and automation that does not.

What the word does not tell you

Here is where it gets expensive.

Agentic is a description of capability. It says what the underlying technology is able to do. It says nothing about whether anyone has built the thing, connected it to your systems, tested it against your data, or taken responsibility for it when it breaks at four o'clock on a Friday.

We have written before about how everything now gets sold under the same word — a model, a toolkit for building things, and a finished worker are three different purchases with three different bills attached. Agentic has landed on top of that confusion rather than clearing it up. A model can be agentic. A toolkit can help you build something agentic. A finished product can be agentic. All three are accurate uses of the term, and knowing that a vendor's software is agentic tells you which of the three you are looking at exactly as well as knowing a vehicle has four-wheel drive tells you whether it is a tractor or a hatchback.

The question that gets you somewhere is not whether it is agentic. It is who has already done the building.

What it looks like when it is actually running

Take processing an invoice, which is about as unglamorous as operational work gets.

An invoice arrives. It might be a clean PDF from a large supplier or a photograph of a handwritten sheet from a subcontractor. It gets read, and the relevant details come off it: supplier, amount, dates, line items, VAT treatment. Those details get checked against the purchase order that should match them. Where they match, the record is prepared and ready to process. Where they do not — a quantity is off, a rate does not match what was agreed, the PO cannot be found — that is flagged and put in front of the finance lead with the discrepancy already identified, rather than landing in an inbox for someone to investigate from scratch.

That is a plan, several tools, a series of steps, and a judgement about which cases need a person. Agentic, technically. But nobody in the finance team is thinking about that. They are thinking that the invoices are done and the exceptions are on their desk with the problem already named.

The same shape applies across the operational work these businesses carry: chasing the payment afterwards, or moving a quote through to a signed order. Different process, same structure. Read what arrived, do the mechanical steps, surface the ones that need a person.

The part that is not agentic, and should not be

The word makes some people uneasy, and the instinct behind that is sound.

Software that plans its own steps is only useful if the boundaries around it are clear. Which is why the interesting question in any of this is not how much the software can do on its own, but where the decisions sit. The finance lead still approves the payment run. The estimator still decides the margin. The site manager still calls whether a deviation needs escalating.

This is the same argument as separating the mechanical steps from the ones that need judgement, and agentic capability does not change it. It just makes the mechanical half considerably more reliable. Nothing about the technology being more capable means it should be handed decisions it was never the right thing to hand them to.

Our digital workers are built on that basis, and the data they handle stays inside the business rather than being passed to a model provider for training. What the worker does is bounded, visible, and reversible. That is a design decision, not a limitation of the technology.

So what should you actually ask

If a supplier tells you their product is agentic, they have told you something true and almost entirely unhelpful. It is a fact about the engineering, offered in place of a fact about the outcome.

The useful questions are duller and shorter. Does it handle the specific process that is currently eating your team's week. Does it work with the systems you already have, including the spreadsheet nobody will admit is load-bearing. Who built it, who maintains it, and what does it cost when it runs a thousand times a month rather than ten.

Agentic AI is real, and it is the reason work that could not sensibly be automated three years ago can be automated now. But it describes the engine. What you are buying is the journey, and no amount of detail about the former tells you anything reliable about the latter.