Build or buy: putting AI to work across your own systems

Plenty of companies already pay for an AI assistant — Claude, ChatGPT, Copilot — and find the same thing. It is very good at reasoning over what it is handed, and it has not been handed the business. The finance system, the CRM, the HR directory and the warehouse system are each a separate door with its own sign-in, and nothing about the assistant opens them.

So there are two ways forward. Build the layer between the model and your systems, with developers of your own, contractors or an agency. Or buy one. This is what each involves, as plainly as we can put it — including when building is the right call.

The model is not the hard part

A question like “sales are up, why is cash down?” touches the ledger, the CRM and the warehouse system. Before any reasoning happens, somebody has to decide which of those hold a piece of the answer, fetch it, check each was read as of a date that makes the comparison fair, notice where two systems count the same thing differently, remove what the person asking is not allowed to see, and keep enough of a record to prove the figure later.

The model does the last step well. The rest is the work, and a setup that simply points a model at your systems leaves it to a person, by hand, for every question.

What building it involves

A connection for every system

For each system: register an application with the vendor, write a client for its API, and handle its sign-in — which differs from vendor to vendor more than it should. Some issue a token that lasts. Some expire it within the hour and hand back a refresh token that changes every time it is used, so a connection that forgets to keep the new one works until the old one runs out. Some authorise on the customer’s own hostname rather than one front door. One sends back the company identifier on the redirect and nowhere else. None of it is hard once it is known; all of it has to be learned per vendor.

Keeping every connection working

Vendors change their APIs, and they do not wait for you. In 2026 alone, Xero retired its broad accounting scopes for new applications, so an app asking for them is refused before anybody can sign in; Linear moved every OAuth application to day-long tokens that rotate on every use; and Shopify stopped issuing lasting tokens to new public apps. Each of those breaks an integration that worked the week before.

The quieter failure is worse. A field the vendor renames does not raise an error — the integration keeps running and reports no invoices where there were hundreds. Somebody has to be watching for that, for as long as the integrations run.

Who may see what

The simplest build puts one set of credentials behind the model, which means everybody who asks gets the same answer — the new starter and the finance director alike. Per-person access means mapping each person to what they may read, and checking it on every request rather than only hiding it in the interface.

Figures that disagree, and figures you can prove

HR says 41 employees and payroll says 43, and both are reading their own records correctly (what the gap is made of). A model given both will choose one, or split the difference, unless something tells it which department owns the word. And when a figure is challenged later, the question is not what the model said it read; it is whether that record exists and says what the answer claims. That check has to be built too.

Who you need

Developers for the integration work — yours, contractors or an agency — and then somebody to own it after they have moved on to something else. That last part is the one most build plans leave out.

What it takes here

Connecting a system is one of two things. Either a button opens the system’s own sign-in, you approve read-only access, and the connection is checked with a real read before anything relies on it; or the card lists a few steps — usually creating a read-only key or app in the system’s admin settings — with every value we supply ready to copy and paste. Either way it is a job for an admin, not a developer, and nothing is installed.

A cloud account is a stack you approve in your own console, which creates a read-only role we may assume; a shared drive is scoped by picking folders in its own file browser.

Every connection is read-only, and asks for the narrowest access its vendor offers. No connector may ask for a write scope, and a test in the product holds every one of them to it.

Keeping the connectors working is ours. Every night, the API descriptions vendors publish are checked against what each of our connectors relies on — the calls it makes, the fields it reads, and any flag a vendor has set to say something is going away — and a change becomes ours to fix rather than a blank in your answer.

When building it yourself is the right call

Sometimes it is. If the question lives in one system and a data team already owns it, a direct connection may be all you need. If your data already sits in one warehouse with a reviewed semantic model, a BI tool with a question box over it can be the more auditable answer — and anything going into an audited statement belongs in a deterministic pipeline either way. And if what you want is for the AI to act in your systems — create, update, post — this is not that: every connection here reads, and nothing more.

It stops being the right call when a question needs three systems, two definitions and more than one person’s permissions. That is the problem this is built for.

You already have the model. What you are deciding is who does the work of handing it your business — for every question, every system, and every change the vendors make.

---

See what connecting a system looks like, then start on your own with a seven-day free trial — no credit card required.