Yes. An AI agent can run the day-to-day work of an ERP today: raise and send invoices, chase what is unpaid, book purchase orders, receive stock, reconcile payments, keep customer records current and schedule the follow-ups, across modules and without a person at the screen. Three conditions have to hold. The ERP must expose its actions as tools an agent can call. Each call must be checked against the permissions of the person the agent represents. And the agent must be allowed to connect, whether it is the vendor's or one you already use.
Where it stops is just as definite. An agent cannot do more than its user is allowed to do, so approval thresholds hold. It will pause on ambiguity rather than guess. It does not replace the judgement calls that were never routine in the first place. A well-built system makes those limits structural rather than a matter of trusting the model.
Yes, within three conditions
The question can AI run an ERP gets asked with two different worries behind it. One is whether the models are capable enough, and the answer to that is now settled for routine operational work: a frontier model given a clear outcome and a set of typed tools will plan the steps, call them in order, read what comes back and recover when something is missing. The other worry is whether it is safe to let it, and that depends entirely on the system it is connected to.
The first condition is that the ERP has tools. Not a chat box beside the screens, but a defined list of actions with names, typed inputs and results that an agent can discover and call. The open standard for this is the Model Context Protocol, which the major agent clients now speak; a business system that publishes its actions as MCP tools can be operated by any of them.
The second condition is that every call is permissioned. The agent connects as a specific person and can only be offered, and can only run, what that person is allowed to do. The protocol explicitly allows the tool list to vary with the authorisation presented, and its specification requires servers to implement access controls and validate every input. The systems worth trusting check at both points, when the tools are offered and again when each one runs.
The third condition is that the agent can connect at all. Some products let only their own built-in assistant act, and that assistant reaches only the features the vendor chose. If the agent your team already uses cannot be pointed at the system, then whether AI can run it is a question the vendor has answered for you.
What running it looks like
The clearest way to answer the question is to watch one request go through. Acme Ltd has been a customer for a while, the September work is complete, and the owner wants it invoiced, sent to the contact, and chased if it is not paid in a fortnight. Here is that request as it runs in a Sois workspace with the owner's own agent connected.
- Reading the project's billable work and the customer record
- Invoice created from the billable lines
- Sent to the customer contact by email
- Follow-up scheduled for the due date
Four tools across accounting, contacts, inbox and tasks. Nobody opened a form.
The owner did not find the project, build the invoice, export it, attach it and create a reminder. They described the result. The invoice, the email and the task exist in the system afterwards exactly as if they had. On the day the reminder falls due, the same agent can check whether payment arrived and send the chaser, and the log shows both runs with their inputs and results.
What the agent actually calls
It helps to see the shape of the thing being called, because it is not magic and it is not screen-scraping. Under MCP a server answers a tools/list request with definitions like the one below. This example follows the specification's format and naming rules; the names a given product uses will differ, and a real list runs to hundreds of entries across an ERP's modules.
{
"name": "invoices.create",
"title": "Create an invoice",
"description": "Create a draft invoice for a customer from billable lines. Fails if the caller cannot raise invoices.",
"inputSchema": {
"type": "object",
"properties": {
"customer_id": { "type": "string" },
"lines": {
"type": "array",
"items": {
"type": "object",
"properties": {
"description": { "type": "string" },
"quantity": { "type": "number" },
"unit_amount": { "type": "number" }
},
"required": ["description", "quantity", "unit_amount"]
}
},
"due_date": { "type": "string", "format": "date" }
},
"required": ["customer_id", "lines"]
}
}An illustrative MCP tool definition in the shape the specification defines: a name, a description, and a JSON schema for inputs. The agent reads this, decides when to use it, and calls it with arguments.
Three details in that definition carry most of the safety. The description says what happens when the caller is not allowed, so the model knows a refusal is possible. The input schema is typed, so the server can validate every call rather than parsing prose. And the tool creates a draft rather than a sent invoice, which is a design choice a good ERP makes deliberately: separate the reversible step from the irreversible one, so a person or a policy can sit between them where the business wants it.
Where it stops
An honest answer draws the line clearly. The table lists the common month-end and operational tasks, whether an agent can run them, and what stops it when it cannot.
| Task | Can an agent run it? | What stops it, or where it hands back |
|---|---|---|
| Raise and send routine invoices | Yes | Nothing, within the user's permissions; a customer with two matching records prompts a question |
| Chase unpaid invoices on a schedule | Yes | A dispute on the record; the agent flags it instead of chasing |
| Book purchase orders from an accepted quote | Yes, up to the user's approval limit | An order above the limit is drafted and routed for approval, not placed |
| Receive stock and update levels | Yes | A quantity mismatch against the order is reported, not silently corrected |
| Match supplier invoices to receipts | Yes, within tolerance | Out-of-tolerance matches are left for a person |
| Reconcile bank payments | Yes for clear matches | Ambiguous or partial payments are listed for review |
| Approve a credit note or write-off | Only if the user can | Authority is the user's, and the agent has no more of it |
| Decide whether to keep a difficult customer | No | Judgement that was never routine; the agent can assemble the history |
The pattern in the right-hand column is the point: the agent runs the policy and escalates the exceptions.
The clients that can do this today
Because the connection runs over an open protocol, the agent doing the running can be one you already pay for. Claude supports custom connectors to remote MCP servers on its Free, Pro, Max, Team and Enterprise plans: you add the server's URL, sign in over OAuth, and approve tool calls as they come, with an option to allow a trusted tool to run unsupervised. ChatGPT's developer mode provides full MCP client support for read and write tools on its Pro, Plus, Business, Enterprise and Education plans on the web, with write actions requiring confirmation by default. Developers building their own agents on OpenAI's Responses API can point it at a remote MCP server, restrict which tools it imports, and decide per tool whether approval is required.
All three vendors say the same thing about trust, and it is worth repeating: connect only to servers you trust, because a malicious server can read whatever enters the model's context. For an ERP that means the workspace you connect should be one whose permission layer you have checked, not one you found by searching.
How to start without betting the business
The safe way to answer the question for your own operation is to let an agent run one corner of it. Sois is one implementation of the system described above: a workspace is an MCP server at an address you paste into any compatible client, sign-in is a single OAuth step with no token to copy, tools are filtered by the user's role before they are offered and checked again when they run, access fails closed, spend can be capped per integration, and every action is logged. When your own agent does the reasoning the platform performs no AI on your behalf and charges nothing for it.
- Launch a workspaceFree to start. Bring in one part of the operation, often invoicing and chasing, or the inbox.
- Connect your agentPaste the workspace address into Claude, ChatGPT or another MCP client and sign in once.
- Hand it one jobSomething routine and reviewable. Month-end invoicing is a good first job because the exceptions are obvious.
- Read the log, then widenCorrect what needs correcting, raise the agent's user to the right permission level, and add the next job.
After a month of that, the question stops being whether AI can run an ERP and becomes which jobs you have not handed over yet.
Questions people ask
Can an AI agent run an ERP completely on its own?
It can run the routine work end to end, within the permissions of the person it acts for. It cannot approve beyond that person's authority, and it should pause on ambiguity. Judgement calls that were never routine stay with people, though the agent can assemble the record for them.
Which AI agents can operate an ERP today?
Any client that speaks the Model Context Protocol against an ERP that exposes its actions as MCP tools. That includes Claude through custom connectors, ChatGPT through developer mode, and agents built on the OpenAI Responses API, as well as Cursor, VS Code and other MCP clients.
What stops the agent from doing something it should not?
The permission layer. The agent connects as a specific person, is offered only that person's tools, and each call is checked again when it runs. A spend cap limits cost, and the log records every call with its inputs and result. Client-side approval prompts add a further human check on writes.
Do I need a developer to connect an agent to an ERP?
Not for a system that speaks MCP. Adding a custom connector to Claude or a developer-mode connector to ChatGPT is a matter of pasting a URL and signing in. A developer is only needed if the ERP does not expose tools and something has to be built around it.
- Model Context Protocol specification: tools tool definitions and naming, tool lists that vary by authorisation, and the security requirements on servers and clients
- Anthropic: getting started with custom connectors using remote MCP plans, adding a server URL, OAuth, tool approval and trust guidance
- OpenAI: ChatGPT developer mode and remote MCP in the Responses API full MCP client support, write actions requiring confirmation, plans; the Responses API guide covers allowed_tools and require_approval
- Sois documentation: the workspace MCP server the endpoint, OAuth sign-in, role-filtered tool list, fail-closed execution and budget caps
This article is reviewed when the products it describes change. Next scheduled review: 4 December 2026.