Where Agentic AI Is Ready and Where It Is Not

We have four agents in production and stopped seven proposals. That ratio is not caution for its own sake. Agentic AI has a fairly clear boundary. It reflects a fairly clear line between the work this technology handles well and the work it does not, and the line is easier to describe than the marketing suggests.

An assistant suggests and a person acts. Agentic AI takes a goal, decides on steps, acts, and reports afterwards.

That difference is not technical sophistication. It is a delegation decision, and it deserves the scrutiny you would give a new employee with system access.

Most of what gets sold as agentic AI is the first thing with a longer prompt. Asking which one you are being shown is the fastest way to shorten a vendor meeting. Asking which one a proposal actually describes clears up a surprising number of conversations.

Bounded, reversible, well defined tasks: Clearing a full disk of known temporary files. Restarting a stuck consumer. Reclassifying a case that was routed wrongly.

Each has a known correct outcome, an obvious failure mode, and an undo.

Retrieval and assembly: Gathering information from several systems into one briefing. The agent reads, it does not decide, and every claim points at its source.

First pass triage: Incoming work sorted, tagged, and routed. A person confirms anything unusual and the volume of ordinary cases drops.

None of those is impressive in a demonstration. All four of our production agents fall into these categories.

Anything producing a number somebody acts on without checking. The output looks authoritative and the error is invisible.

Anything with an irreversible effect. A refund issued, a message sent, a record deleted. We allow none of these autonomously, and that is a policy rather than a technical limit.

Anything requiring judgement about an individual customer relationship. We tried and the results were confident and wrong often enough that the team stopped trusting the whole screen.

And anything where nobody can reconstruct what happened. If the log does not let us replay a decision, it does not go live.

Every agent we run began without the ability to change anything.

Read only against production data, output visible to the team alone. That first fortnight usually kills one or two assumptions the design rested on.

Then one narrow write action with an approval step. Then, once the log gives us a reason, the approval comes off for the lowest risk subset.

Each expansion needs evidence from the previous stage. Agentic AI deployed straight into autonomy skips the phase that tells you whether it works.

Six things, none exotic, all enforced in code rather than described in a prompt.

Request scoped identity, so the agent acts with the permissions of whoever asked. Never a shared service account.

An allow list of operations. Everything not on it is refused rather than attempted.

Approval thresholds agreed by the business owner, not by engineering.

Hard limits on spend, rate, and volume that stop rather than warn.

An immutable log of inputs, decisions, tool calls and effects.

And a rollback path for anything the agent can change.

Our compliance function approved production deployment because those are engineering facts rather than assurances.

One question, asked of every proposal.

If this behaves badly for an hour before anyone notices, what is the worst outcome, and can we undo it?

Seven proposals could not answer it satisfactorily. Two of those may become viable as the controls improve, and reviewing that list quarterly has been more productive than forcing them now.

Vendors now ship agent capability inside products you already own, which changes the buying question.

Our CRM estate runs several salesforce cloud products. The agent capability there sits closer to the data than anything we would build. That is a genuine advantage for CRM specific tasks.

The trade is the usual one. A platform gives you speed and less control over the failure behaviour. A raw integration gives you control and more to build.

We use both. The deciding factor has been whether the data already lives in that vendor's system, not which approach is more capable.

Our customer app was an obvious candidate and we have been deliberate about it.

Agents acting on a phone raise the stakes, because the user cannot easily see what happened and the recovery path is a store release rather than a server deploy.

The iOS app development company we work with raised this before we did, which was a good sign. Any iOS app development company that has shipped agent features will know the recovery path is a store release. Our app surfaces agent output and never acts autonomously on the device. Anything with an effect happens server side, where we can log it and reverse it.

Five things, reported monthly, the same for every agent.

Actions taken, split by type. Actions requiring approval, and how many approvals were refused. Actions reversed after the fact. Replay coverage, meaning the share we could fully reconstruct if challenged. And refusal rate, which should be non zero.

The third and fourth are the ones I would keep if I had to drop the rest. A rising reversal rate means the boundary is wrong. Incomplete replay coverage means we cannot answer a question we will eventually be asked.

Separate the two things. Assistants that suggest are ordinary software with a model inside them and you should be shipping those already.

Agents that act are a delegation decision. Write down what they may change, what needs a person, what gets logged, and how you undo an hour of bad decisions. Do that before evaluating any product, so the assessment stays consistent.

Agentic AI is genuinely useful in narrow, reversible, well bounded work. Our four are all of that description, they are collectively unglamorous, and they are still running eighteen months later, which is more than I can say for most of what we were pitched.