Add AI Where It Earns Its Place, Not Where It Demos Well
We build AI into software — assistants grounded in your own content, search that understands meaning, document processing, agents that take real actions. We'll also tell you when the honest answer is that you don't need a model for this.
Four Kinds of AI Work, and They Are Not Equally Hard
Nearly every request we get is one of these. The first is usually the cheapest and the most useful. The third is the one people underestimate.
AI Features Inside an Existing Product
Search that finds the right record even when the wording is different. A summary at the top of a long thread. Automatic tagging of incoming items so they land in the right queue. A first draft of the reply, the listing or the job description — written for a person to edit, never sent unseen. These are small, well-bounded additions to software you already have, and this is where most of the real value sits.
Support Assistants Grounded in Your Content
An assistant that answers from your documentation, help articles, policies and resolved tickets — and shows which document each sentence came from. Grounding is the whole game here. Without it you have a confident stranger guessing about your business. With it you have something a support lead will actually let near a customer.
Agents That Take Multi-Step Actions
Read the email, pull the order, check the policy, issue the refund, write back. Genuinely useful, and genuinely the riskiest thing on this page, because an agent that is wrong doesn't just say something wrong — it does something wrong. We build these with a fixed set of permitted tools, hard limits on what can change without approval, an audit trail of every step, and a review gate on anything that moves money or reaches a customer.
Document and Image Processing
Invoices, delivery notes, applications, ID documents, inspection photos from a connected device — pulled apart into structured fields your systems can use. This works well, but accuracy is a number, not a yes. We measure it per field, route low-confidence extractions to a human queue, and design the screen where that review happens as carefully as the extraction itself.
Why a Grounded Answer Is a Different Product
A model on its own answers from whatever it absorbed in training. A grounded system answers from your content, and can show you where every claim came from.
Asked inside your product, carrying the signed-in user with it.
From your documents, filtered to what this user is allowed to see. Nothing else is considered.
Instructions plus those passages, with an explicit rule: answer only from this material.
Constrained to the supplied evidence, and told to decline when that evidence is thin.
Every answer links back to its sources, so a reader can check it in one click.
Answers are stored and scored against the evaluation set. The failures become next week's fixes.
What the retrieval step actually buys you
It keeps the answer inside material you control, so when a policy changes you edit a document instead of rebuilding a feature. It respects permissions, so a customer is never handed an internal note by accident. And it makes wrongness visible: if the answer cites the wrong page you can see that in a second, rather than arguing with a black box.
It also sets a ceiling you should know about before you budget. If the answer isn't in your content anywhere, no amount of prompt work will conjure it. Grounded assistants are frequently a content project wearing an AI costume — and the honest version of that conversation happens in week one, not month three.
The backend work underneath thisThe Limits, Before You Spend Anything
None of these are reasons not to build. They are reasons to build it a particular way, and to budget for the parts nobody puts in a pitch deck.
Hallucination is a property, not a bug we can patch
- A model produces text that fits the shape of a good answer, which is not the same as a true one
- Grounding, citations and explicit permission to say "I don't know" reduce it a great deal
- They do not reduce it to zero, and any proposal claiming otherwise should worry you
- So the design question is never whether it will be wrong — it is what happens when it is
Consequential output needs a human in the loop
- Anything that moves money, changes a legal record or is sent to a customer in your name gets reviewed
- Review only works if the screen makes it fast — a queue nobody can clear gets rubber-stamped
- Show the evidence beside the output, so the reviewer can check rather than redo the work
- Confidence scores let you auto-approve the easy majority and route the rest to a person
Cost per request is real at scale
- You are billed by the volume of text going in and coming out, on every single call
- Stuffing an entire manual into each request is the most common and most expensive mistake
- Tighter retrieval, caching of repeated questions and a cheaper model for easy cases all help
- We model the monthly figure at your expected volume before building, not after the first bill
Latency changes the interface
- A generated answer takes seconds, not milliseconds, and a multi-step agent takes considerably longer
- That is fine when the screen streams the answer as it arrives and says what it is doing
- It is not fine inside a checkout, or any other path a user is trying to rush through
- Slow work belongs in the background with a notification when it lands
Evaluation matters more than the demo
- Any AI feature demos well — a demo is three inputs chosen by the person demoing
- We write an evaluation set of real inputs with agreed correct answers before building the feature
- It runs on every change, so an improvement to one case cannot quietly break nine others
- Without it there is no way to tell whether last week's prompt edit helped or hurt
Your data, and where it goes
- Using a hosted model means request text leaves your servers, which is a decision to make deliberately
- We read the provider terms on training and retention, and write down exactly what gets sent
- Sensitive fields can be stripped or masked before the call, and usually should be
- Where data genuinely cannot leave, a self-hosted open model is an option — cheaper per call, more infrastructure to run
When You Don't Need AI for This
We would rather lose the AI budget and keep the client. Here is how we decide — and you hear it on the first call, not after the invoice.
The rule is already a rule
If the decision is a fixed set of conditions someone can write on a whiteboard, write those conditions. A model is slower, costs money on every call, and may answer differently on Tuesday. Deterministic logic isn't the boring option here, it is the correct one.
The data is already structured
Totals, filters, trends and thresholds over rows in a database are a query and a chart, not a language model. That is a reporting problem with a much cheaper and far more reliable answer — see analytics dashboards.
There is nothing to ground on
An assistant with no documentation behind it is a general chatbot with your logo on it. If the answers only live in one person's head, the first project is writing them down. That isn't a failure, it is the prerequisite, and it is often worth doing on its own merits.
The volume doesn't justify it
If four people a week spend ten minutes on the task, the build, the evaluation work and the running cost will not pay back. Automate the thing that happens four hundred times a week instead, and leave this one alone for now.
Messy language in, judgment out
Free text, emails, PDFs, photos, notes that no two people write the same way. When the input has endless variation and the output needs interpretation rather than lookup, this is what a model is genuinely good at, and very little else does it well.
People can't find what they know exists
When users are certain the answer is in your system but keyword search won't surface it because they used different words, semantic search repays its cost quickly. It is also one of the lowest-risk AI features you can add, and a common first step on an ecommerce catalogue: a poor result is a poor result, not a false statement of fact.
One Job, Measured, Then the Next
Pick a single job
One task, one user, one measurable outcome — not a platform. Scoping ends with the narrowest useful version and an estimate of what it should cost per request to run.
Write the evaluation set
Real inputs from your business with answers you agree are correct, including the awkward ones. This exists before any feature code, because it is what decides when we are finished.
Build the grounded pipeline
Retrieval, prompt, citations, refusal behaviour, logging and the human review screen — behind your existing login and permissions from the first commit.
Ship behind a flag, then watch
Released to a small group first, with cost per request, latency and evaluation scores visible. We widen it when the numbers hold, and you get a working demo build every two weeks throughout.
Related Work
AI features almost never arrive alone. These are the pieces they usually sit on top of.
Backend & APIs
Retrieval, queues, caching and the audit log an AI feature needs behind it to be safe and affordable.
Learn moreCustom Business Software
The internal tool an extraction pipeline feeds, including the review queue where a person confirms the uncertain rows.
Learn moreAnalytics Dashboards
Where accuracy, cost per request and latency become numbers you can watch rather than opinions people hold.
Learn moreQuestions We Get Asked First
Will the AI make things up?
Sometimes, yes. A language model generates plausible text, and plausible is not the same as correct. We reduce it by grounding answers in your own documents, showing the source next to every answer, and designing the system to say it does not know rather than guess. For anything consequential a person reviews the output before it reaches a customer. Anyone who tells you hallucination is a solved problem is selling you something.
How much does an AI feature cost to run?
There are two numbers: what it costs to build, and what it costs per request forever after. Model calls are billed by the amount of text processed, so a feature that reads a long document on every use costs far more per use than one answering a short question. We estimate the per-request cost during scoping, design the retrieval step to keep the input small, and cache anything that repeats. At low volume it is often a few dollars a month. At high volume it becomes a line item worth engineering against.
Can you add AI to the app we already have?
That is most of what we do. We read your codebase, find the places where a model genuinely helps rather than the places where it would demo well, and add the feature behind your existing login and permissions so it only ever sees data that user is already allowed to see. You do not need to rebuild anything to start.
Do you train a custom model on our data?
Usually not, and that is good news for your budget. Retrieval over your own content gives accurate, current, source-cited answers with no training run, and you can change the content without retraining anything. Fine-tuning earns its place when you need a consistent output format or house tone at volume, not when you need the system to know facts. We tell you plainly which case you are in.
How do you know the feature actually works?
We build an evaluation set before we build the feature: real inputs paired with answers we agree are correct, run automatically against every change. A demo proves the happy path with the three questions the person demoing picked. An evaluation set tells you what happens on the other two hundred, and that is the difference between shipping something and hoping.
Tell Us What You Want the AI to Do
Describe the task in plain words. We'll come back with whether a model is the right tool, what it costs to build, and what it costs per request to run.