Service AI features & LLM integration
Your product, with the intelligence built in.
You already have a product, a codebase, and years of content inside it — docs, tickets, records, uploads. We add the features that finally make that content useful: search that understands the question, answers that cite their source, copilots that live in your interface. Built on Claude and other frontier models, graded against an evaluation set before anyone calls it done.
01 What we build
Six features clients ask for by name.
If you want software that runs a whole workflow on its own — reads the inbox, updates the system, closes the loop without anyone watching — that's AI agents & chatbots. This page is the other half of the job: capability added inside a product your users already open, shipped as screens and endpoints in your existing codebase.
Search that understands the question
Retrieval over your own content, matched by meaning rather than keywords, so "what's our refund window for annual plans" finds the paragraph that answers it instead of every page containing "refund".
Grounded answers with citations
A question box that replies in prose and links every claim back to the passage it came from. Users can check the work, which is the only reason they end up trusting it.
Document understanding
Uploads turned into structured records inside the product: contracts, specs, statements, and forms parsed into fields your existing schema already has, with low-confidence values flagged rather than guessed.
In-product copilot
An assistant panel that can see the record the user is looking at — the project, the ticket, the account — and draft, explain, or answer in that context, respecting the same permissions as the rest of your app.
Summarize, classify, extract
Background pipelines that give every long thread a summary, every incoming item a category, every blob of text the three fields you actually query on. Cheap, batched, and rerunnable.
Evaluation harness
A scored test set of real questions and expected answers, wired into CI. It is what turns "the demo felt good" into a number you can watch move when you change a prompt, a model, or a chunking rule.
02 How it works
How a grounded answer is actually made.
A model on its own answers from memory, which is where invention comes from. A retrieval pipeline answers from your content: it looks the passages up first, hands them to the model with the question, and requires the answer to point back at them.
Fig. — Retrieval first, model second: passages are found in your own content, the answer must cite them, and every change is re-scored against a fixed eval set.
03 The build
From "we should add AI to this" to shipped.
Choose one feature
Not a strategy — a feature. The one your users would notice missing next week. We look at your product and your support queue, and we say plainly if the honest answer is a better filter rather than a model.
Write the eval set first
Fifty to a couple of hundred real questions with the answers you'd accept, collected from your team before any code exists. This is the single step most projects skip, and the reason they can never tell whether a change helped.
Get retrieval right
How your content is split, what metadata rides along, how many passages come back, and how permissions are filtered. Most bad AI answers are bad retrieval; the prompt gets blamed for it.
Wire it into the product
Real integration into your codebase: your auth and permission rules, streaming responses, loading and empty states, timeouts, a sane fallback when the model is slow or down, and cost caps per user.
Ship behind a flag, then tune
Live for a slice of users first, with logging on inputs, outputs, latency, and spend. We tune against the eval set and the real traffic — and you own the code, the prompts, the eval set, and the keys.
04 Fit
This is for you if…
- Your product holds years of content nobody can find with the search box you have.
- Users upload documents and someone re-types the contents into your forms.
- You added a chat panel with a raw API call and it confidently makes things up.
- Your team writes the same summaries, tags, and replies over and over inside the app.
- You need answers that cite a source because a customer or auditor will ask where it came from.
- You have a prototype that impressed everyone and no way to tell if it got better since.
05 Questions
What clients ask first.
How do you stop it making things up?
You can't reduce it to zero, and anyone promising that is selling something. What you can do is remove the incentive to invent: the model answers from retrieved passages rather than memory, every claim carries a citation the user can open, and when retrieval comes back empty the feature says it doesn't know instead of filling the gap. The eval set then measures how often that behavior actually holds.
Does our data get used to train models?
No. We build on business-tier APIs where your content isn't used for training, and the index we build lives in your infrastructure. Retrieval respects your existing permissions, so a user can't be shown a passage from a record they couldn't already open. If you have residency or compliance requirements, tell us on the call and we'll design around them.
What does it cost per request, and what stops it running away?
Usually fractions of a cent to a few cents per answer, depending on how much context each one needs. Four things keep it there: retrieving fewer, better passages instead of stuffing the prompt; caching repeat questions so they never reach the model; using a smaller model for the easy, high-volume work like tagging and summarizing; and hard per-user and per-day caps. We model the monthly bill at your real traffic before you commit.
Which model do you use, and are we locked in?
Usually Claude, sometimes others, chosen per task — a large model where reasoning matters, a small one where volume does. Calls go through a thin layer in your codebase, so swapping a model is a config change plus an eval run, not a rewrite. The model is the cheapest part to replace; the retrieval, the product wiring, and the eval set are the durable work, and they're yours.
How do we know it's any good?
By the numbers on the eval set: did the answer contain the expected facts, did it cite a real passage, did it correctly decline when the content had no answer. That runs on every prompt, model, or chunking change, so improvement and regression are both visible. Alongside it we log real usage — latency, spend, thumbs-down, and the questions that returned nothing — because the questions your feature fails on are the roadmap.
06 Related
Often built together with:
Tell us what your users can't find.
Describe the product and the content sitting inside it. You'll get an honest read on whether retrieval, a smaller feature, or nothing at all is the right answer — and a fixed quote within 48 hours if there's something worth building.
Book a free discovery call