For most of the last decade, most enterprises have bought process intelligence as a project. Someone in operations would sponsor it, usually after a transformation initiative had underperformed. A team would stand up, run an engagement, produce a report, and disband. The report would identify automation candidates, surface a few inefficiencies, and inform a roadmap. The roadmap would be partially executed. The tooling would sit, quietly, until the next initiative needed it.
This is how most of the market has used process intelligence: useful, episodic, owned by a specific function, scoped to a specific question. The closest analogy in the technology stack is something like business intelligence in the late 1990s: valuable, but not yet load-bearing. And we all remember the cognitive overload from all those dashboards.
That was never the only way to run it. A smaller group of organizations kept the observation running, year after year, across teams and systems. They have been running their operations from a live picture of how work gets done while everyone else worked from snapshots. The difference was never the idea. It was whether anyone treated the observation as something to keep rather than something to finish.
What’s changing now is that the always-on model is about to become a requirement rather than an advantage. Of course, the technology itself has evolved. Still, the most transformative shift is that the raw material (the work itself) is becoming the substrate on which a new generation of autonomous systems operates. And the moment work becomes the foundation for AI agents, the observation of work can’t be a project anymore. It has to be infrastructure.
I want to spell out what that means, because the implications go beyond “we should buy a process intelligence tool.” They are about how the operations function reorganizes itself, what the technology stack looks like five years from now, and which problems become solvable that weren’t.
What “infrastructure” actually means in a tech stack
Infrastructure, in the engineering sense, has a specific definition. It is the layer that other layers depend on. It is always-on, not project-driven. It has its own team, its own service-level agreements (SLAs), its own budget line. When it fails, things downstream break in ways that are immediately visible. When it works, nobody notices it, which is the highest compliment infrastructure receives.
By that definition, a short list of things that count as infrastructure in a modern enterprise:
- Identity (Okta, Entra, Auth0). Always on. Owned by security. When it breaks, everything breaks.
- Observability (Datadog, Splunk, New Relic). Always on. Owned by platform engineering. When it breaks, you find out about the next outage twenty minutes late.
- Data catalog and lineage (Collibra, Atlan, Alation). Always on (when it’s working). Owned by data engineering. When it’s broken, governance and compliance suffer in slow motion.
- Service mesh and API gateway. Always on. Owned by platform engineering. When it breaks, services can’t find each other.
For most enterprises, process intelligence hasn’t looked like this. It has looked like a tool: bought by operations, deployed for an engagement, owned by whoever ran the last project. The team that operates it is project-shaped. The funding is project-funded. The expectations are project-bounded.
My argument is that this shape no longer fits the function. The function has outgrown the project model, and the organizations that already run it continuously show what comes next.
Three forces pulling process intelligence (and context intelligence) toward infrastructure
Three things are happening at the same time, and together they change what process intelligence has to be. (By context intelligence, I mean the wider view: not just the sequence of steps, but the systems, data, policies, and judgment calls surrounding each one.)
One: agents need a substrate
The previous essay made this case at length, so I’ll be brief here. Agents that perform real enterprise work (not single-task copilots, but systems that execute multi-step processes end-to-end) depend on a faithful representation of how that work is currently performed: the variants, the exceptions, the applied policy, the inter-system handoffs, the workarounds. Without that representation, the agent is operating on intent, not behavior, and the gap between the two is where pilots fail.
The representation has to be current. A snapshot from last quarter doesn’t help when the team changed a workaround three weeks ago. The representation has to be continuous, which means observation has to be continuous, which means the process intelligence layer has to be always on.
This is the first force. The moment you commit to agentic execution at scale, you have also committed to running the observation layer as infrastructure. The agents depend on it the way services depend on identity. You don’t turn it off.
Two: governance needs evidence, not assertion
The second force is regulatory and is easy to underestimate. As agents move into regulated work (credit decisions, claims adjudication, healthcare prior authorization, anti-money-laundering review), the question of how the system actually behaved becomes one that someone external will ask.
The answer cannot be a process map. A process map describes intent. The regulator wants behavior. They want to see, for a representative sample of cases, what the system did, in what order, on what data, against which policy, with what override authority, and producing what outcome. They want it for the agent, and increasingly for the humans the agent works alongside, because the audit trail has to be consistent across both.
The only way to produce this evidence at scale is to have been recording it the whole time. You cannot reconstruct it after the fact. The observation layer, in this frame, is the system of evidence: the layer that lets the enterprise answer, with specifics, what it actually did. That is an infrastructure responsibility, not a project deliverable.
Three: continuous transformation replaces episodic transformation
The third force surprised me when I first noticed it. The cadence of enterprise change is shortening.
A decade ago, an operations transformation was a multi-year program. You’d spend six months in discovery, twelve months in design and pilot, and another twelve to twenty-four in rollout. The process intelligence work fit into the discovery phase. It produced a snapshot, the snapshot informed the design, and the snapshot was discarded once the new state was in place.
That model assumed the new state would be stable for a while. It isn’t anymore. The combination of cloud-native systems, frequent user interface (UI) updates, regulatory drift, and the introduction of AI capabilities means that the “new state” of any operations process is itself a moving target. You don’t deploy an automation and walk away. You deploy it, watch it, retune it, replace pieces of it, and integrate new capabilities on a cadence closer to monthly than annual.
Continuous transformation requires continuous observation. The snapshot model is dead because the snapshot is stale by the time the rollout completes. What replaces it is an always-on view of how the work is being performed today, against which any change (agent deployment, process redesign, system migration) can be measured. The observation layer becomes the baseline you keep, not the artifact you produce once.
What infrastructure-grade process intelligence and work context fabric has to look like
If more enterprises are going to run process intelligence as infrastructure, the technology they run has to look different from the project tooling most of them bought. Call the result a work context fabric: a continuous, shared record of how work actually gets done, woven across every team and system. A few things follow.
It has to be continuous. Episode-based observation (install the tool, capture six weeks of data, run the analysis, decommission) produces a snapshot. Infrastructure produces a feed. The difference is not technical. It is operational. You staff differently, you fund differently, you set different expectations.
It has to be wide. A process intelligence platform that sees only one process, one team, or one system is the equivalent of an observability platform that sees only one service. The whole point is the joins: the moments where work crosses from one team to another, from one system to another, from a human to an automation. Those joins are where most operational pain lives, and you can’t see them with a narrow tool.
It has to be machine-readable. The first generation of process intelligence tools produced dashboards. The dashboards were aimed at humans: process owners, transformation leads, executives. The next generation has to produce structured representations that other systems can consume. The agents need it. The governance tools need it. The simulation tools need it. The audit tools need it. A dashboard is a destination; infrastructure is a source.
It has to be privacy-preserving by construction. Observing work, by definition, observes the people doing the work. That observation can be deployed responsibly (with consent, anonymization, and clear policies about what is captured and how it’s used) or in ways that erode trust. Infrastructure-grade observation has to make the responsible path the default. This is not optional, and it’s not a feature checkbox. It is the precondition for the layer to operate at all.
It has to be vendor-agnostic about the systems it observes. A process intelligence layer that depends on integrating with each underlying application will be a project forever. There are too many applications, they change too often, and the integration work compounds. That, more than anything, is why the project model stuck: tools that depend on extracting logs from each application have to be re-scoped, re-integrated, and re-run every time. The architectures that run as infrastructure today observe at the interaction layer (the screen, the keystroke, the system boundary) rather than the application layer. The pixel is the universal interface; the API is the special case.
What this changes about the operations function
If process intelligence becomes infrastructure, the operations function reorganizes around it.
The center-of-excellence (CoE) model, the dedicated team that owns automation, runs robotic process automation (RPA), and is funded as a project organization, is going to look strange in this new shape. The CoE was built for a world in which automation was a discrete capability, deployed to a discrete process, by a specialized team. That world is going away. Automation is becoming a property of how work is performed everywhere, not a capability deployed somewhere. The team structure has to follow.
What replaces it, in the organizations getting this right, looks more like a platform team. The platform owns the process record. It exposes the record to the rest of the enterprise: to operations leaders who use it to make decisions, to engineers who use it to design and deploy agents, to the compliance team that uses it for audit, and to the data team that links it to outcomes. The platform team is not, itself, in the business of running engagements. It is in the business of running infrastructure.
This is a real change. It changes who you hire (more platform engineers, fewer consultants), how you fund (a permanent capex/opex line, not a project budget), and how you measure (uptime and coverage, not deliverables and reports). The operations leaders who make this transition well will, five years from now, run a function that looks more like a modern engineering org than a 2015-era transformation program. The ones who don’t will keep running projects until the agents that depend on the observation layer start to underperform, at which point the question of who owns the substrate will become urgent and contentious.
The potential (and valid) objection
The honest pushback to this argument runs roughly: we’ve been here before. Every few years, some category in the operations or data stack gets reframed as infrastructure. Data warehouses were going to become infrastructure. Master data management (MDM) was going to become infrastructure. Data catalogs were going to become infrastructure. In each case, some of the predictions came true, many of them didn’t, and the categories ended up where they always do: useful, partially adopted, and selectively deployed.
This is a fair objection, and I want to engage with it directly. I think process intelligence is on a different trajectory, not because the technology is better (though it is), but because the dependency is different. Data catalogs are useful when they exist; the rest of the stack functions without them. Agents do not function without a substrate of observed work. Once an enterprise commits to agentic execution, that dependency is hard to remove. The observation layer is not a nice-to-have that improves the data catalog story. It is the thing without which the agents fail.
Infrastructure is defined by what breaks when it goes down. Identity is infrastructure because nothing logs in without it. Observability is infrastructure because outages become invisible without it. The observation layer is becoming infrastructure because, in an enterprise that runs work through agents, losing it means the agents start making decisions on stale or incorrect assumptions about the work, and nobody finds out until something downstream breaks.
That’s the test. By it, process intelligence has crossed the threshold.
What to do about it now
For operations leaders sitting with this argument, the practical version is this: you have a window, probably eighteen to thirty-six months, in which to make the transition deliberately. After that, the agents you’ve deployed and the regulators asking how they behave will make the choice for you.
The transition has three parts. First, separate the observation layer from the engagements that use it: make it a permanent capability, not a project artifact. Second, hire and structure for it the way you would for any infrastructure team: a small group of platform engineers, a clear product owner, and an internal-customer model for the rest of the operations function. Third, raise expectations for what the layer produces: not just dashboards for humans, but structured outputs that agents, auditors, and design tools can consume.
None of this is glamorous. Infrastructure work rarely is. The teams that build it well, though, end up being the teams that everything else in the agentic enterprise depends on — and that’s a position worth occupying before someone else does.