The Great Re-Engineering
All business processes are legacy. They were designed for a world where AI didn’t exist. Re-engineering them, not optimizing them, is the defining work of the next decade.
Every process in your enterprise is legacy. It was designed for a world where AI did not exist. This is why we are now entering the decade of ‘the great re-engineering’: every company will reinvent itself or die. The constraint is not access to AI but knowing where it belongs in your business and redesigning your operations and enterprise architecture around it.
Jakob Freund, CEO, Camunda
Every business process running in your organisation today was designed before modern AI existed. Before large language models. Before agents that can reason and act. Before it was possible to hand AI genuine authority over how work moves.
That’s not a criticism. It’s a fact. Those processes were designed intelligently, for the world that existed at the time: a world where humans had to fill every gap that software couldn’t, where approval chains existed because systems couldn’t make judgments, where documentation was necessary because nothing could read context.
That world has changed. The processes have not.
What “legacy” actually means
When people call a process legacy, they usually mean it’s old or inefficient. That’s not quite right. A process is legacy when its design assumptions no longer reflect what’s possible.
Your accounts payable process routes invoices to humans because, when it was designed, only humans could read a PDF and cross-reference it against a purchase order. Your onboarding process takes weeks because it was built around the time required to gather, verify, and move information between systems that couldn’t talk to each other. Your customer service process has escalation paths because exceptions required judgment that software couldn’t provide.
None of these constraints exist in the same form today. The structural assumptions embedded in your processes are no longer true. But the processes, and the constraints they encode, remain.
The gap is already visible in tech
AI-native companies in tech are generating revenue per employee that legacy software companies cannot approach. Not marginally more. An order of magnitude more.
ARR per employee · 2025
AI-native
Legacy SaaS
Source: Accel Globalscape Report 2025
The gap between Cursor and Datadog is not a product difference. It is an operational model difference. Cursor was built around AI from the start: every process, every workflow, designed for a world where AI does the work. Datadog was built before that world existed.
What is happening in tech will happen in every industry. The organisations that re-engineer their operations around AI, not just deploy AI into existing operations, will have structural cost and output advantages that legacy-process competitors cannot close through optimisation alone.
Why adding AI isn’t enough
The natural response is to add AI to existing processes. In most enterprises, this has meant task assistance: recommendations, AI-assisted search, chatbots not truly empowered to act. It works, up to a point.
The result is a faster version of the same process. Not a better one.
AI added to a legacy process
~20%
faster. The same steps. The same structural constraints. The same ceiling, just approached more quickly.
Re-engineered AI-first process
Months → Days
Danica re-engineered their customer onboarding with Camunda. A process that took months was reduced to days. Not by automating the old steps, but by redesigning them entirely for an AI-first world.
Worse, bolting AI onto legacy processes compounds technical and organisational debt: more complexity, more fragility, more cost. Doing nothing is not neutral.
Research: INSEAD & Harvard Business School, March 2026
A field experiment studying 515 companies given identical AI tools, identical budgets, and identical technical training found a stark difference in outcomes based on one variable: whether companies restructured their operations around AI, or deployed AI into existing processes.
The firms that restructured generated 1.9× the revenue, were 18% more likely to win paying customers, and needed 39.5% less capital to achieve the same growth.
Those that deployed AI into existing processes saw marginal gains. The researchers named this failure mode: the mapping problem. When you map AI onto a process designed without it, you get a faster version of the old process. Not a better one.
Read the research →The ceiling is structural. It lives in the design of the process itself: the sequence of steps, the handoffs, the approval gates, the exception paths. Adding AI to a process designed for human limitations doesn’t remove those limitations. It just moves faster inside them.
The right question
Re-engineering is not about optimisation. It’s about asking a different question entirely.
AI-first process transformation must work backwards from outcomes, not forward from current reality.
ProcessOS tackles the real reason AI adoption stalls: we can’t build tomorrow’s processes using only what we know today. Transformation starts with a bold vision of the future.
Lily Wang, Managing Director, Barclays
What would you design if you were starting today, knowing what AI can now do? If you had agents that could read any document, correlate any data, make judgment calls on edge cases, and act on your behalf: what would the process look like? What steps would you remove? What approvals would become unnecessary? What would you redesign around the outcome rather than the constraint?
That question produces different answers from “how do we automate step four.” And those answers lead to processes that are qualitatively different. Not a percentage improvement, but a different operating model entirely.
What re-engineering looks like in practice
Business process re-engineering is not a new concept. Hammer and Champy wrote the book in 1993. What is new is that the barriers to doing it have collapsed.
Re-engineering used to require months of consultant-led discovery. Process workshops. Documentation. Modeling. Then a separate build phase measured in quarters. The overhead was so large that most organisations limited re-engineering to their highest-value, most broken processes, and even then, many projects failed before reaching production.
AI changes every phase of this work.
Discover how you actually work
AI agents query your systems, analyze your data, and read your documentation. They surface how your processes actually run, not how they were documented, including the edge cases, exceptions, and workarounds that consultants spend weeks uncovering. Discovery that used to take 2–3 months takes 1–2 weeks.
Re-engineer for the outcome you want
You define what good looks like: a fitness function of KPIs weighted by what matters in your domain. AI designs an AI-native process around that goal, not around the constraints of the old one. Re-engineering that used to take 1–2 months of design work takes a week.
Build and deploy
AI generates the BPMN process models, the worker code, the connectors, and the tests. Architects and developers review, extend, and approve. A build phase that used to take 3–6 months takes 2–4 weeks.
Continuously improve
Once in production, AI monitors performance against your fitness function. It backtests proposed improvements against real historical data before surfacing them for human approval. Optimisation becomes continuous rather than a quarterly exercise.
The process shape itself changes.
A legacy product development process might have 8 steps across 6 roles in a linear sequence. An AI-first version of the same process has 5 steps, 2–3 roles, and a continuous feedback loop. AI removes the handoffs that existed only to move information between people. Re-engineering doesn’t speed up the old shape. It produces a structurally different shape.
The compounding effect
10× faster
The second process you re-engineer is faster than the first. The tenth is dramatically faster than the second. Every engagement builds organizational memory: your systems, your integration patterns, your edge cases, your decisions. The catalog grows with proven connectors. The work compounds.
This is not a technology project
Re-engineering is an organisational decision before it’s a technology one. It requires a willingness to ask what you’d design from scratch, which means being willing to let go of what you designed before.
That is harder than it sounds. Existing processes have stakeholders. They represent decisions that were once correct. Changing them requires someone with the authority and the clarity of purpose to say: the constraints that shaped this process no longer exist. We are going to design around what’s now possible.
The organisations doing this work are not moving faster. They are operating at a different level. The ones that add AI to their existing processes will improve. The ones that re-engineer will transform.
Business process re-engineering is the most important thing my organisation will do over the next 2–3 years.
Mark Zanoli, Global Chairman, Barclays Investment Bank
The window is open. It will not stay open.
Process re-engineering at this speed and cost is new. The technology that makes it possible is roughly 18 months old. The organisations that move now will build organizational memory, the institutional knowledge encoded in AI systems, while their competitors are still running discovery workshops.
That knowledge compounds. The gap between organisations that re-engineer now and those that wait will not be linear. It will accelerate.
The great re-engineering has started. The question is whether your organisation is doing it, or watching someone else do it first.
ProcessOS is the intelligence layer that makes this possible. It works with the systems you already have, not against them. ProcessOS discovers how you work, re-engineers your processes, builds them, and continuously improves them.
Learn about ProcessOS →Ready to re-engineer your first process?
Start with Process Zero. We deliver your first production process end-to-end.