How to avoid choosing an ERP that isn't ready for AI

Every ERP vendor now says they are AI native. Most of them mean they added a chatbot.

I cannot tell you which vendor to pick. What I can tell you is where our agents get stuck, because we have spent the last two years building them. Requirements, testing, training, configuration. Real agents doing real work on real ERP projects.

Along the way we learned that AI native has very little to do with the architecture debates people love. Monolith or microservices, agents do not care. They never see your backend. They only see your APIs.

So this is not a rulebook. It is seven things we ran into, in the order they hurt, and what we think ERP vendors need to support if agents are going to work on their platforms. If you are choosing an ERP right now, these are the things that will bite you in year two, long after the demo is over.

1. If it only exists on a screen, the agent cannot do it

The first wall we hit was simple. Everything the platform can do must be possible through an API, not just through screens.

Take any task a consultant does today in the ERP user interface. Setting up a new warehouse. Defining an approval limit. Creating a pricing rule. Can an agent do the same task through an API?

In most ERP systems the answer is no. Large parts of configuration only exist behind screens. The moment that happens, the agent is stuck. We have watched teams try to get around it with screen scraping and robotic process automation. It breaks every time the vendor changes a screen.

We stopped caring about architecture style very quickly. Whether the vendor built one big system or five hundred small services makes no difference to the agent. The agent never sees the backend. It sees the API contract and nothing else. A monolith with complete, clean APIs is more AI native than a microservices platform where half the configuration is locked behind screens.

What we think vendors need to support: full coverage. If a human can do it in the product, an agent should be able to do it through an API.

2. Fine grained APIs are for developers. Agents need task shaped ones.

Fine grained sounds good. For agents it usually is not, and this took us a while to accept.

Take creating a new customer. In a typical fine grained design the agent must call the customer master API, then the address API, then the payment terms API, then the credit limit API, then the tax registration API, then the price list assignment API. Six or more calls, in the right order, where a failure in call four leaves a half created customer sitting in the system.

Every extra call is a chance to fail. It also fills the agent's context with bookkeeping instead of thinking.

What actually works is one call. Create customer with this profile, defaults from this template, return everything that was set. One call, one meaningful business outcome, one clear result to check.

Anthropic's engineering team published the same finding in their guidance on building tools for agents. Choose tools with high leverage that do a meaningful job, not thin wrappers around existing APIs. Our experience matches theirs completely.

There is a second half to this that we ran into later. Many ERP tasks are not instant. The agent fires a posting or a data load, gets a job ID back, and then has to work out what happened. Did it go through? Is it still running? If the call times out and the agent tries again, does the system post twice? We have seen agents retry a call that had actually succeeded, and quietly create the same record a second time. Task shaped APIs need to be safe to repeat, and they need to tell the agent honestly what state the job is in.

What we think vendors need to support: task shaped APIs alongside the fine grained ones, and every write safe to retry without duplicating.

3. Gates belong at the API layer, and they have to be based on risk

This is the point we got wrong ourselves before we got it right, and we have seen others get it wrong in both directions.

Gate nothing, and you have an agent running loose in a system that controls your inventory, your ledger and your payroll. One wrong configuration change and a warehouse stops shipping.

Gate everything, and something worse happens. Every read, every lookup, every tiny write needs approval. The AI adds no speed, and people start clicking approve without looking. A gate nobody reads is worse than no gate, because it gives false comfort.

What works is risk based. An agent reading item master data to answer a question flows freely. An agent updating a text description on a report layout gets logged and moves on. An agent changing a posting rule, a warehouse putaway strategy or a credit limit stops and waits for a named human, with a clear view of exactly what will change.

And the gate has to sit in the API layer, because that is the only place it cannot be bypassed. A gate in the user interface protects the user interface. An agent does not use the user interface.

We are not alone on this. AWS publishes the same pattern in its Well Architected guidance for agentic AI. Reads proceed on their own, low risk writes get light approval, high risk operations get strict approval. OWASP says the same in its agent security guidance.

What we think vendors need to support: risk classification on every API, and approval enforced at that layer.

4. An agent meets your API for the first time, every single time

An agent should be able to ask the platform what it can do and get an answer it understands. This is where most enterprise APIs fail hardest.

Picture an agent asked to set up intercompany invoicing between two companies. Before it can do anything, it needs to find which APIs exist for that area, what each one does, what inputs each one needs and what the outcomes mean.

The documentation is no help. It is written for human developers who read it once, attend a training and then remember it. Field names like STCD1 or OBJNR mean something to a consultant with ten years on the platform. They mean nothing to an agent. And here is the part people miss: the agent meets the API for the first time on every single task. It has no ten years. It has no colleague to ask.

Discoverable means the platform can list its own capabilities in a form a machine reads. Semantic means every API, field and error speaks business language. Not STCD1, but tax registration number. Not error 4022, but what actually went wrong.

This is the idea behind the Model Context Protocol, the open standard that lets agents discover tools and their contracts at run time. To be clear, MCP is not the answer to AI readiness. It solves discovery. It does nothing for permissions, business rules or safe execution. But discovery is the door, and most ERP platforms have not opened it.

