A traditional ERP is built for a person at a screen. Its features, its integrations and its audit trail all assume that work enters through forms a human fills in. An AI-native ERP is built for an agent as the primary user: every action the system can take is exposed as a typed tool an agent can call over an open protocol, and each call is checked against the permissions of the person the agent represents. People still use screens to look and decide; they are no longer the only way work gets done.
That is an architectural difference rather than a feature difference. A traditional ERP with an assistant added still routes work through the person. An AI-native ERP routes work through the agent and keeps the record as a by-product. The rest of this piece shows where the two paths split and what follows from it.
Trace one purchase order through both systems
Start with something ordinary. A supplier called Northwind has quoted for stock, the quote is acceptable, and the business needs a purchase order raised, sent, and matched when the goods and the invoice arrive. Follow that request through each architecture and the difference is visible before any feature list is opened.
In the traditional system the path is a person's path. Somebody opens the purchasing module, finds or creates the supplier, keys the lines from the quote, checks the cost centre, saves, exports the document, attaches it to an email, and later returns to receive the goods and match the invoice. If the system has an assistant, it may pre-fill the lines from the quote or draft the email. The person remains the one who moves from screen to screen, and the assistant only reaches the screens the vendor chose to connect it to.
In the AI-native system the path is an agent's path. The person tells their agent what they want. The agent asks the workspace which tools it may use, and the workspace answers with a filtered list: supplier lookup, purchase order creation, document sending, goods receipt, invoice matching, and nothing that person's role does not permit. The agent calls those tools in sequence, the workspace checks each call again as it runs, and the purchase order, the sent document and the later match exist in the system exactly as if a person had keyed them. The person sees the result and the log, not the forms.
In an AI-native system the request passes from the person to their agent, then through a permission layer, before any module is touched. The same layer that governs a person's access governs the agent's.
The primary user is the difference
Everything else in the AI-native ERP vs traditional ERP comparison follows from one design decision: who the software expects to be operating it. Traditional ERP answers that question with a person, and forty years of good work has gone into making the person's job easier. Screens got faster, workflows got configurable, mobile apps arrived, and eventually an assistant appeared beside the form. None of it changed who was at the controls.
AI-native ERP answers the same question with an agent acting for a person. Once that is the answer, the product has to be built differently from the first line. Every capability needs a tool definition with a name, typed inputs and a result, not only a screen. The permission model has to work per call, not per session, because a single request may fan out into a dozen calls across modules. The protocol has to be open, because the agent doing the calling may belong to the customer and not to the vendor. And the audit log has to record what the agent did with the same fidelity as what a person did, because that log is now the primary way a manager reviews the work.
What follows from it: six consequences
The table below is the practical comparison. Each row is a consequence of the primary-user decision rather than a feature one vendor chose and another did not.
| Traditional ERP | AI-native ERP | |
|---|---|---|
| Primary user | A person at a screen | An agent acting for a person |
| How work enters | Forms, imports, integrations built for each pairing | Tool calls over an open protocol; screens remain for review |
| Reach of the AI | The features the vendor connected the assistant to | Every action the system has, because each one is a tool |
| Which agent | The vendor's, inside the product, if any | Any compatible client, including one the customer already uses |
| Permissions | Per user, per session | Per user, checked when tools are offered and again on every call |
| Audit | Who changed which record | Who asked, which agent acted, which tools ran with which inputs and results |
Rows are architectural consequences, not scores. A traditional ERP can be excellent at what it was built for.
The row that surprises buyers most is reach. An assistant added to a traditional system feels broad in a demo because the demo is scripted around the features it touches. In daily use it stops at the edge of those features, and the person takes over. In an agent-native system the boundary is the person's permissions, which is a different and more useful boundary.
What does not change
It is worth being precise about what stays the same, because vendors on both sides blur it. The data model does not change. Double-entry accounting is double-entry accounting whether an agent or a person posts the journal. Tax rules, multi-currency handling, stock valuation, period close and document numbering are the same problems with the same answers. An AI-native system that gets these wrong is a bad ERP with a good interface for agents, which is not a trade worth making.
Permissions do not change in principle either; they change in where they are enforced. A traditional system checks what a user may see when a screen loads. An AI-native system has to check what a user may do every time a tool is called, because there is no screen load to hang the check on. The rule is the same. The enforcement point moves.
The need for judgement does not change. An agent will raise the purchase order and match the invoice; it will also stop when two supplier records look like the same company, when a match is out of tolerance, or when an approval sits above its user's authority. Those pauses are the system working as designed, and the first weeks with an agent look a lot like the first weeks with a capable new colleague.
Where traditional ERP is still the right answer
An honest comparison has to say when the older architecture wins. If the business runs deep, validated manufacturing or regulated processes with decades of customisation inside an established suite, the cost of moving is real and the assistant that suite now ships may be enough for what the team actually needs from AI, which is often summarising, drafting and answering questions about the data. If the operation is a handful of people with a bookkeeping package and a spreadsheet, either architecture is more than they use.
The case for AI-native is strongest in the middle: a business with enough routine, cross-module work that the entering has become a job in itself, and a team that already uses an agent for other things and would rather point it at the business than learn another vendor's chat window. That is where routing work through the agent pays back quickly, and where being able to bring your own agent stops being a slogan and starts being a line on the cost sheet, since a workspace performs no AI on your behalf when your own agent does the reasoning.
How to tell which architecture you are being shown
Demos are designed to make the two look alike. The following sequence separates them in under an hour and does not need a technical person to run it.
- Bring your own agentConnect the agent you already use (Claude, ChatGPT or another MCP client) from outside the vendor's product. If that is not possible, you have your answer on the protocol question.
- Ask for the tool listHave the agent list what it is allowed to do. Check that the list is long, covers the modules you care about, and changes when you sign in as a more restricted user.
- Complete one outcomeAsk the agent to raise, send and schedule the follow-up for one purchase order with nobody touching a screen. Watch whether it finishes or hands back to a person part way.
- Read the logFind the record of what the agent did: who asked, which tools ran, with which inputs. If that log is thinner than the log for a person, the agent is a guest in the system rather than a user of it.
Sois is one implementation of the AI-native architecture, and it is the one we can describe precisely. A workspace is an MCP server. Any compatible client connects by adding the workspace address and signing in once over OAuth, with no token to paste. The tools offered are filtered by the user's role before the agent sees them and checked again when each runs; access fails closed. Spend can be capped per integration and every action is logged. The modules underneath are the ones you would expect from an ERP: contacts and CRM, inbox, documents, calendar, tasks, accounting with invoicing, bills, purchase invoices and multi-currency, deals, warehouse and stock, and a marketplace of apps.
Whether or not you choose it, run the sequence above against whatever you are shown. The question to keep asking is not which product has AI, since they all say they do, but who the product was built to be operated by.
Questions people ask
Is AI-native ERP the same as agentic ERP?
In practice, yes. AI-native and agent-native describe how the system was built; agentic describes what happens in it. All three phrases point at systems where an agent can operate the software under a person's permissions, as opposed to systems that added an assistant to screens built for people.
Does an AI-native ERP still have screens?
Yes. People use screens to look, review and decide, and to work directly when they prefer to. The difference is that screens are no longer the only way work can enter the system.
Can a traditional ERP become AI-native by adding an assistant?
Not by that alone. An assistant helps a person drive the existing screens and reaches only the features the vendor connected. Becoming AI-native means exposing every action as a permissioned tool over an open protocol, which is a rebuild of the interface layer rather than an add-on.
Is it safe to let an agent post transactions?
It is as safe as the enforcement underneath. Look for permissions checked on every call, a spend cap, and a log that records the agent's actions with the same detail as a person's. The agent should act with the authority of the person it represents and never more.
- Model Context Protocol specification: tools how tools are defined, listed and called, and the requirement that servers implement access controls
- Sois documentation: the workspace MCP server the endpoint, OAuth sign-in, role-filtered tool list and fail-closed behaviour described above
- Sois: security and the permission layer permissions enforced when tools are offered and when they run; spend caps; logging
This article is reviewed when the products it describes change. Next scheduled review: December 4, 2026.