Integrating AI Into Software You Already Have

You do not need to rebuild anything

The most common misconception we meet is that adding AI means a new system. It almost never does. In the majority of our AI work the existing application is barely touched: a new service does the AI part and the application calls it.

That boundary is the important design decision, and it is worth insisting on even when a quicker inline implementation is available.

Keep it removable

This field changes faster than any part of software we have worked in. A model that is state of the art now will be superseded, repriced, deprecated or beaten by something cheaper within a year.

So we build AI features as replaceable components: one interface your application calls, one place the provider is configured, no provider-specific concepts leaking into your domain code. Swapping providers should be a day's work, not a quarter's.

If you cannot describe how you would swap out the model provider, you have not integrated AI — you have married it.

The three integration patterns

1. Synchronous. User waits — a suggestion while typing, an instant classification. Needs a latency budget and a fallback for when the provider is slow.
2. Asynchronous. Queued and processed — document extraction, batch enrichment. Simplest to make reliable and where most business value sits.
3. Assistive. Draft presented for a human to accept, edit or reject. Highest value per unit of engineering because the human is the quality gate.

Most requests that arrive as “we want it real-time” are better served asynchronously. Real-time adds latency risk, cost and failure modes; ask what breaks if the answer arrives in ninety seconds, and the answer is often nothing.

Failure handling that does not break the application

Providers have outages, rate limits and slow days. The application must survive all of them, which means the AI feature is always additive, never load-bearing.

• A timeout shorter than your user's patience, with a defined fallback
• Retry with backoff, and a circuit breaker that stops hammering a failing provider
• A degraded path — the old keyword rule, a blank draft, a manual queue
• Queue and retry for async work, never silent loss
• An alert when the fallback rate rises, because that is the early warning

Where the feature actually belongs

Put AI where a person currently reads something and decides. That is the seam, and it is usually obvious once you look for it: the inbox, the queue, the moment someone opens a document to type its contents somewhere else.

Where it does not belong: anywhere the existing code already produces a correct answer deterministically. Replacing working logic with a model is a downgrade in reliability dressed up as modernisation.

Cost, and keeping it visible

AI features have a per-use cost, which is unfamiliar in a world of fixed hosting bills. It needs to be visible from day one or it becomes a surprise line item.

• Log cost per request and per feature, not just in total
• Set a monthly cap with an alert well before it
• Cache aggressively — identical inputs are more common than anyone expects
• Use the cheapest capable option per task; not everything needs the largest model
• Review monthly, because provider pricing genuinely moves

Frequently asked questions