Your ERP becomes a data platform: where does the workflow live?

Enterprise software used to do two jobs in one product: hold the records and enforce the process. Agents pull those jobs apart. The records stay where they are. The process moves up into a layer that spans systems — and that layer, not the database underneath it, is where your company's advantage ends up living.

So the architecture question is no longer "which suite do we standardise on?" It is: where does the workflow live, and who owns it?

An agentic workflow layer is the software above your systems of record that carries a process end to end: it reads the request, gathers what it needs from the connected systems, applies your rules, stops at the approval points you defined, and leaves an audit trail of what it did.

The records stay; the process moves

In most companies a process is a sequence of human hand-offs between screens: read the mail, look up the customer, check stock, apply the discount rule, draft the document, ask a colleague, update the record. Each step is small. The sequence is the job.

An agent can carry that sequence, which means the process no longer needs to be implemented inside the application that stores the record. What it does need is somewhere to run with proper identity, permissions, orchestration, approval steps and an audit trail. That is a product in its own right, and for most companies it is the first piece of genuinely strategic software they will own in years.

Three routes per system — from the builder's side

The decision repeats per system. ScopeRight frames it as replace, connect or stay from an advisory standpoint. Here is what each route means once you are actually building.

Rebuild it as your own application

Worth it when the system is effectively a store of records with a user interface, and the process around it is yours. On a shared backbone the undifferentiated work — access, permissions, workflow orchestration, audit, administration, APIs — is already there, so the build is your domain model, your screens and your rules.

The honest warning belongs here too: a records application and a full ERP are different orders of magnitude. We will say so when a scope sits on the wrong side of that line.

Connect a workflow layer to it

The common case. The system keeps the records and its own strong processes; your layer runs the work that crosses systems. Two things decide whether this ages well: the quality of the interfaces you depend on, and the discipline to settle the replacement question first. Every integration you build raises the cost of leaving the system you integrated with.

Extend what the vendor ships

Sometimes the vendor's own AI capability is good enough for the workflow in question, and building anything would be waste. Judge it on what is in production for customers like you. Then accept the trade-off: the logic lives in their product, and your improvement rate follows their roadmap.

What belongs in the layer you own

This is the part that gets underestimated, because it does not look like software. In an agentic product, these are the assets:

• the instructions and context given to each agent;
• the decision rules — pricing, compatibility, eligibility, escalation;
• the approval conditions: which actions need a human, and whose name is on them;
• the integration contracts: what is read, what is written, with which permissions;
• the regression set: the real cases that prove the behaviour is still correct after a change.

We would name those explicitly in an agreement, the same way we name code. The detail of how we split what you own from what you license sits in own your AI software: your product is yours, the backbone is licensed and maintained by us, and your environment runs in accounts in your own name — repository, hosting, database, model provider. Each customer runs in its own environment with its own data; there is no shared database across customers, and connecting a system does not mean its data has to move.

Model choice stays yours as well. Nova runs bring-your-own-key access across several model adapters, so swapping a provider is a configuration decision rather than a rewrite. The requirement most companies arrive at is not the best model — it is not being owned by any single model provider, with governance where production actually runs.

For cloud services, EU law now points in the same direction: the Data Act, applicable from 12 September 2025, sets a framework for customers to switch between providers of data-processing services. For the custom build itself, your agreement is what decides.

The layer we are still building: evaluation

One thing we will not pretend is finished. Continuous, automated evaluation of agent behaviour in production is the honest gap in nearly every agent stack today, ours included. It is the next layer we are building, and saying so is more useful than implying it exists.

Until it matures, the substitute is concrete: traces from production, a regression set of real cases that the company owns, named approval points, and human review that is actually staffed. We set out how we handle that in building evals into agentic workflows.

Why this is a decision worth making deliberately

Most companies will not replace their systems of record this decade. Almost all of them will add a workflow layer above them — through a vendor, a consultant, a platform or their own build.

The difference between those options is not the demo. It is whether, three years from now, the rules that make your company good at its work are in software you can change, move and hand to someone else. That is what our approach is built around, whether we build it with you, an implementation partner builds on the backbone, or an SME starts with an assessment that concludes you should keep and improve what you already have.

If you are weighing this for a specific system, discuss your build with us.

Own the software. Own the data. Rent the expertise.