From Monolithic to Agentic ERP
TECHNOLOGY BLOG | ENTERPRISE ARCHITECTURE
From Monolithic to Agentic ERP
The enterprise technology paradigm is changing. ERP is changing with it.
Authors: Arun Kumar Das & Kathirvel Balakrishnan
Reading time: about 9 minutes
Why ERP architecture is back on the agenda
The success of ERP has been underpinned by the standardisation and integration of business processes—helping organisations drive consistency, operational synergy and process optimisation at enterprise scale. Those foundations remain important, but organisations increasingly need greater flexibility around them: differentiated digital experiences, faster innovation, real-time access to data and intelligence, and the ability to introduce new capabilities without continually changing the transactional core. Business expectations have moved on. Organisations now expect greater agility, faster innovation, differentiated experiences and intelligent decision-making, without sacrificing the consistency, control and transactional integrity that ERP has traditionally provided.
This article traces how ERP architecture has evolved to meet those demands, what each model offers and costs, and how to choose between them.
ERP: from integrated enterprise stack to trusted transactional core ERP has evolved beyond being simply a piece of software. For many organisations, it has provided an integrated enterprise platform connecting business processes, application logic, user experience and transactional data. It typically covers financial management, procurement, manufacturing and production planning, supply chain and inventory, human resources, asset management and customer service operations. A significant part of its value has come from enabling these functions to operate through common processes, data and governance standards.
Hold on to that idea, because every architecture in this story is a different answer to one question: where do you draw the boundaries around that common data and those shared rules? Over several decades, different architectural patterns have emerged in response to changing business and technology priorities.
- ERP 1.0, monolithic suites: one application, tightly integrated modules.
- ERP 2.0, modular ERP: deploy the modules you need on a common platform.
- ERP 3.0, composable ERP: assemble capabilities from specialised services and applications.
- ERP 4.0, Emerging ERP architectures – headless, AI-enabled and increasingly agentic: exposing governed business capabilities through APIs to support differentiated experiences, assistants and agents.
A note on terminology, because the labels are younger than the ideas. Gartner introduced “postmodern ERP” in 2013, predicting the breakup of monolithic ERP into loosely coupled, mostly cloud based applications. Its wider “composable business” framing followed in October 2020, and composable ERP grew out of the two. “Headless” is older still, but it began in commerce around 2013 and was applied to ERP only later, so treat the 2020s as when it became a mainstream ERP term rather than when the pattern first appeared.
The monolith: consistency above all
The classic model is represented by platforms such as SAP ECC, Oracle EBS, Dynamics AX and Infor LN. In a traditional monolithic ERP, typically the modules shares the same database, business rules, user interface framework, security model and release cycle.
That shared foundation is a genuine engineering achievement. When a warehouse operative posts a goods receipt, the system can update inventory, post to the general ledger and create a payables accrual inside a single ACID transaction. Either everything happens or nothing does. Reporting is a join across tables rather than a reconciliation between systems. Processes can be standardised globally, governance is simple, and the vendor ecosystem of training and implementation methods is mature.
The price is the same coupling. Over the years, organisations add custom code through user exits and direct modifications. Each change makes sense at the time. Together they become technical debt that every upgrade must be regression tested against. Because the whole platform upgrades as one unit, upgrades become rare, enormous projects. The organisation can become increasingly dependent on the vendor’s roadmap, while replacing or significantly changing individual capabilities may have implications across the wider platform. The design prioritises consistency over flexibility, and it delivers exactly that.
Modular ERP: a bridge with a catch
Vendors responded with modular deployment. Finance first, procurement later, manufacturing in a third phase. Implementations became smaller, initial investment dropped, and risk was spread across a phased modernisation.
The catch is that modules were independent in the contract but not in the code. They still sat on a centralised data model, and their upgrades remained interconnected. It is like buying a house room by room while sharing one foundation and one boiler. A finance patch, for example, may still have to wait until manufacturing is ready to absorb it.
Cloud native: changing how change happens
Moving a monolithic onto virtual machines in someone else’s data centre is hosting, not architecture. Cloud native ERP goes further and adopts modern engineering practice: microservices, containers, elastic scaling, automated updates and continuous delivery. Platforms such as SAP S/4HANA Cloud, Oracle Fusion Cloud, Dynamics 365 and NetSuite are designed to evolve continuously rather than through large upgrade projects.
There is a quiet consequence. As vendors move towards more frequent cloud releases, extensive modification of the core becomes increasingly difficult and undesirable. You extend it through supported APIs and extension points, a discipline SAP calls a clean core. That habit is the unglamorous prerequisite for everything that follows.
Composable ERP: assemble, do not procure
Composable ERP stops treating one large system as the answer to everything. Business capabilities become the unit of design, and each is served by the best platform for the job. A landscape might look like this.
Capability | Example solution |
Finance | SAP S/4HANA |
CRM | Salesforce |
HR | Workday |
Procurement | Coupa |
Analytics | Microsoft Fabric |
Integration | Azure Integration Services |
Four principles hold this together. The design is centred on business capabilities such as Order to Cash, Procure to Pay, Record to Report and Hire to Retire, rather than on software products. It is API first, so every capability exposes secure interfaces. It is event driven, so systems communicate through events rather than direct dependencies. And components evolve independently, so one can be replaced without disturbing the rest.
The engineering detail is where it gets interesting. When a purchase order is approved in Coupa, it publishes a PurchaseOrderApproved event to a broker such as Azure Event Grid or Service Bus. Finance subscribes and records the commitment. This reduces the need for direct point-to-point dependencies between participating systems.. But a trap waits here. If a service updates its database and then publishes the event as two separate steps, one of them can fail. The transactional outbox pattern solves this by writing the event in the same local transaction as the state change and relaying it afterwards. Because delivery is usually at least once, consumers must also be idempotent, so a replayed event never posts twice.
Notice what happened to that single ACID transaction. It has become a saga, a chain of local transactions with compensating actions when a step fails. You trade instant consistency for eventual consistency, and you must decide deliberately which numbers may be seconds stale and which must never be.
That is the honest ledger of composability. The benefits are real: agility, best of breed choice, reduced vendor dependence and incremental transformation, one capability at a time. So are the costs. More systems mean more integration points. Governance and architecture standards become essential. Keeping a single source of truth demands real master data management, with clear ownership of customer, supplier and product. And access control must span every platform, ideally through one identity provider and least privilege roles.
Headless ERP: the system behind the screens
Traditionally the ERP vendor controlled both the business process and the screen you used to reach it. Headless patterns increasingly separate experience from the underlying business capabilities. ERP can continue to manage core transactional capabilities while different channels and experiences consume those capabilities through governed APIs.
In practice, a field engineer’s mobile app, a customer portal, a Power App and an AI assistant can all call the same create sales order operation. Pricing, validation and credit checks run once, in one place. Behind the gateway sit OAuth 2.0 authentication, throttling and versioning. Teams design contracts first, often with OpenAPI, and consumers call operations rather than reading tables. Throttling matters more than people expect, because it protects the core from a chatty mobile client.
The benefits are tailored experiences, omnichannel support, direct AI integration and new interfaces that do not wait for an ERP upgrade. The costs are that you now own front end development, API quality becomes a product discipline, and every extra channel widens the security surface.
Composable and headless are not the same thing
These terms are constantly confused, yet they answer different questions. Composable asks how to divide business capabilities. Headless asks how to separate experience from capability.
Aspect | Composable ERP | Headless ERP |
Primary focus | Business capabilities | User experience |
Architecture goal | Functional flexibility | Experience flexibility |
Technology driver | Modular services | API consumption |
Front end ownership | Shared | Independent |
Typical outcome | Best of breed ecosystem | Omnichannel experiences |
Mature landscapes use both at once: a composable architecture whose capabilities are exposed through headless interfaces.
When the consumer is an agent
Historically, ERP has primarily provided the trusted processing and recording of enterprise transactions. Increasingly, AI-enabled capabilities around and within ERP can predict outcomes, recommend actions, automate decisions and orchestrate workflows.. The first wave is AI native ERP: embedded copilots, continuous forecasting, intelligent automation and natural language interfaces. An emerging direction is an increasingly agentic enterprise, where AI agents can act on behalf of users across ERP and other governed enterprise capabilities.
A procurement agent evaluates suppliers and raises purchase requests. A finance agent performs reconciliations and investigates exceptions. A supply chain agent spots a disruption and executes mitigation. An HR agent coordinates onboarding.
This is why headless matters so much. An agent is just another API consumer, but a very fast, tireless and occasionally wrong one. So the architecture around it matters. ERP and other enterprise capabilities can be exposed to agents through governed tools and APIs, with emerging standards such as Model Context Protocol providing one approach to connecting agents with those capabilities. An orchestration layer applies policy, including spending limits, segregation of duties and human approval above a threshold. Every action is logged with its reasoning for audit. Idempotency keys stop a retry from double posting, and risky actions can run as a dry run first. Treat an agent like a new employee on probation: least privilege, clear limits and a supervisor.
This is the shift the whole story has been building towards. ERP remains the trusted system of record, while the enterprise evolves around it into an intelligent system of action.
Choosing your architecture
There is no universally correct answer. The right choice depends on what you are optimising for.
- Choose monolithic ERP when standardisation is the main goal, customisation needs are limited and governance simplicity is critical.
- Choose composable ERP when business agility matters, best of breed solutions are required and frequent innovation is expected.
- Choose headless ERP when you need exceptional digital experiences, many user channels, or AI driven interfaces as a strategic priority.
- Choose cloud native ERP when scalability matters, continuous modernisation is desired and you want to minimise infrastructure management.
One practical warning. Do not decompose what does not hurt. Start where the pain is sharpest and use the strangler pattern: place an API facade in front of the legacy function, route traffic through it, then replace the implementation behind it, one capability at a time. An anti corruption layer keeps the old data model from leaking into the new services. The monolith shrinks without ever needing a big bang cutover.
Conclusion
ERP architecture is no longer a discussion about software packages. It is a strategic conversation about how an organisation structures its business capabilities, data, integrations and user experiences.
The monolith gave enterprises consistency and control in an era focused on standardisation. Today the priorities are adaptability, innovation and digital experience, which is driving adoption of composable and headless models. The future is unlikely to be purely monolithic or purely composable. For many organisations, the direction of travel is likely to be towards a hybrid digital core: cloud native ERP for foundational capabilities, composable services for flexibility, and headless experiences for intelligent, AI powered interaction.
ERP is evolving from an integrated enterprise stack towards a trusted transactional core within a broader digital business architecture, one in which processes, experiences, data and increasingly AI-enabled agents can operate across enterprise capabilities. Organisations that manage this shift deliberately can create greater flexibility to respond to change, exploit data and AI, and progressively reinvent how work is performed .