The Two Paths of Modernisation: Build the System, or Layer Agents on the One You Have
Every modernisation decision in 2026 reduces to two paths. There is no third path. The honest diagnosis is the difference between agents in production in 90 days and another five-year programme that never ships.
The previous post in this series argued that legacy modernisation, as it has been understood for the last twenty years, is dead. AI-Native Modernisation has replaced it. The work is to get an AI Agent Workforce running on a governed System of Record.
This post is the operational follow-on. Once the goal is clear, the question becomes: how? And the honest answer is that there are exactly two paths to the goal, depending on what you already have. Most modernisation programmes fail because they pick the wrong path, or because they pretend a third path exists when it does not.
The two paths are not ideological. They are diagnostic.
Path A: Build the System of Record from scratch
Path A is the right answer when the existing System of Record is not modern enough to host an AI Agent Workforce. The signs are unambiguous. There is no governed identity model that can authenticate a non-human worker. There is no event substrate — just polling and database triggers. The data is fragmented across applications, and there is no single source of truth for any major entity. Adding agents to such a substrate produces hallucinations, conflicts, and audit gaps within weeks.
For these enterprises, the right answer is to generate a new System of Record using a metadata-driven, AI-native platform — and deploy agents on top of it. The classic example is the freight industry. Freight had no modern operating system. The vertical was running on a patchwork of email, spreadsheets, port-authority portals, and homegrown apps from the 1990s. Layering AI agents on that substrate would have failed within hours. So we generated the substrate first.
What Path A actually looks like
Path A is faster than people expect. The runtime engines — the metadata engine, the workflow engine, the page rendering engine, the event substrate — are already built. The work is authoring metadata: defining Entities, Views, Workflows, Pages, Frames, Process Templates. This is a configuration exercise, not a code project. It is the difference between writing a recipe and writing the chemistry textbook the recipe sits inside.
The DSL (Domain Specific Language) plays a critical role here. When LLMs author or modify metadata, the DSL minimises the token count and preserves precision. Authoring a Workflow with twenty States and forty Transitions takes a few minutes; manual code-based equivalents would take weeks.
Who Path A is for
Path A fits enterprises that meet at least one of these conditions: the existing core system is end-of-life or unmaintainable; the vertical has no industry-standard ERP and never has; the legacy custom-built application would cost more to extend than to replace; the organisation is launching a new business line that has no incumbent system to integrate with.
Path B: Layer Agents on the System of Record you already have
Path B is the right answer when the existing System of Record is modern enough to host agents. The signs here are equally unambiguous. The enterprise has SAP S/4HANA or ECC under active maintenance, or Oracle Fusion, or Salesforce, or a well-built custom ERP that just works. Master data is reasonably consistent. Standard APIs exist for the core operations. The system itself is not the bottleneck — the absence of an agent workforce is.
For these enterprises, the right answer is non-invasive layering. Agents read from and write to the existing SOR through pre-built connectors. The underlying SAP investment is unchanged. Custom code, transports, and modifications are not required. The SAP support contract is unaffected. The S/4HANA upgrade path remains protected. And agents are operational within weeks.
What Path B actually looks like
The integration layer carries the weight. iHub provides 200+ pre-built connectors for major enterprise systems and adds AI-driven schema-drift healing — agents detect when an API contract changes and self-heal the connector before downstream processes break. This is what makes non-invasive layering economically viable. Without self-healing, every connector is a perpetual maintenance line item; with it, integration becomes a self-healing capability rather than a recurring engineering project.
Once the connectors are live, agents take Service Role allocations against the existing SOR. The same SAP material master is now read by an AI agent. The same Oracle invoice queue is now processed by an agent that posts back to the same Oracle. The user-visible system does not change. Behind the system, a workforce is now operating.
Who Path B is for
Path B fits enterprises that meet most of these conditions: the existing SAP, Oracle, or Salesforce footprint is large and recently invested in; standard APIs and integration mechanisms are well understood; the appetite for risk on the core ERP is low; the priority is speed-to-first-Agent-in-production rather than core-system replacement.
The honest diagnostic
The error mode in modernisation programmes is rarely picking the wrong technology. It is misdiagnosing which path the enterprise is actually on. The pattern repeats:
Pretending you are on Path A when you are really on Path B
This is the multi-year custom rebuild that produces a system no better than what it replaced. The existing SAP works. The Oracle ERP works. But the IT organisation has decided that “modernisation” means writing a replacement, because that is what the last several modernisation programmes meant. Five years and significant capex later, the new system goes live, the old system gets retired, and the operating model is exactly the same. AI agents were never even part of the conversation. This is the most common form of failed modernisation today.
Pretending you are on Path B when you are really on Path A
This is the AI pilot that never reaches production. The substrate is fragmented — spreadsheets, shared mailboxes, a 1990s-era custom app — but the team layers an agent on top anyway, because adding an agent is faster than building an SOR. The agent hallucinates. It writes to the wrong system. The data lineage is unauditable. After six months of pilots, the programme is shut down with the conclusion that “agentic AI is not ready.” The agentic AI was ready. The substrate was not.
Pretending a third path exists
This is the most expensive failure mode. The enterprise tries to do both at once — rebuild the SOR while simultaneously layering agents on the partially-rebuilt system. The two programmes interfere with each other. The agents are fed inconsistent data. The rebuild keeps shifting because the agent requirements keep changing. Years pass; budgets balloon; nothing ships.
Mixed-path enterprises
Most large enterprises run both paths simultaneously, and that is correct. The SAP-running finance organisation is Path B. The custom-built logistics system that was end-of-life five years ago is Path A. The Salesforce-instrumented sales organisation is Path B. The homegrown HR system that the original developers left a decade ago is Path A. The diagnostic is per-function, not per-enterprise.
What matters is that each function is honestly classified before the work begins. The most common mistake is to apply one path uniformly across the estate. SAP shops attempt to rebuild the manufacturing operations alongside the finance operations because rebuilding is “the modernisation playbook.” Custom-app shops attempt to layer agents on a substrate that cannot host them because layering is “the modern way.” The honest answer is almost always: this part Path A, that part Path B, and govern both as a single AI Agent Workforce programme.
What both paths share
Whichever path each function takes, the destination is the same: an AI Agent Workforce running on a governed System of Record. The path-independent components are the same.
- Service Roles and Pairing Rules — the assignment fabric that lets agents and humans share Workflow Task ownership.
- Decision Traces — the immutable record of every agent action, the inputs consulted, the rules applied, the outcome.
- Append-Only Event Logs — the SAP-style transport mechanism for configuration, replacing artisanal change management.
- Guardrails — the middleware chain that bounds agent authority and validates inputs and outputs.
- Process Orchestration — the engine that lets agents own end-to-end Enquiry-to-Cash, Procure-to-Pay, and Order-to-Fulfilment cycles.
This is what makes the two-path model coherent. It is not two products. It is one platform with two onramps, each appropriate to the starting condition of a particular function.
What to do this quarter
Two: apply the diagnostic test to each one. Could a production agent deploy on this substrate in 60 days, using only existing APIs, without modifying the underlying system? Yes = Path B. No = Path A.
Three: pick the highest-ROI Path B function and the highest-ROI Path A function. Run them in parallel as the first wave.
Four: resist the urge to apply one path to the whole enterprise. The two-path model exists because no enterprise is uniformly on either side.
Five: set the success measurement before any vendor arrives. Cycle time before, cycle time after. Error rate before, error rate after. Headcount per process before, headcount per process after.
Closing
The two-path model is not a sales framework. It is what the architecture of the AI-Native enterprise demands. There is no third path because there is no third state for an existing System of Record — either it can host an agent workforce, or it cannot, and you respond accordingly.
The enterprises that get this right move fast. The enterprises that pretend the diagnosis is more complicated than it is spend the next three years discovering that it was not.
The next two posts in this series take each path apart in detail. Post 4 walks through Path B in the SAP context — how non-invasive layering works architecturally and what the first 90 days look like. Post 5 walks through Path A — what generating a new SOR using DSL + AI Builder looks like, and how WorldZone went from no modern operating system to live agents handling enquiry-to-invoice.
Diagnose first. Then choose. Then execute.
VoltusWave is the AI Agent Workforce Platform — the only platform that ships AI Agents AND the System of Record they run on. Two paths to production: build a new SOR via DSL, or layer agents non-invasively on your existing SAP, Oracle, or Salesforce. Fully managed SaaS or fully governed on-premises.