Context
Many executives picture the ERP that took months to implement, the payroll system nobody wants to touch, and the spreadsheet that holds up half the operation. They conclude that installing an AI agent means changing all of that.
It does not. An agent is closer to a new colleague than to a new system. When you hire someone, you do not ask them to rebuild your software. You give them access to what already exists, explain how the work gets done, and supervise them at the start. The same goes for an agent, with one useful difference: you decide, as far as each system allows, what it can reach and what it can do in each place. Connecting may require setting up access in your current systems, such as turning on a connection or creating a user with permissions, but not rebuilding them.
The core idea
An agent does not need your software to be new. It needs an access route to the information and actions that already live in it. There are three routes, from the cleanest to the most improvised.
The first is a direct connection between programs. Many systems offer what is called an API, an official door through which another program can ask for data or ask for something to be done. Think of a bank teller window: it has clear rules, it leaves a record, and it does not depend on how the screen looks.
The second is files. Many companies exchange information through spreadsheets, PDF reports, or exports that someone downloads every morning. An agent can read those files and drop its own in an agreed folder. It is not elegant, but it works, and it is usually the realistic first step.
The third is operating the screen the way a person would. When a system offers no door and no export, the agent can open it, look at what is on screen, click, and type into fields. It covers cases that would otherwise be left out, but it is the most fragile route, because it depends on the screen looking the same as yesterday.
On top of all three sits a layer above: the agent's own work area, where it gathers what it reads from several systems, prepares its work, and keeps a record of what it did. Your systems stay exactly as they were. The layer is the new part, so it can be changed or removed without rebuilding anything else. Records the agent already wrote in your systems stay, which is why it matters that they are logged.
How it is done
First you map where each piece of data lives. For a bank reconciliation you need to know where the bank movements are, where invoices are recorded, and who approves differences. That map decides the route for each system: the most stable one available. The screen is the last resort.
Then come the permissions, which matter most to whoever runs the company. There are two levels.
- Read: the agent sees the information and works with it, but changes nothing in the system. Almost everything starts here.
- Write: the agent creates or changes records, such as entering an invoice or updating a status.
The practical rule is to allow read access only at first and open write access in steps, once its work has been reviewed and you trust it. What the agent reads is sent to the provider's model for processing, so you also decide what information you open to it. Even with write access, keep it narrow: it can create drafts but not approve them. It is the same logic as handing a new hire the office key before the check-signing authority.
Finally, everything is logged. Every query and every change is written down, so a person can review what the agent did and why. Agents make mistakes, like any colleague, and review is part of the design.
An illustrative case
Imagine a building materials distributor, invented for this example. Its administration manager, Lucía, spends the first days of every month matching customer payments against invoices. She works from the statement she downloads from the bank portal, the billing system, and a spreadsheet where she notes exceptions.
The bank offers a file export. The billing system has a direct connection. The spreadsheet sits in a shared folder. None of the three has to change.
The agent starts with read permission on everything. Each month it reads the bank file, looks up the open invoices, and proposes which payment belongs to which invoice. It leaves its work in a new sheet, separate from Lucía's. She reviews, fixes what does not add up, and remains the one who decides.
After several months of proposals without surprises, Lucía authorizes a very narrow write permission: the agent can mark an invoice as reconciled, but it cannot cancel one or change an amount, because the billing system in the example allows that level of detail. The reconciliation becomes a shorter review, and Lucía uses the time on collections, which always got pushed aside. Her role grows.
One day the bank changes its file format. The agent no longer understands the date column and flags it in its log instead of guessing. Someone adjusts the reading and work continues.
Takeaways
- An agent connects in three ways: a direct connection between programs, files, or operating the screen like a person. Use the most stable one you have.
- The layer above is the agent's work area. Your systems are not migrated. The layer can be removed without rebuilding them, although records the agent already wrote stay, which is why they are logged.
- Start with read permission and open write access in steps, always narrow and with a log of every change.
- When a system changes, something breaks. Ask how that change is detected and who fixes it. Also ask how fine-grained the permission controls of each system are.