Application Equilibrium

Every domain of enterprise software is built around one core object, and everything nearby is pulled toward it. The domain holds its shape until a core forms around an object that sat inside an existing core.

---

Key question. What holds a domain of enterprise software in place, and what breaks it?

Key finding. Each domain of software is built around one core object, its main record, such as the ledger in enterprise resource planning (ERP) or the account in customer relationship management (CRM). A core is the product built around that object. Features and ancillary solutions emerge around the core and a balance forms. I call the steady state application equilibrium. A domain holds its shape, it maintains equilibrium, until a core forms around an object that sat inside an existing core. That creates a new domain, and the new core applies its own process and rigor around the object.

Many people are asking whether AI agents will replace core systems like ERP and CRM. I think it's the wrong question. The better one is who gets to reach a core system's data, and on what terms, and the answers are arriving now.

Salesforce went headless in April 2026, so agents can use it without its screen.¹ On October 7, 2026 RealPage paused new activations of EliseAI, a leasing AI company.² On October 13, 2026 Workday made its server for outside agents generally available.³

An agent can change how a core is reached, not what the domain is built around. The exception is an agent that comes to hold a core object of its own.

I have watched similar questions play out from three chairs: analyst at Gartner, buyer at Irvine Company and vendor at MRI Software. Read the four pieces in order:

• 1. Application Equilibrium, the theory. You are here.

• 2. Seven Domains, the multifamily example.

• 3. Will AI Agents Replace Systems of Record?, the pressure test.

• 4. What Stays Scarce in a World of Agents, what holds.

Enterprise software keeps changing shape. It ran on premise, moved to the cloud, and is now going headless.

Each move raised the same question: do the winners of the last era keep their domains? The answer has mostly been yes.

The interesting part is when the equilibrium changed. Something a core held as an element of its data became an object of its own, as the account did when CRM broke out of ERP.

One question sorts every case in the record: does a core form around the object? Most domains never leave the steady state. The object stays an element of a core. The domain holds. The record is long, and part of it is mine.

The Model: One Question Decides Whether a Domain Holds

Picture a core as the nucleus of an atom. It is the product that holds the object's authoritative record and runs the process around it. Everything nearby is held close by a strong force. That force keeps the domain in equilibrium. A domain is a competitive market. No vendor owns it. Many products keep records of the same object, the ledger, the account or the worker. A product holds the core object only when it is built around it, not when it keeps a copy.

Now and then something nearby breaks free. Salesforce made the account, which ERP had treated as a field, the center of a core of its own, and CRM became a domain apart. The story is below.

Some products look like cores and are not.

A non-core component can appear as a bridge or a loop. Payroll is a bridge with an outcome of its own. It takes the worker's data from HR, runs its own statutes, rules and time clocks, pays the worker and files the taxes. Then it posts the result to the ERP's ledger.

Payables automation is a loop. It takes invoices and payables from the core, adds process and rigor the core never applied, such as capture, matching and approval, and returns the result.

Each has its own processes and data and serves a core's mission. Neither replaces the core. The authoritative record still lives there.

A component can also be used standalone, apart from any core. That use means a less well integrated set of applications working toward the same outcome.

Five terms, held fixed

Five terms carry this series, and each means one thing.

A domain is a field of competition, such as ERP, CRM or HR. Many vendors compete in one.

A core object is the record a product is built around: the ledger, the account, the worker. A domain organizes around one core object, and many products keep records of it.

A core object can be a compound record when its parts live together in the product's own data model. A lease with its ledger is one. A building with its units and their condition history is another.

The test is the data model, not the number of nouns.

A core is a product built around that object, the system a buyer calls ERP or CRM. One domain can have several cores, and one vendor can sell cores in more than one domain. A product that serves a core, consuming its data and returning data to it, is a component, not a core.

A system of record is the core's authoritative history of its object, the version an auditor signs against.

Access is the set of terms on which anyone else can read the object or start the core's processes. It runs through an API, the interface programmers use, or a Model Context Protocol (MCP) server, a standard interface built for agents. The later pieces turn on access, because agents arrive through it. An agent is software that acts for a person or organization across systems.

One question decides whether a domain holds

Does a core form around the object? Either the object stays an element of an existing core, and its process and rigor live in that core. Or a new core forms around it, and process and rigor are built around it.

Most domains sit in the steady state: the object stays an element of a core, and the domain holds. The cases below take each outcome in turn.

The Cases: A Domain Holds or Splits Off

