Coming Full Circle: BPR Returns in the Agentic AI Era

Coming full circle

I have seen this movie before. Almost.

A good part of my early career was spent doing business process re-engineering. We would sit with a business, understand how work really happened, map the as-is process in painful detail, challenge every hand-off and exception, and then design the to-be. The technology came after that thinking: it was an enabler of the redesigned operating model, not the place where the process itself necessarily lived.

Over the following two decades, the centre of gravity shifted. ERP and then SaaS applications increasingly arrived with their own opinion about how customer management, finance, procurement, HR, service management and dozens of other processes should work. We still redesigned processes, of course, but transformation became much more about configuring workflows inside the application, integrating systems around them and asking the organisation to adapt to the platform.

What I am beginning to see with AI is a reversal of that relationship. The systems of record remain important, but the orchestration of work no longer has to sit inside any single application. An agent can reason across systems, understand context, invoke tools, apply policy, deal with exceptions and bring a person into the loop when judgement is required. In other words, the workflow can start to move back above the applications that hold the underlying records.

WHAT HAS CHANGED

The important difference this time is that we may be able to build the future process, let people experience it, and prove it before we integrate it.

Why now

The adoption problem has moved

Enterprise AI has moved rapidly from access to experimentation. The harder problem now is redesigning the operating model around it.

The latest 2026 data makes this gap difficult to ignore. Stanford's AI Index reports that 88% of surveyed organisations use AI in at least one business function and 70% use generative AI in at least one business function. Deloitte, meanwhile, found that only 25% of organisations had moved 40% or more of their AI pilots into production, while just 30% were redesigning key processes around AI and 37% were still applying AI at the surface with little or no change to the underlying process.

The economics tell a similar story. PwC's 2026 CEO survey found that 56% of CEOs had seen neither significant revenue gains nor cost reductions from AI, and only 12% reported both. McKinsey's July 2026 research found another version of the same readiness gap: 70% of respondents felt personally prepared to use AI, but only 27% of leaders believed their organisations were ready to make the shifts required for an agentic future.

My reading of those numbers is not that AI is failing. It is that access to intelligence is becoming less of a constraint than the organisation around it. McKinsey's earlier State of AI work is especially relevant here: among 25 organisational practices tested, workflow redesign had the strongest relationship with reported EBIT impact from generative AI, yet only 21% of organisations using gen AI said they had fundamentally redesigned at least some workflows. That is a strong signal that the next phase of enterprise AI has to move closer to the process itself.

The new playbook

Build the to-be process before you integrate it

This starts with process identification, but I mean something broader than drawing a process map. Process mining can reconstruct actual paths from system event data, while task mining can show what people really do on the desktop. Both are useful, but the real process also lives in procedures, application logic, policies, tickets, spreadsheets, approval habits and the judgement of experienced employees who know which parts of the documented process are routinely bypassed.

The first objective is therefore to build a representation of the work that the business recognises: the states a case can enter, the decisions that move it forward, the data and systems touched, the exceptions, the approvals and the measures that tell us whether the process is actually working. Once that representation exists, coding agents change the economics because we do not have to connect the design to production systems immediately. We can build an executable digital twin of one bounded workflow and make the proposed to-be process behave realistically enough to challenge.

THE SHIFT

We are prototyping the operating model, not just the AI.

A concrete example

What this could look like in quote-to-order

Take enterprise quote-to-order. The twin might contain a synthetic customer service, a mock product catalogue, a simulated credit check, business rules, agent roles, human approval points and a library of historical cases. A shadow MCP tool can expose the same interface the real service will eventually expose, while deterministic validators check pricing limits, approval thresholds or compliance conditions without asking a language model to improvise a rule that should be exact.

IN THE TWIN, BEFORE PRODUCTION

• Synthetic customer, product and order data
• Shadow MCP interfaces that mirror production contracts
• Historical cases replayed at scale
• Model-routing and autonomy strategies compared
• Risk, exceptions and human approvals tested
• Cost per successful workflow measured

WHEN THE BUSINESS CASE HOLDS

• Shadow MCP is replaced by governed live services
• Synthetic data is replaced by enterprise context
• Test identity becomes enterprise identity and permissions
• Human-in-the-loop controls stay where evidence says they are needed
• Production telemetry feeds new cases back into the twin

That gives the business something much more useful than a conventional AI demonstration. Operations can challenge exception paths, finance can measure the cost of a completed workflow rather than the price of a token, security teams can inspect which tools the agent attempts to call, and users can show us where the proposed design is still wrong. Historical cases can be replayed to ask how many would have completed without manual intervention, where the agent would have escalated and what new work the process creates for people.

