Artificial intelligence

Plugging AI into what you already have

These projects fail on the connection, not the model. What to inventory before signing, and where to put the seam.

Published on 24 July 2026 — Algeria Agency

The demo always works. It works because it crosses none of your systems: the data in it is clean, available and already in the right format, which describes exactly the situation you are not in.

At your end, the useful data sits in a till that exposes nothing, in a file somebody exports on Monday, and in an application whose publisher no longer answers. That is where these projects die, and it is knowable before committing a single dinar.

This article describes the inventory that reveals it, what to do when a system is closed, and where to put the seam so the AI supplier stays replaceable — because it will change its price, its catalogue or its availability during the life of your project.

The model is never the problem

It is worth saying plainly where the time goes in these projects. Choosing the model takes a day and can be revised in an hour; the question "how do we get that customer list, up to date" takes weeks and is revised by redoing everything.

The reason is that models have become interchangeable for the large majority of business uses, while management systems have stayed as heterogeneous as ever. Two shops in the same trade have the same need and two installations with nothing in common.

The consequence is an unusual order of work: look at the systems first and the model last. A supplier who opens by telling you which model they picked is telling you about the part of the project that causes the fewest problems.

There is a quick way to check that claim against your own project. Ask the supplier how many days go to choosing the model and how many to getting at the data, and compare the two numbers with what you have just read. A quote where the second line is shorter than the first describes a project that has not yet looked at your systems.

The inventory before the quote

The inventory answers four questions per system: what comes out, by what means, how often, and what state the data is in. It requires no privileged access, it requires half a day with the person who uses the system daily.

It produces a short, cold document: what can be connected, what can only be connected at the price of a periodic export, and what cannot be connected at all. That page decides the project, and it sometimes decides there will not be one.

We bill that stage on its own and the document stays yours, including if you stop there or take it to somebody else. That is deliberate: an inventory whose answer is "no" is worth as much as one that opens a build, and it has to be deliverable without the supplier losing by it.

The inventory also raises a question projects skip systematically: who is entitled to grant access. In many businesses the administrator password for the management application belongs to somebody who is neither in the meeting nor aware of the project, and sometimes to an external supplier who is hard to reach. Spotting that at the start costs one question; discovering it midway costs several weeks.

What comes out of an application, and how

There are three cases and they do not cost the same. First: the application exposes a documented programming interface. That is the comfortable case, the data is available on demand and current, and the integration is built against a stable contract.

Second: the application exposes nothing but can export — a file, a backup, a printable report. The data is then available with a delay equal to the export frequency, and you have to decide whether that delay suits the use. For an assistant answering stock questions, a daily export is usually unacceptable; for a monthly dashboard it is perfect.

Third: the application does neither. That is the case where you stop and ask the question differently, because the workarounds available at that point are all bad and durably so.

The second case deserves a qualification that often changes the decision: the export frequency is not always the one the application offers. Many applications that export once a day can export on demand if somebody runs the command, and a scheduled task does the rest. The gap between ‘once a day’ and ‘every hour’ is enough to make an otherwise excluded use acceptable.

The till that exposes nothing

Part of the locally installed estate consists of older desktop applications, sometimes undocumented, sometimes with no publisher still reachable. That is not a criticism: those applications do the job they were bought for, and have done it for ten years without incident.

They are simply systems designed before anybody expected software to talk to other software. They record correctly, they print correctly, and they never had a reason to expose anything outward.

We have no figure to cite for what proportion of the Algerian estate that represents. We meet the case regularly, we know of no dated survey of the installed base here, and a statistic imported from another market would describe a different estate — we would rather describe what we see and present it as that than dress an impression up as a percentage.

This case has an outcome worth not dismissing too fast: ask the publisher. Where one still exists, they sometimes have an export module or an undocumented interface supplied on request, and the cost of a letter is nothing beside the cost of a workaround. That step is rarely tried because it is slow; it is also the only one that leaves the system under warranty.

The layer you own

The architectural decision that matters fits in one sentence: the model is called behind an interface that belongs to you, never directly from your application. One place in the code decides which supplier answers.

The cost of that precaution at design time is close to zero — a few hours — and its cost if added later is a rewrite. It is the kind of decision made only at the start and regretted exactly once.

It looks theoretical until the first real event: a supplier multiplying its prices, withdrawing a model from the catalogue at short notice, or becoming unreachable from Algeria. None of those three is hypothetical and none of them is predictable.

The layer has a second benefit only measurable afterwards: it makes the cost visible. Since every call passes through one place, you can count how many there are, which are expensive, and which are pointless. Without it the invoice arrives as one total and nobody knows which part of the application produced it, which makes any optimisation impossible to target.

The supplier behind it

The replacement also has to be verified, not merely possible. A supplier who claims the provider is interchangeable should demonstrate it during the project: switch to another model, run the test set, and show you the result.

That test takes half a day and turns an architectural promise into an observed fact. If it is refused or deferred, the abstraction probably exists on paper rather than in the code.

There is a variant of that test costing even less, and it can be asked in a meeting: have them name the file or module where the choice of provider is written. If the answer is one specific place, the abstraction exists. If the answer starts with ‘it depends’, the provider's name is probably scattered through the code, and the replacement announced as simple will be a rebuild.

What happens when it does not answer

A remote interface does not always answer. It happens for mundane reasons — maintenance, saturation, a rate limit reached — and the question is not how to avoid it but what your system does meanwhile.

There are three acceptable behaviours and one has to be chosen explicitly: queue and process later, degrade while announcing the degradation, or stop cleanly and say so. The unacceptable behaviour is the one you get by default: a technical error page in front of a customer, or worse, a silence that looks like an answer.