In 2000, at Gartner, I helped write the research note that argued ERP's back-office kernel would reach outward and consume the domains around it, a process we called the cycle of assimilation. CRM was one of them. The core would win, because the core always won.

I remember a senior SAP leader referencing the note at SAP's annual conference. SAP built a CRM, and ERP still did not take the domain. We were right about the pattern. We missed what would break it.

The domain holds: the object stays an element of a core

ERP was the product of the same cycle a lap earlier. Material requirements planning (MRP) began as one narrow object, inventory and production scheduling. It consumed capacity planning, labor and shop-floor scheduling, became MRP II, and by the 1990s was broad enough to need a new name, which Gartner supplied: enterprise resource planning.⁴ That cycle ran to completion. For CRM, it didn't.

We should have framed the test for what ERP consumed around what drove changes to the financial system of record. Anything that did lived in ERP: purchasing, inventory and order entry. CRM did not, because in the ERP of that era the account was at best an attribute of a transaction.

The test is whether the authoritative record of the object lives in the core. The invoice and the payable are elements of the ledger, and payables automation sped up their processing while the outcomes still posted to the ledger. Payroll has the same shape: statutes, local rules and time clocks drive the process, and the ERP is fed the outcome of the run.

In each case the product was built around an element of the core and its result ended up there, so it stayed a bolt-on.

A component can be integrated without being a core. Payables automation and payroll have their own processes and their own data, and they serve the mission of the core they connect to.

They consume data from the core and provide data back to it. Their own processes and data make them a product, not a core: no domain organizes around what they hold, because the authoritative record stays in the core they serve.

A new domain, led by a newcomer: Salesforce and the account

An object that sat inside an existing core. ERP kept the account as an attribute, a field on a transaction, and Salesforce made it the thing the product was built around.

The account is the relationship that persists across transactions, and CRM became a domain apart from ERP. A 2020 study by Haddara and Constantini found organizations still widely bought separate CRM systems even when their ERP package included a CRM module.⁵

I saw the same gap as a buyer. At Irvine Company, the density of the portfolio created a need for customer-centric thinking beyond what the property management systems of the time could provide. We needed more than a global guest card.

A similar gap showed up in ERP, where the unit of work is a sale, not a lease. An invoice and a payable posted to the ledger. The account did not. The calls, the pipeline and the service history never touched the ledger, and only the booked order did. ERP held the account as a field on a transaction.

The work and its records lived somewhere else, and that is where a new core was needed. A core applies its own process and rigor around the object. The pipeline, the calls and the service history are run and recorded where they happen. Only the booked order crosses to the ledger.

The lesson was never that ERP's equilibrium was weak. An equilibrium holds only the object it is built around. Salesforce won by building a different object next to it, and it still talks to the ERP.

The question a buyer can use is simple: what is this product built around, and does the vendor hold it?

A new domain, led by the incumbent

When an object that sat inside an existing core breaks out, it lands inside the incumbent's reach. The incumbent can build it, and it does. The later pieces test that against multifamily software and against agents.

Why Most Domains Hold

Two things hold a domain in place when no new object arrives.

The record is the hard thing to move. The ledger is the company's official account of its money, and in the ledger decisions I have seen, the CFO signs that it is right.

A company will change how people reach the ledger long before it moves the ledger, because moving it puts that signature at risk.

Swapping one working ledger for another is often not reason enough on its own. Cheaper migration lowers one cost of moving a record. It does not remove the signature, and it does not supply a reason to move.

Buyers favor the integrated suite. Every extra vendor adds an integration. In 2013 Gartner described postmodern ERP, the suite taken apart into the best application for each area, integrated as needed.

By 2018 analysts were reporting that buyers still wanted one vendor.

Ray Wang of Constellation Research said "For a lot of folks, they would still rather buy from one vendor." Forrester's George Lawrie said "The thing our clients worry about a lot is data integrity."⁶ The tendency is to favor integrated over best of breed until good enough is not good enough. Buyers kept weighing the same question: who holds the record, and who answers when two systems disagree.

Surfaces changed, and none of them moved the object

A surface is the way a person reaches a core. People have reached the same core by typing commands, then filling in formatted screens on terminals, pointing at objects in windows, and following links on pages. Each step lowered the skill a person needed, and each ran the earlier one inside it: terminal emulators ran in windows, and pages ran in browser windows.⁷

Mobile added no step. It put the same window or page on a smaller screen.

