The sales conversation goes like this. You ask the ERP vendor about agents. The vendor says the agents are in the new version, which is the suite you have not bought, and the agents will be wonderful once your inventory, your books and your orders are all inside it. The implied price of an agent is a two-year replacement of the systems that currently run the company.
That is the wrong price, and most of the time it is the wrong project. An agent is a layer that sits over the systems you run. It needs four things from each of them, and the systems you already have mostly provide all four. The question is not which platform to buy. It is which connections to make.
Strip the marketing off and an agent is a program that reads records, decides within rules, writes records, and explains itself. For each system it touches, that means four things.
A read. The agent must be able to fetch the records it reasons from: the account, the open orders, the stock position, the last invoices. Every system built in the last fifteen years exposes a read, and most of the older ones export one.
A write. The agent must be able to change a record, create one, or propose a change for a person to accept. This is the one vendors imply only their suite has. It is also the one every CRM, help desk, books package and warehouse system has had for years, because the integrators needed it before the agents did.
An identity. The agent must act as someone, with that someone's permissions, so that what it can see and change is bounded by a rule a person set rather than by what the code happens to try. We wrote up how one connector handles this in the Zoho MCP server permission model: the agent inherits the permissions of the user it runs as, and that is the whole safety model, not a feature.
A trail. Every change the agent makes must be visible afterwards, with the reason, so that a person can audit it and undo it. Most systems keep a modification history; the agent layer has to keep the reason beside it.
Read, write, identity, trail. If a system has those four, an agent can sit over it. If it has three, the fourth is usually a small piece of work. If it has none, the system is a spreadsheet, and the fix is not a new ERP either.
The suite argument is that agents work best when everything is in one place, because then the agent has one read, one write, one identity and one trail. That is true, and it is also true of every integration argument ever made, and it has never been enough reason for a company that works to replace the systems that make it work.
The cost side is the part the deck omits. Replacing an ERP in a 50-to-500-person company is a year to two years of the finance and operations team's attention, a migration in which the counts diverge, and a cutover that lands on a quarter end. We priced the parts of that nobody quotes in what an ERP migration actually costs. During those two years there is no agent, because the records it would act on are in flight. At the end, the systems the suite did not absorb, the one the warehouse insists on, the one the industry requires, the one a customer mandates, are still outside, and the agent still needs the layer to reach them.
So the suite pitch buys a two-year delay in order to reduce the number of connections from four to two. The layer over what you run makes the four connections now.
Here is what a real estate looks like at this size. Zoho CRM for the pipeline, or Salesforce, or HubSpot. QuickBooks or Xero or an ERP's finance module for the books. A warehouse, manufacturing or field service system chosen by the people who use it, often industry-specific and often older than everything else. A help desk. Payroll somewhere separate. Two or three spreadsheets that are secretly systems.
Nobody designed it, and nobody is going to redesign it, because each piece was chosen by the people whose work it holds and each one works. The agent layer has to accept that estate as given. Its job is to sit over it, read across it, act within each system's permissions, and leave a trail in each.
The hard part of the layer is not the model. It is agreeing which system owns which record, so that the agent knows where to read the truth and where it is allowed to write. We laid that out for the two systems that disagree most in ERP versus CRM, and what each system is the record for, and for the one record every agent reads first in which system owns the customer. Settle those and the layer has a map. Skip them and the agent reads the CRM's version of the customer, writes the books' version, and the two disagree by the end of the week.
Platform-agnostic is a phrase vendors use to mean their platform connects to yours. For an operator it should mean something narrower and more useful: the agent layer does not care which systems are underneath it, only that each one provides the four things, and the company does not have to replace a working system to get an agent over it.
In practice that means the layer is built from the connectors each system already exposes, with the identity and trail added where a system is thin on them. It means the agent's boundary is set per system, so the agent may draft in the CRM, propose in the books and only read in the warehouse, if that is the trust the company has today. And it means the estate can change underneath the layer, a system replaced when its time comes, without the agent being rebuilt.
The test to put to any agent vendor is the same test. Which of my systems must I replace to use this? If the answer is any of them, the vendor is selling a platform, not an agent.
Start with the connection, not the agent. Pick the one record that crosses the most systems, almost always the customer, and make the four things true for it in each system: readable, writable, under an identity, with a trail. Then give the agent one job on that record that is useful and easy to check, and widen the boundary as the trail earns trust.
This is the work we run as a managed subscription: the connections, the identities, the boundary and the trail, over whatever the company runs, with one party accountable for whether the agent's actions were right. Discovery is no-risk: we map which of your systems already provide the four things and which need work, and you pay only if you go ahead.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
