AI-powered ERP vs agentic ERP: what is actually different

Two demos that looked the same

A common experience for anyone buying ERP this year: two vendors, two hour-long demos, both describing their product as AI-powered, agentic, or both. In each demo a presenter types a request, the system produces something sensible, and the room nods. On the way out the buyer cannot say what the difference was, and the shortlist gets decided on price and familiarity.

The difference was there. It was hidden by the way demos are run. In the first demo the presenter was at the screen the whole time, and every suggestion the system made was accepted by a click. In the second the presenter could have left the room after typing the request. That is the whole distinction, and once you know to look for it you cannot unsee it.

A copilot suggests; an agent completes

A copilot lives inside a screen. Its job is to make the person at that screen faster: summarise this customer, draft a reply to that email, fill these three fields from the attached quote, tell me which invoices are overdue. It is genuinely useful and, for a surprising amount of daily work, it is what people want. Its limit is structural. It can only reach the features the vendor connected it to, it cannot move between modules on its own, and it never clicks Save. The person does.

An agent lives outside the screen. It receives an outcome to achieve, discovers what it is allowed to do, plans a sequence, calls the tools, handles what comes back, and reports. It moves across modules because the tools it calls are not tied to screens. It completes the work because completing is what it was given permission to do. It stops and asks when something is ambiguous or above its user's authority, not because it needs a click to proceed.

The test: can it act with nobody at the screen?

Slides cannot answer that question; only a live request can. Run the following against any product that claims either label. It takes an hour and does not require a developer.

1. Choose one outcomeSomething routine, cross-module and reviewable. Invoice a customer for last month's work, send it, and schedule a reminder if it is unpaid in two weeks is a good one because it touches billing, contacts, email and tasks.
2. Bring your own agentConnect the agent you already use from outside the vendor's product, over MCP. If the vendor cannot support that, note it and use their agent; the answer to the protocol question is already in.
3. State the outcome onceType the request, then take your hands off. No clarifying clicks unless the system asks a genuine question, such as which of two matching customers you meant.
4. Check the resultOpen the invoice, the sent email and the reminder in the system. Then sign in as a more restricted user and repeat. The agent should be refused where that user would be refused.
5. Read the logLook for who asked, which agent acted, which tools ran and with what inputs. A log as detailed as a person's is the mark of a system that treats the agent as a user.

Two outcomes are common. The copilot completes part of the request and returns control to the person for the rest, usually at the point where a module boundary or a Save is involved. The agent finishes it, and the only evidence that a machine did the work is the log. There is a third outcome worth naming: the vendor's own agent finishes the job but nothing from outside can connect. That is an agentic product with a closed door, and the door will matter when your team's agent is the one they want to use.

What has to be true underneath

For the agent column to be real rather than a demo script, three things have to be built into the product, and all three can be checked.

• Every action is a tool with a definition. The Model Context Protocol, the open standard the major agent clients now speak, defines a tool as a name, a description, a JSON schema for its inputs and optionally one for its outputs. A system that has done this work can hand an agent a machine-readable list of what it can do. One that has not can only show it a chat box.
• The list is filtered by who is asking. The protocol allows the set of tools returned to vary with the authorisation presented, so a restricted user's agent is offered fewer tools. The good implementations then check again when each tool runs, because a filtered list is a courtesy and an execution-time check is a control.
• The client can be yours. Claude supports custom connectors to remote MCP servers across its plans, with an OAuth sign-in and per-tool approval that you can relax for servers you trust. ChatGPT's developer mode offers full MCP client support for read and write tools on its paid web plans, with write actions requiring confirmation by default. Both vendors tell users plainly to connect only to servers they trust. A system that can be operated by either of those clients has passed the protocol test.

Where the copilot is genuinely better

It would be convenient to say the agent wins everywhere, and it would be wrong. A copilot is the better tool when the person wants to stay at the screen: exploring the data, deciding what to do next, editing a document line by line, or doing work that is one-off and needs judgement at every step. A copilot that sits next to the form and answers questions about what is on it is a good design for that, and a system built for agents should include one, because agents do not replace looking.

The copilot is also better when the organisation is not ready to trust delegated action. Some teams want a period where the AI proposes and a person disposes, on every item, before anything runs unattended. That is a reasonable stance and a copilot delivers it. The point is to know which one you are buying, and not to pay for the agent column while getting the copilot column.

There is a cost dimension too, and it cuts both ways. A copilot inside the vendor's product runs on the vendor's AI, and you pay for that as part of the subscription or by usage. An agentic system that lets you bring your own agent can perform no AI on your behalf at all: your agent does the reasoning, and the platform charges only for what it stores and does. For a team already paying for Claude or ChatGPT that changes the arithmetic, and it is worth putting on the comparison sheet next to the licence fee.

What it looks like when the agent version runs

Sois is built on the agent side of this comparison, so it is the implementation we can show. A workspace is an MCP server. Any compatible client connects by adding the workspace address and signing in once over OAuth. Tools are filtered by the user's role before they are offered and checked again when they run, and access fails closed. Here is the test outcome from the flow above, as it runs.

Run the same request as a user who cannot raise invoices and the agent is refused at the first write, with a plain explanation, because a granted connection can never do more than the person behind it. Cap the spend on the integration and the agent stops when the budget is reached rather than running on. Open the log and every call is there with its inputs and result. None of that is special to the demo; it is how the permission layer treats every caller.

When you compare AI-powered ERP vs agentic ERP, ignore the labels on the slide. Ask for the outcome, step back from the screen, and see who finishes the work.

Questions people ask

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