What we think vendors need to support: machine readable capability discovery, and business language everywhere.

5. Mistakes will get through. Plan for the day they do.

Human gates catch mistakes before they happen. Reversibility saves you when one gets through anyway. And in ERP, one will get through. We have learned to build for that day rather than hope it never comes.

Three things are needed.

Preview before commit. When an agent proposes a change to warehouse putaway rules, the platform should show what would happen. These 200 items would move to a different zone, these 14 orders currently in process would be affected. The human approving the gate sees the preview, not just a description of it.

An undo path. If the change goes in and receiving grinds to a halt an hour later, there must be a way back. Restore the previous configuration, or apply a compensating change. Anyone who has watched a warehouse stand still over one wrong configuration knows exactly what this is worth.

A full audit trail under the agent's own identity. Today most automation logs in with a borrowed human account or a shared service user. Six months later an auditor asks who changed this posting rule, and the log says Sarah, except it was an agent using Sarah's login. Nobody can separate what the agent did from what Sarah did. OWASP calls this the attribution gap.

And identity is only half of it. The other half is permissions, and this is where ERP has a problem it has not noticed yet.

Every serious ERP has had role based access control for twenty years. That is not the gap. The gap is that those roles were designed for humans, and agents break the assumptions they were built on.

Roles are too coarse. A human gets a role once and keeps it all day. An agent doing one task needs only the permissions for that task, for the length of that task. Give it a consultant role and it can do far more than the job requires.

Worse, segregation of duties quietly collapses. Your auditors insist the person who creates a vendor cannot also pay an invoice. Now you have one agent identity that can do both, because it was convenient to set up that way. You have not broken any rule in the software. You have broken the control the software exists to enforce, and nobody notices until the audit.

And when an agent acts on behalf of a user, whose permissions apply? The agent's, or the user's? Most platforms have no answer, so in practice the agent runs with whatever the service account has, which is almost always too much.

For a system of record that carries financial statements and stock valuations, none of this is a nice to have. It is the difference between an auditable system and one you can no longer trust.

What we think vendors need to support: preview, undo, a first class identity for every agent, and permissions scoped to the task rather than borrowed from a human role.

6. The platform has to hold the line, not the prompt

Business rules, validation and permissions belong in the platform, not in the prompt. This is the one we feel most strongly about.

It is tempting to write in the agent's instructions, never post an unbalanced journal, never ship against a credit blocked customer, never change configuration in a closed period. Tempting, and worthless as a control. Prompts are guidance, not enforcement. Agents can be manipulated through the data they read, and sometimes they are simply wrong.

Our working assumption is that one day the agent will try to do the wrong thing. On that day, the platform must stop it.

So the journal posting API rejects an unbalanced entry no matter who calls it, human, agent or anything else. The sales order API refuses to release against a blocked customer. The configuration API refuses changes to a closed period. The rule sits in the platform once and protects every caller forever.

OWASP calls this complete mediation. Validate every request rather than trusting the model, and never rely on model output for authorisation decisions.

ERP platforms actually start ahead here, because the good ones were built with strong validation from day one. What worries us is vendors adding new AI convenience APIs that skip those checks in the name of speed. That is exactly backwards.

What we think vendors need to support: no shortcuts. AI APIs go through the same validation as everything else.

7. Tell the agent what went wrong, not just that it went wrong

This is the least discussed point on the list and, for anyone actually building, one of the most important. It is also the one that cost us the most time.

When a human consultant gets error 4022 from an API, they read the documentation, search the vendor community or ask a colleague. When an agent gets error 4022, it has none of that. It has the error text and nothing else.

Compare two responses to the same failed goods issue.

The first says error 4022, transaction failed.

The second says the goods issue failed because the requested quantity of 100 exceeds available stock of 40 in location A02. Either reduce the quantity, or check inbound receipts due this week, or pick from an alternative location with stock.

The first ends the agent's progress, or worse, sends it guessing. The second lets the agent fix the problem on its own and carry on. Anthropic's guidance on agent tools makes this point directly. Error messages should guide agents toward the correct next step, not just report failure.

In ERP, where half of daily work is exceptions, blocked orders, failed postings, stock mismatches, the quality of error messages decides whether an agent is genuinely useful or constantly stuck.

One caution, because we have had to pull this back ourselves. Helpful does not mean unlimited. An error should give the agent enough to act on and nothing more. Do not pour internal logic, table names or unrelated business data into it. The agent is not the only thing that might read it.

What we think vendors need to support: errors that explain the cause, suggest the next step, and stop there.

The Real Test

Notice what is not on this list. Not microservices. Not which cloud. Not which model the vendor licensed. Not how many APIs they advertise.

The count of APIs tells you almost nothing. Six thousand APIs designed for human developers can be less useful to an agent than two hundred designed for agents.

What matters is whether the platform was built for agents to use safely. Task shaped APIs an agent can discover and understand. Risk based gates a human actually reads. Changes that can be previewed, reversed and audited. A platform that enforces its own rules no matter what the AI asks for. And errors that teach the agent instead of stopping it.

None of this shows up in a demo. All of it shows up in year two. That is why it is worth asking about now.

That is the real test of AI native. Everything else is a feature.