Leave your system of record alone
You can add AI agents to existing software without replacing it, and in most cases you should. Your current system already holds the customers, orders and history that run the business, and it applies rules that people trust. Ripping it out to make room for an agent adds risk and cost before the agent has proved anything.
A better picture is a layer beside it. The agent reads from your software, reasons about the request and acts through the same controlled routes your staff use. The system of record stays authoritative. If the agent is switched off, the business carries on as it does today, which is a useful test of a sound design.
Three ways an agent can reach your software
The first and best way is an API, a published route that lets programs request and change data under rules the software enforces. Most modern tools have one. The second is a read-only view of the database or an export, good for answering questions but not for taking actions. The third is the screen itself, with the agent operating the interface like a person.
Prefer them in that order. An API gives structure, permissions and an audit trail. A read-only view cannot damage anything. The screen route is brittle, slow and easy to break when the layout changes, so treat it as a last resort. If your software has no usable API, building a small one is often the first real project.
- API: structured, permissioned and logged
- Read-only database view or export: safe for questions and reports
- Screen operation: the last resort when nothing else exists
Give the agent its own account and narrow permissions
Treat the agent as a new staff member with a very specific job. Create a dedicated account for it so every action is traceable, and grant only the access that job needs. If it drafts replies, it does not need permission to delete records. Where the software allows it, separate read access from write access and require approval for writes that matter.
Add limits around it: a spending cap on model usage, a cap on actions per hour, a list of things it must hand to a person, and a way to switch it off quickly. Keep secrets such as passwords and keys out of the agent's instructions, and log each request and result so you can reconstruct what happened.
Run it beside your staff before it acts
Before an agent touches live records, run it in shadow. It sees real requests and works out what it would do, but nothing it produces is used. Staff carry on as normal. Then compare its proposals with what your people actually did, and read every case where they differ. The gaps show you what to fix in its instructions, its access or your data.
Next, let it prepare work in a queue that a person approves. Only after that record looks sound should it perform narrow actions alone, starting with the cheapest to reverse. Keep sampling afterward, because behaviour can change when your business, your data or the underlying model changes. Widening its freedom should be a decision, not a drift.
What to fix in your software first
Agents expose weak spots that people quietly work around. Duplicate customer records, free-text fields that should be choices, undocumented rules and missing change history all make an agent less reliable. It is cheaper to tidy these before connecting than to debug a confused agent later. Settle ownership too: who maintains the connection, and who answers when something looks wrong.
A short review of your integrations, data quality and permissions will tell you how much groundwork is needed. Sometimes it is a modest cleanup. Sometimes it shows that a particular system is too fragile to connect, and some modernization comes first. Either way, you learn this before the agent does anything with live data.
- Duplicate or conflicting customer records
- Free-text fields that should be fixed choices
- Business rules that live only in someone's head
- No change history or audit trail
- Missing or poorly documented API
Where agent-ready software is heading
Some software vendors are publishing cleaner APIs and finer permission controls with agents in mind, and tools for testing and monitoring agents keep improving. That may make connecting easier. It will not remove the groundwork: sound data, narrow permissions and honest trials still decide whether an agent helps or causes harm. Build those habits now, and the choice of tool matters less.
- 01Cleaner APIs and finer permission controls from software vendors
- 02Better tools for testing and monitoring agent behaviour
- 03Agents that call your existing business rules instead of copying them
Questions & answers
Usually, yes. The agent works through your software's API, a read-only view or, as a last resort, its screens, while the system itself stays untouched. Feasibility depends on whether there is a safe way in, how clean your data is, and how narrowly you can limit permissions.
An API is the best route, but not the only one. Without it you can use read-only exports for questions or screen operation for simple tasks, though both are less reliable. If the job matters, building a small API around the system is often worth doing first.
Give it its own account with the least access that works, separate read from write, and require approval for writes that matter. Log every action, set limits on how much it can do, and test against a copy of your data before it touches live records.
There is no fixed length. Run it in shadow until its proposals match your staff's decisions on realistic cases, including awkward ones. Then let it act on low-risk items first. Keep reviewing samples afterward, and pull it back to approval mode if quality slips.
