I’ve spent the past year sitting in on AI deployment conversations with banks, insurers, systems integrators, and digital-native challengers. Pretty much every flavor of enterprise you can name, and I’ve had some version of this conversation with all of them. It tends to go the same way. Someone leading AI governance walks us through what their agents are already doing in production. People nod. And then, somewhere in the middle of it, you can watch the room quietly figure out that nobody in it can actually answer a fairly basic question: if this thing gets something wrong tomorrow, who’s accountable for that, and which rule did it break?
That question, not model capability, is what’s going to decide how many of the current wave of AI agent programs actually survive. Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, and the reasons it gives aren’t “the technology didn’t work.” They’re escalating costs, unclear business value, and inadequate risk controls. That third one is the reason nobody wants to put on the kickoff slide.
We’ve started calling the missing piece an Agentic Process Foundation. It is not the thing the industry is currently selling as AI governance, because most of that pitch is still about documentation, and documentation was never really the problem.
Everyone’s Giving the Same Advice, and It’s Not Quite Right
Sit in on enough of these conversations and you’ll hear the same prescription over and over: map your processes, document your workflows, feed the AI more context. None of that is wrong exactly. It’s just not enough, and the gap doesn’t show up until it’s already a problem.
A process map tells you what happens in a workflow. It doesn’t tell you what could go wrong in it, whose job it is to stop that from happening, or which regulation the control in question is actually there to satisfy. I’ve seen good engineering teams build beautifully detailed process diagrams (the kind you’d be proud to show a board) and then hand an agent that exact process with zero idea which step needed a second signature, or which dollar amount turned a routine transaction into something you have to report. The diagram was accurate. It just wasn’t built to answer the question that mattered.
So the gap isn’t visibility, at least not the kind most people mean when they say it. It’s risk and compliance context, specifically. And almost nobody I talk to is building for that on purpose. Most companies stumble into it, if they get there at all, after something’s already gone sideways.
I’ve heard this pitched under a couple of different labels, and both are worth naming, because neither one gets you there on its own.
Process intelligence, the mining and analytics side of this market, tells you what has actually happened in a workflow: where the bottlenecks are, where exceptions cluster, how long things really take once you strip away what the documentation claims. That’s definitely useful, and I’m not knocking it. But it’s a description of behavior, not an assignment of accountability. It tells you the process is slow at step four. It doesn’t tell you who’s supposed to own step four, or what breaks if that step gets skipped.
And process context, the newer pitch, the one I’ve used myself, usually just means the agent gets more information about the process before it acts. That sounds like progress until you notice the information still doesn’t say who’s accountable for the third approval step, or which control it’s tied to, or what happens if it’s wrong.
Both get you a smarter picture of the process. Neither one, by itself, gets you a governed answer to who’s responsible and what breaks. That’s the actual gap, and it’s narrower and less glamorous than either label suggests.
Whatever you call it, it has to operate at the same depth the agent does. Most business governance tools only see the top of the process hierarchy, not the step buried inside it where the agent acts.
The Four Layers of an Agentic Process Foundation
Watching enough of these deployments, a pattern starts to show up. The companies that get this right tend to build four things, in this order. These are the four layers of an Agentic Process Foundation:
Visibility. Risk and control visibility. Where the risk in a process lives, and who is accountable for it.
Prioritization. Risk-adjusted prioritization. Where to point an agent in the first place, simulated under real risk and control constraints before anything reaches production.
Context. Runtime risk context. The specific risks, controls, and accountable owners tied to the exact step an agent is about to take, delivered at the moment it takes it.
Optimization. Conformance against the approved baseline, so drift gets caught as drift instead of as an audit finding.
The order matters, because each layer depends on the one before it. You can’t risk-adjust a priority list without a risk register to adjust against. You can’t hand an agent runtime context you’ve never written down. And you can’t test conformance without an approved baseline to conform to. Skipping one quietly undermines whichever layer comes after it. These are four distinct, sequential capabilities, not four ways of describing the same thing.
Visibility is the first one, and it means having somewhere to actually look up where the risk lives and who’s responsible for it. Not a diagram, but something closer to a risk register with names attached. Most companies already have this information. It’s just scattered across spreadsheets, audit binders, and whatever’s in the head of the one person who’s been there fifteen years and remembers why a particular control exists. None of that is something an agent can query before it acts, which means, functionally, none of it protects anything. It’s worth saying plainly how far behind this most companies are: McKinsey’s November 2025 State of AI survey, covering nearly 2,000 organizations, found only 23% scaling agents in even one business function, with another 39% still experimenting. That’s a lot of companies deploying agents into processes whose risk profile has never been written down anywhere an agent could find it.
Prioritization comes second: being disciplined about where you point an agent in the first place. This shouldn’t be a popularity contest for whichever process looks easiest to automate. It should involve actually simulating how the agent would behave inside that process, under its real risk and control constraints, before any of it touches production. I keep seeing teams skip this and go straight for whatever’s most visible rather than whatever actually matters, and then the thing they didn’t simulate for (an exception path nobody flagged, a regulatory threshold buried three steps down) shows up after go-live, at the worst possible time to discover it.
Context is third, and it’s the one that actually keeps an agent out of trouble once it’s live: giving it the specific risks, controls, and accountable owners tied to the exact step it’s about to take, right when it’s taking it, not a bigger document to interpret on its own. The actual answer, already worked out. This is also where the concern actually sits for the people running these programs. KPMG’s spring 2026 Global AI Pulse survey, which covered more than 2,100 senior leaders across 20 countries, found that nearly three in four are somewhat or greatly concerned about data security, privacy, and risk. That’s the single highest-ranked concern in the whole survey, ahead of cost, ahead of talent, ahead of almost everything else people worry about out loud. I remember a conversation with a digital-native bank’s internal AI team that had gone and built this themselves, manually, because no one had offered them a version of it. When I asked why they hadn’t just waited for a vendor, the answer stuck with me: nobody else seemed to be solving the actual problem, which was never “give the agent more information.” It was “give it the right information, with a name attached to it.”
Optimization is fourth: checking, after the fact, whether what actually happened lines up with what was supposed to happen. Conformance, in other words. Comparing execution against the approved risk baseline and catching drift before it turns into a finding instead of after. I had a conversation not long ago with someone at a much older institution, the kind with a hundred-page-plus internal standards manual, who described spending real hours every month manually checking new process work against that manual by hand. Then, almost hopefully, asked to be first in line if anyone ever automated that. That request tells you something. When your most experienced compliance people are volunteering to beta test something that doesn’t exist yet, that’s not a nice-to-have sitting on a roadmap somewhere. That’s a backlog nobody’s gotten to.
Even the Smartest Teams Fall Into This
Here’s the part that surprised me a little, honestly. The mistake I run into most isn’t coming from companies behind the curve. It’s coming from the most advanced teams in the room, the ones juggling five or six AI initiatives at once, fully convinced they’ve already solved governance because they solved documentation.
You’ll hear some version of this: why would I need any of this when I can just ask a general-purpose model to draw me a process diagram from a plain description? Fair point, and also beside the point. Ask that same model who owns the third approval step, or which version of a control was actually in force on the date a decision got made, and it has nothing. A picture of a process isn’t the same thing as a governed record of who’s responsible for it. Nobody notices the difference for months. Then a regulator or an internal auditor asks the question directly, and suddenly it’s the only thing that matters in the room.
What’s a little ironic is that the teams most likely to assume this is already handled are usually the ones with the most exposure if it isn’t. Feeling confident about your AI stack and being able to account for what it does are two different things, and I don’t think enough people running these programs have separated them yet.
Where This Is Headed
If I had to bet, I’d say the AI governance conversation shifts pretty significantly over the next year, away from “do we have a strategy” and toward “who signs off when the agent gets it wrong.” I think it moves from a slide buried in a compliance deck to something audit committees ask about as a matter of course, roughly the way cybersecurity did about a decade ago. Boards didn’t start asking about breach response because CISOs got better at slides. They started asking because a handful of very public failures made not asking look reckless. I think AI accountability is on the same path, just moving faster, because the deployment cycle is faster.
Companies building these four layers now, before a board member or a regulator makes them, are going to spend next year shipping. The ones that wait are going to spend it explaining, after something’s already happened, why a model that worked exactly as designed made a decision nobody can actually defend.
I still think about that governance lead, mid-sentence, watching her own team realize nobody could say who’d be accountable if their agent got the next call wrong. That’s going to happen in a lot more rooms this year. The companies that already have an answer won’t notice it happening. Everyone else is going to find out the hard way that the AI failures coming next aren’t going to be model failures. They’re going to be accountability failures wearing a model’s face.
Daniel Hughes leads sales for North America and Japan at iGrafx, where he works with banks, insurers, and technology firms on AI agent risk and process governance.
Frequently Asked Questions
An Agentic Process Foundation is the risk and compliance layer an AI agent needs before it can be trusted to act inside a governed process. It has four sequential layers: Visibility, Prioritization, Context, and Optimization. Together they establish where risk lives and who owns it, where to point an agent in the first place, what the agent needs to know at the moment it acts, and whether what happened matched what was approved.
Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. The third reason is the one that stalls programs quietly. A team that cannot say who is accountable if an agent gets something wrong will not be permitted to point that agent at a process that matters, so the program never leaves pilot.
Accountability has to be assigned before the agent acts, not worked out afterward. In most organizations it has not been. The risk owner for a given process step exists somewhere in a spreadsheet, an audit binder, or one person’s memory, none of which an agent can query before it acts. Naming the accountable owner for each step, and making that record available at runtime, is what turns an agent’s decision into one the organization can defend to a regulator or an internal auditor.
Process intelligence tells you what has actually happened in a workflow: where bottlenecks form, where exceptions cluster, and how long steps really take once you strip away what the documentation claims. That is a description of behavior. An Agentic Process Foundation adds the assignment of accountability, meaning which risk applies to a given step, which control governs it, and who owns the outcome. Process intelligence tells you a step is slow. An APF tells you who is responsible if it gets skipped.