AI integration services

The question to ask before any of this

Not "where could we put AI?" but "which part of this product currently makes a person do tedious work that has a right answer?" That question rules out most of what gets proposed and points straight at the things worth building. Data entry someone retypes from a document. A judgement call made fifty times a day from the same three signals. A search that only works if you already know the vocabulary.

If a feature doesn’t replace a specific, repeated, currently-manual task, it will demo well and get used twice. That’s the single most expensive mistake in this category, and it’s a product mistake rather than a technical one, which is why it survives so many technical reviews.

Four integrations that consistently pay off

1. Extraction, turning documents into data

Someone is reading a PDF, a receipt, a statement or a photo and typing what they see into your product. This is the highest-return integration available to most products because the task is genuinely tedious, the output is checkable, and the customer feels the benefit on day one. The engineering effort goes into what happens when the model is unsure: a confidence-aware flow that flags the three fields it wasn’t certain about beats a confident wrong answer every single time.

2. In-context assistance

Help delivered where the user already is, with the context already loaded. The difference between this and a chat box is that the assistant can see the record the user is looking at, so the user doesn’t have to explain their own situation before getting an answer. The hard part is scoping: what the assistant can see has to match what that specific user is allowed to see, on every request, without exception.

3. Classification and routing

Categorising, prioritizing, tagging, triaging. Unglamorous and frequently the best return in the whole list, because it runs invisibly on every record rather than waiting for someone to click something. It’s also the easiest to measure: you can compare against how a human categorised the same thing and get a real number, which means you can tell whether it’s working instead of hoping.

4. Agentic actions

Letting an assistant actually operate the product, read the right records, take real actions, within the permissions you set. This is the newest of the four and the one with the most upside, because the customer stops coming to your app for routine work and starts asking for it wherever they already are. It’s also the one with the most ways to go wrong. I’ve written about the implementation patterns separately in MCP development.

How I build it

Choose the smallest model that clears the bar

The instinct is to reach for the most capable model available and leave it there. That decision is invisible until it shows up as a bill or a latency complaint. Most production tasks, classification, extraction, routing, run acceptably on a cheaper, faster tier, and the ones that genuinely need the top tier are usually a minority of calls. Getting that split right is often the difference between a feature that pays for itself and one that quietly doesn’t.

Measure it, or you’re guessing

An AI feature doesn’t fail loudly. It degrades, slightly worse answers, slightly more often, with no error in any log. Without a set of known-answer test cases you run deliberately, you’ll discover the regression through a customer complaint weeks later and have no way to tell whether it was the prompt, the model version or the data. This is the part most teams skip and the part that determines whether the feature is still good in six months.

Design for the wrong answer

The model will be wrong sometimes. That’s a property of the technology, not a bug to be fixed, so the product has to be built around it: show the source, make correction a single click, keep the human as the approver anywhere the outcome matters, and never let a confident tone stand in for a verified fact. Products that hide uncertainty feel impressive for a week and lose trust permanently the first time someone gets burned.

Be deliberate about what leaves your system

Every integration is a decision about what customer data goes to a third party, and that decision belongs in the design rather than in an afterthought. What gets sent, what gets stripped first, what is retained, and what you can honestly tell a customer who asks, settled up front, because it’s very expensive to retrofit and it is exactly what a serious buyer will ask you about.

Products I’ve shipped this in

Four live products, four different shapes of the same problem.

YouGuard is the fourth, classification at volume, deciding what is appropriate for a child across YouTube and the browser. It’s the clearest example of why measurement matters: the cost of a wrong answer is asymmetric, and a parent notices.

What this usually costs you in time

A focused extraction or classification feature is typically a matter of weeks, not months, because the surrounding product already exists and the work is narrow by design. In-context assistance takes longer, because the scoping and permissions work is the real build. Agentic access takes longest, and should, those are the decisions you can’t easily reverse once customers have connected.

I’d rather scope one of these properly than three of them vaguely. If you aren’t sure which of the four you need, that’s a reasonable place to start a conversation.