The next ERP user may not be human

Every screen is a guess about who is looking

Consider what an ERP is from the side of its user. Behind the brand it is a set of tables and rules: customers, items, orders, invoices, stock movements, and the constraints that keep them consistent. In front of that sits the part most of the money was spent on: several thousand screens that present those tables to a person a few fields at a time, in an order a person can follow, with labels a person can read and buttons a person can find.

Each of those screens encodes a guess about who is on the other side. The guess is a person with a limited working memory, so the form is split into tabs. A person who reads left to right, so the important field goes top left. A person who can hold roughly seven things in mind, so the dashboard has six tiles. A person who will make typing mistakes, so there is validation on submit. A person who gets tired, so the common path has fewer clicks. All of this is good design for the user the designer had, and for four decades that user was the only one there was.

The consequence is that the interface is a lossy rendering of the data model for one kind of reader. The model knows an invoice has lines, a customer, a due date and a status; the screen shows the lines on one tab, the customer on another, and the status as a colour. Work that touches five records means five screens, and the person carries the thread between them in their head. That thread is most of what a business pays its administrative staff to hold.

The new user has tools, not hands

An AI agent operating a business system receives none of that. What it receives, when it connects over the Model Context Protocol, is the result of a request to list tools: for each one, a name, a description written for a model to read, a schema for its inputs, and optionally an annotation saying whether the tool only reads, whether it can destroy anything, and whether calling it twice is safe. The agent chooses a tool, calls it with typed arguments, reads the result, and chooses again. The protocol's own summary is that it is a standardised way to connect AI applications to external systems, the way a common port connects devices, and the major clients now speak it: Claude, ChatGPT, Cursor and VS Code among them.

Look at what this user does not need. It does not need the invoice split into tabs, because it can hold the whole record at once. It does not need the important field top left, because there is no left. It does not need six tiles, because it can ask for the number it wants. It does not get tired, and there are no clicks. Every concession that made the screen good for a person is, for this user, either irrelevant or an obstacle.

And look at what it needs instead, which the screen never provided. It needs the description of each action to be precise, because the description is the whole of its understanding. It needs the schema to be complete, because it cannot see an example. It needs to know which actions are safe to retry. It needs the result to say what happened and what it may do next. For this user the documentation is the interface, and naming is design: one broad tool with a two-line description is a worse product than the same capability as three tools with plain names and honest descriptions, whatever the screens above them look like.

The detour through the screen will not last

The first response to a new user is always to dress it as the old one. Robotic process automation did this for a decade: a bot logs in with a service account and drives the screens as if it had hands, finding the button by its selector or its coordinates. The current version gives a language model a screenshot and a cursor. Anthropic's computer use does exactly that, and its documentation is careful to say where it belongs: it exists for the cases where no tighter interface is available, it steers you to a browser tool when the work stays inside a page, and it asks for a person to confirm anything with meaningful real-world consequences, financial transactions included.

The costume is expensive to wear. A screen makes no promises to a machine, so every change made for the person breaks the automation pretending to be one. Every layer between the agent and the action, the screenshot, the guess at which pixel is the button, the typed text that may or may not have landed in the right field, is a place to be wrong, and a model is already a place to be wrong. Screen-driving is the bridge you build while the system underneath has nothing better, and the vendors of the bots say so themselves: they now describe the robot as an execution layer that an agent calls on for the systems that still need it.

What software has to become

If the argument so far holds, the shape of agent-native software follows from it, and it is more than an API on the side. Five properties have to be true at once.

• Every action is a tool. Not the dozen the vendor thought were safe, but the whole surface a person can reach through the screens: create, read, move, approve, send, reconcile. Anything less, and the agent has to fall back on the screen for the rest.
• Every call carries an identity. The agent acts as a specific person, through a normal sign-in, and the tools it is offered are filtered by that person's role before it ever sees them and checked again when they run. An agent with the run of the system is a design failure, not a feature.
• It asks by design. Some actions run; some hold for a person; some are refused outright. The protocol itself says there should always be a human in the loop able to deny a tool call, and the major clients ask before a write by default. The software has to make the categories explicit rather than hoping the model is polite.
• Spend has a ceiling. Where the system's own reasoning costs money, or where a tool commits money, there is a cap per connection that the system enforces and the model cannot talk its way past.
• The log is the product. Every call, its inputs and its result, under the identity that made it, reviewable in the same way a person's actions are. For an agent the audit trail is how trust is built, one week at a time.

A sixth property is less a requirement than a consequence. When work is done through tools, the record is kept as a by-product: the agent that invoices, chases and reconciles leaves behind exactly the invoice, the chaser and the reconciliation a person would have typed, without the typing. The screens survive, for looking, reviewing and deciding. They stop being the only place work can happen.

The objection worth taking seriously

The strongest objection concedes that agents can do the work and points out that they sometimes do it wrong, confidently, on a write. This is true, and the honest documentation says so: ChatGPT treats any tool without a read-only annotation as a write and requires confirmation by default; Claude asks for approval before invoking a tool from a custom connector and warns that a malicious server may carry hidden instructions. The clients are right to be cautious, and a business should be too.

But notice where the caution has to live. It cannot live in the model, which is the party that might be wrong. It has to live in the software, which is exactly where good software already put it for human users. Validation, permissions, approval thresholds, undo, audit: every one of those exists because the previous user also made mistakes, confidently, on a write. Agent-native software takes that old discipline seriously at every action rather than at the few the screen designer remembered, and applies it to a user that will call a hundred tools before lunch.

A second objection is determinism. Some work must produce the same output for the same input, provably, every time. That work should stay a fixed workflow, and the agent should call the workflow as a tool rather than improvising it. Judgement does not replace rules here; the system needs both, exposed to a user that can tell them apart.

Who builds it, and for whom

The last consequence is the one the entrepreneur should notice. If the user of the software can be an agent, so can the builder. A developer describes the app they want to an agent they already have, the agent builds it against a set of build tools, the developer validates it locally and publishes it, and from the first day every tool the app ships is available to every other agent on the platform. The business that installs it does not learn its screens; its staff bring the agent they already use and describe the outcome. That is the arrangement Sois is built around, offered here as one implementation of the argument rather than as its conclusion.

The conclusion is simpler. For forty years the question a software designer asked was what the person on the other side needs to see. The next user does not see. It reads a contract and calls what it is allowed to call, and it will do so on behalf of the same people the screens were built for. Software that treats that user as a first-class citizen will be operated fluently. Software that keeps the screen as its only door will still be operated, through a keyhole, by an agent wearing a costume, until its owners tire of the costume and move.

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