Best agentic ERP software: what to look for

Why there is no ranking here

Picture the shortlist. Four vendors, four proposals, and the word agentic on every cover. One is an established suite with an assistant added last year. One is a newer product built around its own agent. One is a platform that lets any agent connect over an open protocol. One is a workflow tool with a language model in the middle. All four demo well. Two of them will still expect a person at the screen for anything that crosses a module boundary, and you will not find out which two from the proposals.

A ranked list cannot help with that, for a reason that has nothing to do with the quality of the products. Agentic is a property of architecture, and whether a given architecture is right for you depends on which modules you run, which agent your team already uses, what your approval thresholds are and how much you need to see in the log. Those are your facts, not a reviewer's. What travels between businesses is the set of tests, so this page gives you the tests and asks you to do the ranking.

Test 1: open protocol, your agent from outside

The first test is whether an agent that the vendor did not build can operate the system. The open standard for this is the Model Context Protocol, which the mainstream agent clients speak: Claude adds a remote MCP server as a custom connector with an OAuth sign-in; ChatGPT does the same in developer mode with full read and write support; coding agents and internal agents built on the vendor SDKs connect the same way. A product that speaks MCP can be operated by any of them. A product that only works with its own assistant can be operated by nobody else, and that decision has been made for you.

The evidence to ask for is the server's answer to a tools/list request, which under the protocol is the machine-readable list of everything the agent can do. It should look something like this, repeated for every action in the system.

{
  "tools": [
    {
      "name": "contacts.search",
      "description": "Find contacts by name, email or company.",
      "inputSchema": { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] }
    },
    {
      "name": "invoices.create",
      "description": "Create a draft invoice from billable lines. Fails if the caller cannot raise invoices.",
      "inputSchema": { "type": "object", "properties": { "customer_id": { "type": "string" }, "lines": { "type": "array" } }, "required": ["customer_id", "lines"] }
    },
    {
      "name": "purchase_orders.approve",
      "description": "Approve a purchase order within the caller's approval limit.",
      "inputSchema": { "type": "object", "properties": { "purchase_order_id": { "type": "string" } }, "required": ["purchase_order_id"] }
    }
  ]
}

An illustrative tools/list response in the shape the MCP specification defines. Names and coverage will differ by product; what matters is that the list exists, is typed, and is long enough to cover the modules you use.

Three things to check in the list. It is long, because an ERP has hundreds of actions and a list of twenty means the assistant reaches twenty features. It is typed, with a JSON schema for every input, because that is what lets the server validate calls rather than interpret prose. And it changes when a more restricted user signs in, which is the bridge to the second test.

Test 2: per-user permissions on every call

An agent that can do more than the person it represents is a liability, not a feature. The second test is whether permissions are enforced per user and per call, not per product or per session. The protocol allows a server to vary the tool list by the authorisation presented and requires servers to implement proper access controls, but it cannot enforce either on the vendor's behalf. The good implementations filter the list before the agent sees it and then check again when each tool runs, because a filtered list is a courtesy and an execution-time check is a control.

The evidence is a live refusal. Sign in as a user who cannot approve purchase orders, ask their agent to approve one, and watch what happens. The right answer is a plain refusal at the point of the call, logged, with the rest of the request still completing. The wrong answers are an approval that goes through, an error that leaks what the tool would have done, or a session that fails open because the check was only on the screen.

Test 3: budget and cost transparency

An agent that reasons on the vendor's models consumes something every time it runs, and the third test is whether you can cap that spend and see where it went. The specific mechanism matters less than the two properties: a limit set per integration or per key that the agent cannot exceed, and a per-action record of what each run cost. A product that can only tell you the monthly total after the fact has not built the meter, and you will find that out when a runaway loop or a keen new user hits the bill.

There is a second cost question that ranking pages skip entirely. If the product lets you bring your own agent, then when that agent does the reasoning the vendor may perform no AI on your behalf at all, and charge nothing for it. For a team that already pays for Claude or ChatGPT, that turns agent cost into a line you control rather than a line the vendor sets. Ask each vendor what they charge when your own agent does the thinking, and write the answer down.

Test 4: audit that reads like a person's log

When an agent does the work, the log becomes the primary way a manager reviews it, so the fourth test is whether the audit trail records the agent's actions as fully as a person's. The minimum is who asked, which agent acted on their behalf, which tools ran, with what inputs, with what result, and when. The protocol's own guidance is that clients should log tool usage for audit; the server should be doing the same from its side, because it is the server that knows what actually changed.

The evidence is the log itself, after the demo request. Open it and check for four things: attribution to a person, not to a generic integration user; the tool call sequence, not only the records that ended up changed; inputs and results, so a wrong action can be traced to a wrong input; and refusals, because a permission model that does not log its denials cannot be tuned.

Test 5: a marketplace, and what it tells you

The fifth test is indirect but revealing. If a platform has a marketplace of apps built by people other than the vendor, and those apps are operated by agents through the same tool interface as the core modules, then the tool interface is real, documented and stable enough for outsiders to build on. A marketplace is the vendor's own architecture being tested by strangers every day. It also answers the practical question of what happens when you need a capability the core product lacks: whether you wait for the roadmap, pay for custom work, or install something that already exists.

The evidence is a published app from a third party, installed into your trial workspace, appearing in the agent's tool list on the next request. If the marketplace exists but the apps are all the vendor's own, or if installing one does not change what the agent can do, the test is only half passed.

The scorecard

Take this into every demo and fill it in on the day. Score each test as passed, partial or failed, and insist on seeing the evidence rather than hearing about it. A product that fails the first test is a product with an assistant, whatever the cover says, and the other four tests become academic.

Sois is one implementation you can run these tests against, and since we build it we can say how it answers. 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. Tools are filtered by the user's role before they are offered and checked again when they run, and access fails closed. Spend can be capped per integration, every action is logged, and when your own agent does the reasoning the platform performs no AI on your behalf and charges nothing for it. Developers build apps with their own agent, validate locally for free and publish to a marketplace where every connected agent can call them. Run the same five tests against it as against everyone else; that is what they are for.

Questions people ask

This article is reviewed when the products it describes change. Next scheduled review: 4 December 2026.