The key is progressive replacement rather than a big-bang integration. If the process proves its economics and its controls, the synthetic services are swapped for governed live services and the twin moves closer to production without discarding the interfaces, validators or evaluation sets created during design. If it does not hold up, the organisation can stop while the cost of change is still relatively low.

WHAT CHANGES ECONOMICALLY

The organisation pays the expensive integration tax after the process has earned it, not before.

Harness engineering

The engineering system around the process

A useful process twin needs more than a capable model. It needs an engineering environment in which agents can build, execute, inspect results and try again, which is why I think the recent conversation around coding harnesses matters well beyond software development. The coding agent SDKs that reached general availability during 2026 are one example of how coding engines are evolving: they expose the agent runtime programmatically, including planning, tool invocation, file edits, multi-turn sessions, custom tools, MCP connectivity, hooks and OpenTelemetry tracing.

In this model, the coding engine is not necessarily the runtime for every production business process. Its value is that it can cheaply generate and continuously improve the artefacts that make the twin realistic: skills, adapters, test services, validators, interfaces, synthetic data and replay scripts. The more of that environment an agent can build and test itself, the lower the cost of exploring a different operating model before the enterprise commits to it.

The process also needs enterprise context. A system is not intelligent because it can query a table; it needs to understand what the organisation means by customer, order, service, entitlement, policy or exception and how those concepts relate. A layered context architecture is emerging across the major platforms: one layer for how people actually work, one for business entities and the relationships between them, and one for institutional knowledge. Those ontologies can also be exposed through MCP, which is particularly relevant when the process twin needs a governed semantic model rather than raw data alone. Several of these capabilities remain in preview as of August 2026.

REASONING BELONGS IN THE MODEL

• Interpret an ambiguous customer request
• Choose the next best action from context
• Summarise evidence for a human approver
• Handle a previously unseen exception

RULES THAT MUST BE EXACT BELONG IN CODE

• Approval thresholds and financial calculations
• Schema and contract validation
• Access-control enforcement
• Policy conditions that should never drift

That distinction matters because the best agentic process will probably contain much more conventional software than the phrase 'agentic AI' suggests. The model should reason where judgement is useful; code should enforce what must remain exact. A well-designed harness makes the boundary explicit and testable.

One possible stack

What the pattern looks like in practice

Around the agent sits the enterprise harness: model choice, identity, permissions, evaluation, tracing, human approval, security, cost and governance. The enterprise agent platforms now reaching the market are one example of how this runtime layer is developing. A model router can optimise requests across approved models for cost, quality and latency, while tracing exposes tool calls, latency, errors and other behaviour needed to understand what the agent actually did. The useful unit of analysis is therefore the completed workflow: what it cost, how long it took, whether it was correct and where a person had to intervene.

TWO HARNESSES, TWO DIFFERENT JOBS

The coding harness optimises for rapid iteration: build, break, regenerate and test. The production harness optimises for trust: identity, policy, observability, security, economics and controlled autonomy. Treating them as the same thing creates confusion about what is safe to move into production.

This is also where model routing and token economics become genuinely operational rather than theoretical. A twin lets the team compare a cheap model on routine steps, a stronger reasoning model on difficult exceptions and deterministic logic where no model is needed at all. That is a much better way to understand AI economics than choosing one model for an entire workflow and discovering the true cost only after deployment.

Delivery

Forward-deployed engineering is how the vision reaches the real enterprise

None of this removes the need for deep customer work; in some ways it makes that need more obvious. Someone still has to decide which process is worth redesigning, understand what the data does not reveal, work with frontline users, challenge the proposed to-be process, work within production constraints and keep the value case visible while the engineering changes. A coding harness can accelerate the build, but it cannot substitute for the people who understand the operating reality.

That is why forward-deployed engineering fits naturally into this model. I do not think of FDE simply as an engineer who happens to sit near the customer; the useful idea is a delivery model that keeps engineering, domain knowledge and the actual workflow in the same learning loop. That loop is the deployment engine for everything described above, because a process twin only earns its value when the people building it are close enough to the work to recognise when the design is wrong. Several of the large platform vendors are now organising that model deliberately rather than assembling it engagement by engagement.

In a process-twin engagement, that combination becomes concrete. Industry and process experts identify the workflow and the operational realities that matter; forward-deployed engineers and coding agents build the twin close to the customer context; harness engineers make the system observable and governable; change specialists work with the people whose roles will change; and value owners define the baseline and the evidence required before production investment is justified. The point is to shorten the distance between business reality, engineering and measurable outcomes, not to create another layer of bespoke consulting.

