APIs may become the Trojan horse of enterprise AI
Most enterprise systems built to be extended.
For the last twenty or thirty years, the major ERP, CRM, HR, finance and line of business platforms have opened themselves up through APIs because customers needed integrations, partners needed to build extensions, and vendors wanted their platforms to become harder to remove.
For the last twenty or thirty years, the major ERP, CRM, HR, finance and line of business platforms have opened themselves up through APIs because customers needed integrations, partners needed to build extensions, and vendors wanted their platforms to become harder to remove.
The logic was simple enough. If your CRM talks to your finance system, your marketing automation platform, your customer support tool, your reporting stack and the peculiar spreadsheet maintained by Janet in operations, then removing it becomes difficult. The API makes the platform more useful, more embedded and more defensible.
This became so popular that other vendors popped up making API orchestration tools. I worked for one of them and was an integration expert at another. In fact, integration has been so deeply part of my career, that I cannot remember a time when I either wasn’t selling, building or building around API’s and connectors.
But AI agents may just look at what we built with API’s, and start frothing at the memory chips mouth, because here is a way into to really understand how these systems work. And how to copy them!
What was originally designed as an extension layer could now become a discovery layer. The same APIs that allow other systems to plug into an application may also allow an AI agent to understand what the application does, how it structures work, what objects matter, how processes flow, and where value actually lives.
That is a very different use case to why we built API’s in the first place. A very dangerous use case.
We tend to talk about APIs as plumbing. Data comes out, data goes in, something happens in the middle, and everyone pretends the integration project was simpler than it was.
But an API is more than a pipe. It is a map of how a system thinks.
Look at a mature CRM API and you can see the worldview of the product. Accounts, contacts, opportunities, activities, cases, campaigns, owners, stages, permissions, workflows, custom fields, relationships. The API exposes not just data, but the shape of the business process.
An ERP API does the same. Customers, suppliers, invoices, purchase orders, inventory movements, cost centres, approvals, tax rules, journals. Underneath the technical documentation is an operating model.
Historically, humans used those APIs to connect one system to another. Developers read the documentation, built an integration, handled the exceptions, swore at authentication for a while, and eventually shipped something that mostly worked.
Now imagine an AI agent doing something more ambitious.
It connects to the API. It reads the schema. It explores the available objects. It samples records. It observes relationships between entities. It looks at the workflows. It reviews metadata, field names, validation rules, status transitions, audit logs and usage patterns. It does not just extract data. It builds a mental model of the system.
Not perfect. Not magical. But good enough to start asking awkward questions.
What is this system really doing? Which objects are core and which are historical clutter? Which workflows actually matter? Which customisations represent genuine business advantage and which are just scar tissue from a bad implementation in 2017? Which parts of this application could be replicated by a lighter, more focused system built on top of modern tooling?
That is where things get interesting.
The API as an x-ray.
Many enterprise systems are surrounded by mystique. People talk about them as if they are giant cathedral machines that mere mortals should not question.
In reality, many of them are databases, workflows, permissions, forms, reports and integrations wearing an expensive jacket.
A well-directed AI agent could use APIs almost like an x-ray. It could inspect the structure of a system from the inside. It could identify the essential data model, the processes that are actually used, the integrations that matter, and the reporting outputs the business depends on.
That does not mean it can replace SAP by Tuesday afternoon. Anyone saying that has either never seen SAP or is trying to make noise in their pitch deck.
But it may mean something more commercially dangerous.
AI agents could help businesses understand which parts of a large incumbent system are essential, which are replaceable, and which could be rebuilt as narrower applications around the way the business actually works.
That matters because many companies do not hate their core systems in the abstract. They hate specific things.
They hate the slow quote process. They hate the clumsy approval workflow. They hate the customer view that requires six tabs and a prayer. They hate the reporting layer that is always three weeks behind reality. They hate the fact that every change requires a project, a steering committee and someone called a solution architect who appears once a month with a diagram.
If AI can use the API to understand the guts of that process, it can begin to design alternatives.
Not a wholesale rip and replace. Something more surgical, and so the first wave may be replacement around the edges
The obvious mistake is to assume the opportunity is building a full alternative to every incumbent platform. That is where start-ups go to die with a nice pitch and no customers.
The more likely path is edge replacement.
An AI agent studies the existing system through its APIs, understands a particular process, and then helps build a new application around that process. The old ERP or CRM remains the system of record for now, but the user experience, workflow and intelligence layer move elsewhere.
Sales teams may still have Salesforce underneath, but the actual account planning, pipeline inspection, next action guidance and deal coaching could happen in a new AI-native workspace.
Finance teams may still have NetSuite, Dynamics or SAP underneath, but forecasting, variance explanation, invoice triage or approval preparation could move into a more intelligent layer.
Operations teams may still have a line of business system that holds the official records, but scheduling, exception handling, customer communications and performance management could be rebuilt on top.
Nobody wakes up one morning and says, 'Let’s replace the ERP.' They say, 'Can we just build something better for this one awful process?' Then another. Then another. Eventually the incumbent becomes a record store with a maintenance contract. Still profitable, perhaps. But strategically weaker.
The dangerous bit is the learning loop
The real threat is not that AI can read an API schema once and generate an app. That would be clever but limited.
The real threat is the learning loop.
An AI agent can inspect the existing system, propose a better workflow, generate a prototype, watch how users interact with it, compare outputs back to the original system, refine the model, and gradually increase confidence.
The incumbent system becomes both teacher and benchmark.
It shows the agent what entities exist, what rules are enforced, what exceptions occur, and what data quality looks like in the wild. The new application then learns where the old system is strong, where it is weak, and where users have quietly built workarounds because the official process is too painful.
Every enterprise has these workarounds. They live in spreadsheets, email chains, Teams messages, Access databases that should have been retired before some junior staff were born, and the heads of experienced operators who know which buttons not to press.
APIs give AI agents access to the formal system. User behaviour gives them access to the informal system. Put those together and you have the raw material for serious application redesign.
That should make both buyers and vendors sit up.
For buyers, this creates a new opportunity to challenge the assumption that the current system defines the process. It may simply be the place where the process got trapped.
For vendors, it raises an uncomfortable question. If your API lets an AI agent understand enough of your system to build a better experience elsewhere, are you enabling your ecosystem or training your replacement?
The answer is probably both.
This is not just a technical issue
The lazy version of this debate becomes technical very quickly. Authentication, rate limits, schema discovery, API coverage, data extraction, model context windows, security controls. All important, but nun sufficient.
The bigger issue is strategic.
Most companies do not have a clean view of how their core systems actually support value creation. They know what they pay for. They know who complains about what. They know which vendor contract is up for renewal. But they often cannot easily say which workflows are strategically differentiating and which are just administrative gravity.
AI agents using APIs could help create that view.
They could map the operating system of the business, not in the management consultancy sense where someone produces a 78 page PDF and disappears, but in a practical sense. What data exists? What processes exist? Which teams touch them? Where are the delays? Where are the duplicate steps? Which controls are useful? Which parts of the current system would we rebuild if we were starting again today?
That last question is the killer.
Because for years, the answer was academic. You could ask it in a workshop, put the answer on a wall, and then return to the same old system because rebuilding was too expensive and too risky.
AI changes the cost curve. Not to zero, despite what LinkedIn’s more excitable prophets may suggest. But enough to make the question commercially relevant.
If the cost of understanding, prototyping and iterating a replacement workflow falls dramatically, more companies will start challenging the inherited architecture.
What this means for PE and growth businesses
From a Capsicum perspective, this is particularly relevant in PE backed and growth businesses.
These companies often carry a messy application estate. Some systems arrived through acquisition. Some were bought in a hurry. Some were implemented when the business was half the size. Some are loved by one department and despised by another. Some are only still alive because everyone is afraid to touch them.
The standard playbook is to rationalise, integrate or upgrade. Sensible enough, but often slow and expensive.
AI agents create a different option. Before committing to a major transformation programme, use the existing APIs to understand the operating reality. Map the data structures, process flows and usage patterns. Identify where the incumbent system is genuinely needed and where it is simply occupying space.
Then decide where to build around, where to replace at the edge, and where to leave well alone.
That last bit matters. Not every old system is a problem. Some are boring, stable and perfectly adequate. Boring and stable is underrated in enterprise technology. Nobody should use AI as an excuse to poke a mission critical finance process with a stick just because the demo looked shiny.
But in areas where speed, customer experience, commercial execution or management visibility are constrained by legacy workflows, this becomes a serious value creation lever.
The companies that do this well will not start with 'How do we use AI?' They will start with 'Where does the current system slow down the business, and can AI help us understand and rebuild that part faster?'
Much better question. Fewer conference lanyards required.
The defensive move for software vendors
If you are an incumbent software vendor, the answer is not to close the API and hide under the desk. Customers will not thank you for that.
The better answer is to make your own platform easier for AI agents to understand and extend in controlled ways. That means clearer schemas, richer metadata, safer sandboxing, better event models, stronger permissioning, and tools that allow customers to build intelligent workflows without immediately needing to move outside your ecosystem.
In other words, if agents are going to inspect the belly of the system, give them a well-lit tour rather than forcing them through the air vents.
The vendors that embrace this may strengthen their position. The ones that treat AI as a chatbot bolted onto the homepage may find that the real action is happening through the side door.
And the side door is the API. APIs were built to make enterprise systems extensible.
AI agents may make them legible.
That is the shift.
Once a system becomes legible, it becomes easier to challenge. Easier to improve. Easier to wrap. Easier to hollow out. Eventually, in some cases, easier to replace.
This will not happen evenly. Regulated processes, deep transaction engines and highly customised core systems will move slowly. The graveyard of people who underestimated enterprise complexity is large and well-funded.
But around the edges of ERP, CRM and line of business systems, I think we will see a new class of AI-native applications that use incumbent APIs as their starting point. They will learn from the old system, improve the workflow, capture the user, and gradually decide how much of the original platform still needs to remain.
The irony is rather beautiful.
For decades, APIs helped enterprise software platforms become entrenched.
Now they may help AI understand where to start digging.