That choice is made at scoping and takes ten minutes. It is almost always skipped, because it concerns an event that has not happened yet and nothing in a demo makes it visible.

The most insidious case is not the absent answer but the slow one. An interface answering in thirty seconds instead of one is not down, so nothing fires, and yet the application becomes unusable for whoever is waiting. A maximum delay past which the call is abandoned has to be set explicitly, otherwise the user applies it by closing the page.

What leaves the country, field by field

Sending a request to a foreign service means sending data. Which data exactly is a question to handle field by field rather than wholesale, because the answer is almost never "all of it".

To classify an incoming message, the model needs the text of the message. It does not need the phone number, the name, the address or the purchase history, and sending them because they happened to be on the same record is a common and avoidable negligence.

Good practice is an explicit list of transmitted fields, approved by you, and a mechanism that refuses anything not on it. What is excluded is then handled by local rules or not handled, and that decision is yours rather than the consequence of a technical choice nobody showed you.

There is a simple and under-used technique: substitute before sending. An order number becomes an internal identifier, a name becomes a token, and the mapping stays with you. The model works on text with the same meaning and no personal data, and the answer is reassembled on return. It is not always possible, and where it is it settles the question without removing anything from the service.

The test environment

You need somewhere to check a change before it touches production, with data resembling yours. Without it, every change is a bet placed on a live system, and bets are lost on the day there are people about.

It is the first thing cut when the budget tightens, and the cut is paid for later with interest. A test copy costs little to set up at the start of a project and becomes impossible to add once the integration is live and nobody wants to touch it.

A qualification about test data: it should resemble yours without being yours. Copying the production database into a less protected environment is a common practice and a bad idea, because the test environment always ends up accessible to more people. A derived dataset, with names and numbers replaced but the awkward cases preserved, gives you the same bugs without the risk.

The prototype on the hardest path

When a prototype is asked for, it should cover the riskiest part, not the most demonstrable. A prototype proving the model can summarise a text proves nothing: that was a given. A prototype that fetches a value from your till proves the only uncertain thing.

It is a simple principle and it is systematically inverted, because an easy prototype makes a better meeting. It also makes a worse project, and the gap appears once the budget is committed.

A prototype also has an expiry date that should be announced. It is written to prove a point, not to last, and reusing it as a production base is the commonest way to turn a good stage into debt. Saying so at the moment of delivery avoids the awkward conversation where somebody asks why something that already works needs rebuilding.

What will break, written in advance

An integration is a contract with software that never signed it. The system at the other end will change version, rename a field, alter a date format, and it will do so without warning you because it does not know you exist.

So the documentation does not only describe what was built, it describes what will break it: the external dependencies, the assumed versions, the expected formats, and the symptom each rupture will produce. That is the part that makes the integration repairable by somebody else.

That page is also the simplest test of a supplier’s quality. Ask for it before the project ends. If it does not exist, it is not that it has not been written yet: it is that nobody asked the question.

The documentation has a specific reader worth keeping in mind: the person who will open the file in eighteen months, in a hurry, without you. That reader does not need to know why a given library was chosen; they need to know what happens when the expected file does not arrive, where to look, and who to call. Writing for them produces a shorter and far more useful document than the usual architecture documentation.

What we do, and what we will not touch

We run the inventory, we prototype the hardest path, we build behind a layer that belongs to you, and we put the code, credentials and documentation into your accounts during the project rather than at the end. You never have to ask our permission to work with somebody else.

We do not price the integration before the inventory, and we decline to do so even when pressed. A price given before knowing what your systems expose is not an estimate, it is a bet whose risk you carry: either it is inflated to cover the unknown, or it is fair and will be exceeded, and in both cases you have paid for our uncertainty. The inventory costs a few days, is billed on its own, and turns the question into one that can be priced.

There is also something we will not do, even when it is technically possible and the client asks for it: read an application’s database directly when that application never expected to be read. It can often be done, it works for a few months, and it breaks at the publisher’s next update — on a date we do not choose, about which we have no information, and on which we may no longer be around. The client then inherits a broken system whose cause nobody understands. When an application exposes nothing, we propose a periodic export and accept its delay, or we say the project does not happen.

One last thing, more mundane and more common than anything above: we do not keep your credentials after the project ends. They are created in your name, handed to you, and revoked at delivery. That is elementary hygiene and it is rarely practised, because keeping access makes support more convenient for the supplier. If you call us back, you will reopen the access, and that friction is deliberate.

Frequently asked questions

What if our application has no programming interface?

We look at what it exports and how often, and tell you whether that delay suits the use. Sometimes it does, sometimes not, and the inventory settles it.

Can we change AI supplier later?

Yes, that is the purpose of the abstraction layer. Ask for the switch to be tested during the project rather than promised for later.

Does our data go abroad?

Only the necessary fields, listed one by one and approved by you. Anything you exclude is handled locally or not at all.

Who maintains the integration after delivery?

You, your team or us, as you choose. The documentation is written so the third option stays an option rather than an obligation.

Do we redo everything if we change CRM?

Not the model side, yes the connection side. That is precisely why the two are separated in what we deliver.

How long does a typical project take?

The inventory takes a few days. What follows depends entirely on what it finds, and we do not price it before having it.

Where we come in

For each of your systems, knowing who installed it and whether its vendor still answers decides everything. The second answer is often no.

We build the inventory before putting forward any amount at all.
We build first the connection most likely to fail.
We give your exports back at the end and keep no copy of them.

Until the inventory is done no figure leaves us, however hard you press: a blind estimate is wrong by a factor, not by a percentage.

Start with the free audit See the Custom AI integrations page

Let us talk about your project

A free audit, no commitment: we look at your online presence and tell you what is holding it back.

Request the free audit Write to us