A good engagement should also leave the customer stronger than it found them. Reusable skills, interfaces, validators, evaluation sets and harness components should remain behind, along with the capability to operate and extend the process without permanent dependence on the forward-deployed team. That is how field learning can become product learning and how one successful workflow can create reusable patterns for the next ten.

ADOPTION BELONGS INSIDE ENGINEERING

If employees first experience the redesigned workflow after integration is complete, the organisation has learned too late. The process twin lets people use and challenge the design while it is still fluid, making adoption and change management part of the engineering loop rather than a training workstream at the end.

The operating model

From software CI/CD to process CI/CD

There is a software-engineering analogy here that I find increasingly useful. We stopped shipping serious software by writing code once and connecting it directly to production; we build, test, evaluate, release, observe and then use production evidence to improve the next version. Agentic business processes increasingly need the same discipline because the thing being changed is no longer only software. It is work itself.

A change to a pricing rule should be replayable against historical orders before it changes live behaviour. A new model should be evaluated against the process rather than only against a generic benchmark. A change in an approval threshold should show what it does to cycle time, risk and human workload, while a new MCP connection should be exercised in a controlled environment before the agent receives production permissions. Production traces then become new evaluation cases for the twin, so the process can keep improving rather than freezing at the point it first went live.

I would describe that loosely as process CI/CD, but I would not turn it into a slogan or suggest that every process should become software. Some parts of work will remain deterministic, some will remain human and some processes should be simplified or removed rather than agentified. The value of the twin is precisely that it gives the organisation a place to work out which is which before making the expensive parts of the architecture real.

Where I land

The next scaling problem is process engineering

WHAT I THINK COMES NEXT

If enterprise AI is going to move from thousands of pilots to thousands of production workflows, we need somewhere the future of work can fail cheaply.

That brings me back to where I started. BPR taught us to understand the as-is process and challenge the to-be rather than simply automate what already existed. SaaS then moved much of that to-be workflow inside applications. AI is beginning to pull orchestration back above those applications, but with a capability we did not have the first time around: the to-be process can be executable, simulated, measured and improved before it goes live.

For me, that is the more interesting enterprise AI opportunity. Process identification tells us where the work and the value really are. Coding engines make the future workflow cheap enough to build and rebuild. The intelligence layer gives the process context, the harness makes it governable, and forward-deployed engineering keeps the whole system close to the customer outcome. We may be coming full circle on BPR, but this time the to-be process can run, and that changes the economics of transformation.

THE PRACTICAL SEQUENCE

Understand the real work, design the future process, build the executable twin, prove value and readiness, connect progressively, observe and improve.

In brief

Why do most enterprise AI pilots fail to reach production?

Access to AI is no longer the constraint. McKinsey found that workflow redesign has the strongest relationship with reported EBIT impact from generative AI, yet only 21 percent of organisations using generative AI have fundamentally redesigned any workflow. The bottleneck is the operating model around the technology, not the model itself.

What is an executable digital twin of a business process?

It is a running version of a proposed future-state workflow built with synthetic data, mock services, shadow interfaces, deterministic validators, agent roles and human approval points. It behaves realistically enough to be challenged and measured before any production system is integrated.

What is a coding harness and why does it matter beyond software development?

A coding harness is an engineering environment in which agents can build, execute, inspect results and try again. It matters beyond software because it makes the artefacts of a process twin cheap to generate and regenerate, which lowers the cost of exploring a different operating model before an enterprise commits to it.

Sources

Evidence used in this essay

• Michael Hammer, "Reengineering Work: Don't Automate, Obliterate," Harvard Business Review, July-August 1990.
• Stanford HAI, AI Index Report 2026, Chapter 4: Economy, corporate AI adoption.
• Deloitte, The State of AI in the Enterprise 2026, survey findings on transformation depth and pilot-to-production.
• PwC, 29th Global CEO Survey 2026, findings on AI revenue and cost impact.
• McKinsey Quarterly, "From adoption to impact: Three horizons of AI transformation," 8 July 2026, survey of 750 employees and leaders.
• McKinsey, "The state of AI: How organizations are rewiring to capture value," 2025.
• Microsoft Learn, Overview of process mining and task mining in Power Automate.
• GitHub, "Copilot SDK is now generally available," 2 June 2026, key capabilities including MCP, hook system and OpenTelemetry tracing.
• Microsoft Learn, Agent integration options for ontology: Fabric IQ ontology as an MCP server.
• Microsoft Learn, Work IQ MCP overview: the intelligence layer grounding agents in shared work context.
• Microsoft Learn, Microsoft Foundry model router: routing across approved models for cost, quality and latency.
• Microsoft Learn, Agent tracing overview in Microsoft Foundry: inputs, outputs, tool usage, latencies and costs.
• Microsoft, "Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence," 2 July 2026.