AI Agents for Business: What Changes When the System Acts on the Record.
Search for AI agents for business and you get the same page ten times: a definition built on the word autonomous, a list of use cases, and a product. None of it tells an operator what an agent does on a Tuesday, what has to be true of the company before one is useful, or which jobs to hand over first. This is that page.
What an agent does, on a Tuesday.
Strip the vocabulary and an agent does three things. It reads records, often across more than one application. It compares what it reads to a goal it was given and chooses an action from a list it is allowed to take. Then it takes the action through the application's own interface, the same way a person would: it updates the field, creates the task, sends the email, tenders the load.
That third step is the one that separates an agent from everything that came before it. A report reads. A dashboard reads. A chatbot reads and answers. An agent reads and acts, and the action lands in the record where the business keeps its state. On Tuesday morning the agent moved four deals, reassigned nine leads and drafted twelve emails, and all of it is in the system, attributed, timestamped and reversible.
If the vendor's demo never shows the agent changing a record, it is showing you an assistant. Useful, but a different product.
The precondition nobody puts on the slide.
An agent is only as good as the records it reads and only as safe as the limits on what it changes. The first half of that sentence is the one that decides whether agents work in your company, and it has nothing to do with the model.
Consider the agent that chases overdue invoices. It reads the invoice in the accounting system, the deal in the sales system and the open tickets in the help desk, because an invoice should not be chased while a support ticket about that invoice is open. For that to work, all three systems must agree who the customer is. In most mid-market estates they do not. The customer is Lakeshore Foods in one system, Lakeshore Foods Inc in another, and a parent company name in the third, because finance typed it from the purchase order. We described the fix for reports in the piece on which system owns the customer; for an agent the same fix is not an improvement, it is a precondition.
An agent over disagreeing systems is worse than no agent. A report that joins on the wrong key produces a wrong number that a person can notice. An agent that joins on the wrong key chases the wrong customer, with complete confidence, at nine in the morning, and the first you hear of it is from the customer. The integration layer, one customer id, one order record, one item id across the systems, is the floor the agent stands on. Build the agent first and it stands on nothing.
One application or three.
Every agent demo we have seen runs inside one application. The agent reads a CRM record and updates a CRM field. That is where the vendors can show it, because that is where their product is, and it is genuinely useful: lead follow-up, data enrichment, drafting.
The money is in the agent that works across three. The reason is that the expensive problems in a mid-market company live at the boundaries between systems, not inside them. The quote that stops matching the invoice. The support promise the help desk cannot see because it lives in the sales contract. The stock count that disagrees between the storefront, the ledger and the warehouse. Inside any one application these are invisible, because each application is internally consistent. An agent that can only read one of them cannot see the problem, let alone act on it.
Nobody sells the three-application agent, because it requires the integration work first, and the integration work is not a product. It is a set of decisions about which system is the record for each thing, a one-time reconciliation of what already exists, and connections built in a known direction. That is the work we do, and it is why we treat the agent as the last layer of an integrated business solution rather than the first purchase.
The four jobs worth giving to an agent this year.
Not every process should become an agent. Most should stay as rules, because the next action is the same every time and a rule does that cheaply. The agentic candidates are the processes where the next action depends on reading the situation. In the companies we work with, four come up again and again.
Lead follow-up where the path varies. The contact has left, the email bounced, the company has a second contact in the account record. A rule emails the manager. An agent finds the second contact, drafts the introduction, and sets the task.
Collections with context. Chase the invoice unless a ticket is open about it, unless the deal is in renewal, unless the customer is on a payment plan. Each exception is a rule nobody wrote, and an agent reads them all from the records.
Carrier or vendor selection. A freight brokerage tendering a load, a manufacturer choosing which supplier gets the purchase order, a services firm assigning the next project. The choice depends on history, insurance expiry, lanes and price, all of which are in the records if the records agree.
Support triage against the contract. The ticket arrives; the agent reads the customer's tier from the sales system, the open deal, the past tickets, and routes and prioritises accordingly. This only works when the tier lives in one field synced one way, which is a decision most companies have not made.
Four jobs. In a company of eighty people that is the realistic list for a year, and it is enough to change how the company runs.
What governs it.
Three controls, and the middle one is the one almost nobody has configured. Permissions decide what the agent can see and touch. Approval rules decide which of its actions wait for a person: amounts, closing stages, bulk reassignment, customer email. The audit log records what it did, including what was held and what was rejected. In Zoho the approval process was built for people and governs an agent identically, because to the system a change is a change. We walk the three in the piece on governing agents in a mid-market company.
Write the limits before the agent is switched on. A rule added after the first surprise governs the next action; the one that prompted it is already in the log.
How to start without buying a demo.
The order matters more than the vendor. First, make the records agree: decide which system issues the customer id, carry it across, reconcile what exists once. Second, inventory the rules you already run and give each one an owner. Third, pick one of the four jobs, write its goal in one sentence with a limit in it, list the actions it may take, and write the approval rules for the ones that wait. Then switch it on, for one team, and read the log for a month.
That sequence is slower than the demo and faster than the rebuild you do after the demo goes wrong. Discovery is no-risk: we read your systems, tell you which of the four jobs your records can support today, and you pay only if you go ahead.
Find out what one connected Zoho system would change in the way you run.
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:
Comments