AI integration: connecting agents to the systems you have

The demo took an afternoon. An AI agent read a sample invoice, pulled out the supplier, amount and due date, and wrote them neatly into a table. Everyone in the meeting agreed: let’s do this for real.

Then came the questions nobody had asked in the demo. Where do the invoices actually arrive? Who has access to the ERP? Does the ERP have an API, and if it does, is it switched on in your licence? What happens when the agent can’t read a field? Where does the data go while the model reads it?

Three months later the model still works fine. The project is stuck on the second list.

The model is the easy part

Today’s language models are good enough for most business tasks. Reading a document, sorting an email, drafting a reply: you can test any of these in a chat window in five minutes, and it will mostly work.

What takes time is everything around it. The agent has to get its input from somewhere and put its output somewhere else. In a company with 20 to 300 employees that usually means an ERP that’s ten years old, a document management system nobody fully understands, a shared mailbox, a few Excel files that are more important than they should be, and maybe a database an external developer built in 2014.

AI integration is mostly the work of connecting to those. It’s unglamorous, and it decides whether the project ships.

Four ways to connect an agent

There’s no single right way. I usually go through these options in order and take the first one that works reliably.

APIs. If the system has a documented interface, use it. Most modern ERPs, CRMs and ticket systems do, though sometimes only in a higher licence tier or after someone asks the vendor to enable it. An API gives you clear permissions, structured data and a log of what happened. Check early whether it can do what you need: some APIs let you read everything and write almost nothing.

Mail as the interface. Underrated. Many processes already run through email: orders, invoices, supplier questions. The agent can read from a dedicated mailbox and reply to one, or send its result to the person who needs it. No changes to the core system, and everyone already knows how to check what happened. When there’s no API, this is often the fastest route.

File drops. A shared folder where documents land and the agent picks them up, or where the agent leaves a CSV that the ERP imports overnight. Old-fashioned and very robust. Many older systems have a perfectly good import function that nobody uses because filling the file by hand is tedious. The agent doesn’t mind.

RPA, as a last resort. Robotic process automation clicks through a user interface the way a person would. It works when nothing else does, for example with an old desktop application that has no interface and no import. But it breaks when a button moves, and it’s hard to see why it failed. I use it only when the other three are ruled out, and I plan for the maintenance from day one.

Often the answer is a mix. The invoice comes in by mail, the agent reads it, and the result goes into the ERP through its import folder. That’s fine. What matters is that every step is visible and can be checked.

EU hosting and GDPR from the start

The question “where does the data go?” belongs in the first conversation, not the last. Invoices contain names and bank details. Customer emails contain everything people choose to write in them. If the agent sends that to a model hosted somewhere outside the EU, you need a reason, a legal basis and an agreement that covers it.

The simpler path is to choose EU hosting from the beginning. The major model providers offer it, often through the large cloud platforms with data centres in Frankfurt, Stockholm or Dublin. Combine that with a data processing agreement, a clear rule about what gets logged and for how long, and a check that the agent only sees the data it needs for its task.

Sorting this out at the start costs a few days. Sorting it out after go-live, when your data protection officer reads the setup for the first time, costs a lot more. I wrote more about this in where your data goes when you use AI.

Test on real cases before go-live

A demo with five clean sample documents tells you almost nothing. Real invoices are crooked scans, two-page PDFs with the total on page two, and that one supplier who writes the due date in the email text instead of on the invoice.

So before the agent does anything on its own, run it on real cases. Take a few weeks of actual input, let the agent process it alongside the person who does the work today, and compare. Where does it agree? Where does it differ, and who was right? Which cases does it mark as uncertain, and should it?

This gives you two things. A realistic error rate, so you can decide where the agent needs a human check. And a set of test cases you can rerun every time something changes, whether that’s the prompt, the model or the supplier’s invoice layout.

Only then do you switch it on. Even after that, keep a log: what came in, what the agent decided, and what it wrote where. When something looks wrong in the ERP three weeks later, you want to find the cause in minutes.

Where to start

Pick one process where you already know the input and the destination. Find out early which of the four connection types is available: ask for API access, check the import functions, look at the mailbox. Settle hosting and data processing before you build. Then collect real cases to test with.

If you want help with that first process, my AI automation work starts exactly there: the systems you have, the data you’re allowed to use, and a test on your own cases before anything goes live.