Someone asks for a customer's balance. A person in the back office opens the ERP, finds the account, scrolls through the transactions and comes back with the number. When that query repeats throughout the day, the time goes into navigating screens to find something that is already in the system. And if the person asking doesn't have access, they ask someone who does.
At Ancap IT we use Xubio for our own administration. We built our own integration, based on MCP and on Xubio's public APIs, and today we do several of the tasks that used to require opening the interface from an AI assistant: checking balances and transactions for customers and suppliers, pending collections and payments, invoices issued and received. It isn't a product or a public case study; it's how we work.
What it left us with is a question that applies to much larger systems: if part of the daily work can be done without opening the system, what should we do with the systems we already have?
What it is, without the jargon
The flow is simple. Someone asks the assistant for something in plain language. An integration turns that request into a call to a tool, which uses the ERP's APIs. The ERP processes and records the operation as it always has. The assistant returns the result.
Three pieces, and it pays not to mix them up: the assistant (Claude, ChatGPT, Gemini, Copilot), the server that exposes the tools, and the ERP's APIs. The protocol connecting the first two is called MCP; it's open, it has been governed by the Linux Foundation since December 2025, and all four major assistants consume it.
What the protocol doesn't bring: permissions, confirmations before changing data, and the record of what the assistant did all depend on how the integration is implemented and controlled. That's the part you have to design, not the part that comes for free.
What belongs in a chat and what doesn't
What we saw ourselves: for one-off queries, the chat saves several steps. For comparing lots of data at once, reviewing exceptions or filling in long forms, the screen is still more practical.
It matches what others have measured. A 2025 Stanford study found that people prefer a visual interface over chat in 93.8% of data-analysis tasks, but that on real user queries the advantage drops to 50.8%, and for simple questions chat wins. Gartner sums it up as assistants for simple retrieval, automation for routine workflows, agents for decisions.
What doesn't change because you operate from a chat: data quality, API coverage (whatever exists only on a screen is out of reach), transaction integrity and auditability. Thoughtworks put the idea of naively converting internal APIs to MCP on Hold: chaining small calls eats context, and there is no deterministic way to stop an agent from misusing a destructive operation. Their recommendation, and ours, is a dedicated server with coarse-grained actions that doesn't expose what shouldn't be touched.
Two examples from outside
Revolut launched its assistant AIR inside its app in April 2026. It answers questions about spending, finds transactions, freezes a card, pauses a recurring payment; sensitive actions require biometrics. It's an interesting decision: change the interaction without touching the transactional infrastructure.
Stripe is closer to what we're describing: it exposes read and write operations on its platform to external assistants, but with a separate identity for the agent, mandatory human approval for refunds and outbound payments, and a log of every call. That model of controls is the one that carries over to an ERP.
What changes for EBS, Fusion and SAP
Three questions per platform: can it be done, what limits it, where to start.
Oracle E-Business Suite 12.2. It can be done. The most direct route is to integrate the assistant outside the Forms screens, through the interfaces the system exposes: ISG has published registered PL/SQL, concurrent programs and open interfaces as REST since 12.2.3, and Oracle Integration has an EBS adapter and, since September 2026, an MCP gateway. What limits it is API coverage for the specific task (customizations have to be registered) and the work of carrying the responsibilities, permissions and auditing EBS already has over to the integration. Premier Support for 12.2 is extended through at least 2037, so the clock isn't pressing. Where to start: a frequent query that already has an API.
Oracle Fusion Cloud. It can be done, and Oracle already provides part of the path: AI Agent Studio comes with Fusion (check the documentation for which uses are included and which require a subscription), and since release 26A Fusion agents can consume external tools over MCP. To operate Fusion from an external assistant, the route is Oracle Integration or the REST APIs. The question isn't whether it can be done but where people work: if they live in Fusion, Oracle's agents; if they live in Claude or Copilot, the integration.
SAP. It can be done, with a precondition: beyond the APIs, you need to check which architecture the SAP API Policy in force since April 2026 allows for connecting external assistants. That's where any conversation starts.
What's worth hearing before you start
Agents fail at long, open-ended tasks, there have been real security incidents on MCP servers, and Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. All of it points the same way: narrow scope, read by default, write with approval, a metric before you start. We wouldn't start with an assistant that can operate the whole ERP. We'd start with one concrete query, like which invoices are due this week.
How to decide
These are three separate decisions. How you interact with the system (that's where the assistant comes in). Whether the system is still a good system of record (data, APIs, support, cost). And whether it should be migrated. An assistant doesn't fix an ERP with dirty data and doesn't change the SAP ECC calendar (mainstream maintenance through 2027, extended through 2030). But trying a frequent task that already has an API helps tell whether the problem is the ERP or the steps it takes to use it.
A few situations worth looking at, as candidates to evaluate and not as something we've already done on those systems: checking the status of a purchase order and its receipts; getting a supplier's current balance with due dates; knowing which documents are still pending approval, and with whom.
If there's a query or task your team repeats every day inside the ERP, reply with an example. I'd like to hear about it.