What Comes Before Agentic AI?

Today I sat through a Teams presentation on agentic AI for data centre management, and heard the age-old assumption again: Agentic AI just happens. Assumptions work in theory. Not in practice.

I’ve learnt a lot over the last four years getting under the hood with AI. And these words are tattooed on my brain: “AI is not a black magic box.”

Agentic AI sounds good in a keynote. But break it down, get under the hood, and you quickly find that architecture and best practices matter. This blog is a shout-out to what comes before agentic AI.

Agents themselves are nothing new. My room thermostat is an agent that switches on my heating. Reinforcement learning took that idea further, building goal-seeking agents for decades; the label simply moved faster. What’s new is we now give these agents a large language model to reason with and real business systems to act on. That changes the question entirely. The question in the boardroom is usually “Which agent should we deploy?” That is the Magpie Effect talking. The question that actually matters is far less glamorous: are we ready to let software act on our behalf?

Agentic AI is not a layer you place on top of your existing technology. The quality and safety of what an agent does depends less on the model than on everything around it. So let’s look at what that “everything” is.

Start With the Process, Not the Agent

Every successful AI project I’ve seen starts with a process, not a model. Agentic AI is no different. Find the Golden Process, the single business process where better outcomes genuinely matter, and anchor the agent there. It needs a measurable outcome, clear boundaries and a named human who owns the result. Above all, it needs a safe failure mode for the day the agent is wrong, unavailable or manipulated.

The best early candidates are narrow and repeatable. Think structured inputs, well-defined policies and actions you can reverse. The worst candidate is an agent with broad access and a vague mandate to “help”. That is not a use case. It is an incident waiting for a date. Check out my previous blog: The Unglamorous guide to Agentic AI.

Then comes the uncomfortable part. An agent cannot improve a process the organisation itself cannot explain. Before anything is deployed, the current process needs writing down, warts and all: the exceptions, the approvals and the systems where the truth actually lives.

The same goes for the data underneath it. I’ve written before about data readiness and data pipelines. And why systems so often don’t work as designed. Agents inherit every one of those problems. If information is out of date, duplicated or indistinguishable from last year’s draft, the agent will not resolve the confusion. It will scale it, faster and with more confidence than any human could. Data readiness is not a slogan. For agents, it is the price of entry.

The Interface, the Plumbing and the Flow

I describe the agentic stack in one line: LLMs are the interface, MCP is the plumbing, agents are the flow. Each part needs its own foundations.

Start with the interface. An LLM is a reasoning and language capability, not an authority. It can interpret context and propose an action, but it is not inherently accurate, deterministic or entitled to make decisions outside its mandate. A sound model strategy decides which tasks genuinely need an LLM and which should stay as plain conventional software, and says what happens when the model is uncertain or simply wrong. My rule of thumb: use the smallest, most controlled model capability that meets the need.

Then there is the bill. I covered the tokens and economics in an earlier post on cloud spend, so I’ll keep this short. Agents loop, retry and call tools, and every step costs tokens. Pilots that look cheap can exhaust a year’s budget in months. Put budgets, limits and model routing in place before go-live, and measure cost per successful business outcome, not cost per token.

Now the plumbing. MCP, or any similar tool-connection protocol, gives models a consistent way to discover and call tools. That is genuinely useful. But MCP is an integration mechanism, not a security boundary. The moment an agent can write to an enterprise system, it becomes consequential. Every tool still needs its own authentication, authorisation, audit logging and a human owner. Start read-only wherever you can. Require human approval for anything irreversible. Build in idempotency and rollback so that a retried action does not become a duplicated payment.

Who Said the Agent Could Do That?

Agentic AI introduces a new security question. It is no longer just “Who is the user?” It is “What is this agent allowed to do, on whose authority, and under what conditions?”

An agent should never inherit broad access simply because a human user has it.

That single principle shapes everything else. Agents and tools need identities of their own, with short-lived credentials and delegated authority that is scoped to the task and time-limited. And every document the agent retrieves and every result a tool returns must be treated as untrusted input. Prompt injection is not a theoretical risk. It is simply a new way of handing someone else the steering wheel.

Governance has to be designed before autonomy arrives, not after the first incident. Someone must own the agent, the process, the data, the model and the decision that results. Use cases should be risk-tiered by impact and reversibility, and there must be a kill switch that somebody knows how to use. Accountability cannot be delegated to the agent or to its vendor. The organisation that deploys it owns the outcome.

Finally, production agents need an operational control plane, not just a prompt and an API key. That means version control, separate test and production environments, regression testing and monitoring. Good observability shows not just what the agent said, but why it acted, what information it used, which tools it called and what changed as a result. If you cannot reconstruct a decision after the fact, you cannot defend it.

Autonomy Is Earned, One Rung at a Time

Agentic AI changes roles and decisions, not just systems. The people working alongside an agent need to know what it can do, what it cannot do and when they must step in. Agents land best when they are introduced as a controlled teammate with a defined remit, not as an unreviewable replacement for expertise.

With that in mind, the sensible path is a ladder, not a leap. Pick one high-value, bounded workflow. Document its process, data and failure modes. Put identity, permissions, logging and approval controls in place before the agent touches anything. Then build a read-only copilot that recommends rather than acts, and test it hard against both representative and adversarial cases.

Only then add actions, narrowly scoped and with a human approving each one. Automate the reversible, low-risk actions first. Expand autonomy only when the evidence says you should. Each rung is earned by the one below it.

So, Are You Ready?

Here is the test I’d put to any organisation before it lets an agent loose. Do you know exactly what outcome the agent owns, and is there a named business owner accountable for it? Is the source data trustworthy and properly classified? Can you define and enforce the agent’s permissions? Can a human approve, override or stop what it does? Can you reconstruct every material decision and tool call? Can you test it before release and spot drift afterwards? And when the model, the data or an integration fails, can you recover safely?

If the answer to any of those is no, you are not ready for agentic AI. You are ready for the work that comes before it.

That is the point the keynotes skip. The first investment in agentic AI should usually be in foundations, not agents: process clarity, data quality, secure identity, governed integrations, evaluation and operational control. The LLM brings the capability. MCP brings the connectivity. Security and governance bring the trust. Only when those are in place should you decide how much autonomy to grant, and to which tasks. And my advice – before looking at agent security products – just apply best practices first, you know the stuff. What I’m saying is apply the same RBAC, networking firewalls, and policies that are foundational. No shortcuts just because you want instant automation. Slowly, slowly, catch the monkey.

Agentic AI doesn’t just happen. It’s engineered. And like everything else I’ve found under the hood, trust has to be built in, not bolted on. Architecture matters.