In every one of those steps the object under the surface stayed put. The ledger was still the ledger behind green screens, windows and pages. A new surface changes who can use a core and how well. It does not change what the core is built around, which is why surfaces alone do not break an equilibrium.

What a Buyer Should Ask, and Where Agents Land

Here is the one question I would put to any vendor: is your product where the record lives, or does it work from someone else's copy?

The object decides, and where it innovates decides the rest

A buyer meets the equilibrium as the 2000 question again, integrated or best of breed. Take the bundled version from the vendor already on the books, or the tool that does one thing deeper.

A focused product wins where it holds an object the suite lacks, or does more with the object than the suite, and a connector now costs little. Ask each vendor which object it holds and where its innovation lands. I call this the object test.

To tell whether a vendor holds the object, follow one account from sales to billing to service: does its history show up at each step, or is it missing? Visible means the object is held once and every function shares it.

Missing means each function keeps its own copy, a sign the vendor does not hold the object, not proof.

To the incumbent, the one already holding the core:

• Which parts of this new AI layer are actually a new object, and which are sitting on top of the data I already have?

• How do outside agents reach my data through your product, by API, MCP server or both, and what do your contract terms say about their access, pricing and limits?

To the challenger, the one trying to get in:

• What object do you hold that my current system doesn't, in one sentence, not a feature list?

• Show me the object, not the workflow around it. If I asked for it in a support ticket, what would you export?

• How do you reach my existing systems, by API, MCP server or both, and what happens to your product if their owners change the terms?

A strong answer names one record and shows its history.

An Agent Changes the Equilibrium Only if It Forms a New Core

The object compounds. A vendor that holds the object can build improvements on its accumulated history, and the improvements that depend on that history raise the cost of leaving. This includes AI agents and workflows.

Count the clocks. MRP took three decades, from the 1960s to the 1990s, to become ERP. Salesforce was founded in 1999, and the 2020 study cited above still found CRM bought separately. From these cases, equilibria break in decades, not quarters. That sets the bar for any forecast, including any forecast about agents.

Regulation, distribution, acquisition, pricing and changes in buyer behavior can also move a domain, and I do not claim they never do.

Agents change how a core is reached. They change the equilibrium only if one forms a core around an object of its own. Will AI Agents Replace Systems of Record? works backward from 2032 to see what that would take.

There are four seats in the name. The fifth one is yours.

¹ Salesforce Headless 360, introduced April 15, 2026 at TrailblazerDX: Beri. Salesforce, April 21, 2026: 6 New Innovations Redefining Salesforce Development, which says every capability Salesforce has built over 25 years "is now available via API, MCP, or CLI." That post does not use the name Headless 360. Marc Benioff's April 17, 2026 post, "No browser required. Our API is the UI," is quoted by SaaStr.

² RealPage CEO Dirk Wakeham, October 12, 2026: Multifamily Dive. The October 7 pause was first reported by Thesis Driven.

³ Workday, October 13, 2026: The New Stack. The article says Workday's MCP server, SQL access to live data and a shared runtime for agents are now generally available, and names two further pieces for early access in early 2027.

⁴ Material requirements planning, 1964: Wikipedia. Gartner is credited with first using the term enterprise resource planning in the 1990s: Wikipedia on enterprise resource planning. NetSuite's vendor history dates it to 1990: NetSuite.

⁵ Haddara and Constantini, "Fused or Unfused? The Parable of ERP II," International Journal of Information Systems and Project Management 8(3), 2020: AIS eLibrary. I read the abstract page, not the full text. It says that although many ERP packages include CRM modules, separate CRM systems are still widely adopted, so current ERPs have not reached the ERP II state. The finding is dated to 2020.

⁶ Rosencrance, TechTarget, September 5, 2018: Postmodern ERP countered by continued appeal of single suite. Gartner introduced the term in 2013. The quotes from Ray Wang of Constellation Research and George Lawrie of Forrester are from that article, read as an extract. The article contains no survey data.

⁷ Command line: Wikipedia on the command-line interface (CTSS, 1961; Teletype Model 33, 1963). Terminal: IBM 3270, introduced 1971. Windows: Wikipedia on the graphical user interface (Xerox Alto, 1973; Macintosh, 1984). Pages: Wikipedia on the World Wide Web (released to the Internet in 1991; Mosaic, 1993). The App Store opened July 10, 2008: Wikipedia. The sequence itself is the author's framing, not a sourced history.