The hard part starts after the demo works
A model call is a few lines of code. What takes the time is everything around it: getting the right context in front of the model, knowing whether a change made quality better or worse, keeping the cost per user predictable, and deciding what the product does when the answer is wrong. That's the part we build.
How we take AI to production
The order matters more than the tooling. Most AI projects that stall skipped step two.
Define what correct means
Before any prompt is written: what does a right answer look like, who decides, and what's the cost of a wrong one? A feature nobody can grade can't be improved, only argued about.
Build the evaluation set first
A few dozen real examples with expected outcomes, runnable on every change. It's unglamorous and it's the difference between tuning and guessing.
Get retrieval right before the model
Most bad answers are retrieval failures, not reasoning failures. We measure whether the right source made it into the context window before touching prompts or swapping models.
Pick the cheapest model that passes
Start with the strongest model to prove the task is possible, then work down until quality drops. The gap between those two is usually most of your bill.
Ship behind a flag, to a slice
A percentage of traffic, a visible fallback, and a kill switch that doesn't need a deploy. AI features earn their rollout the same way any other risky change does.
Watch quality and cost together
Tokens, latency, and answer quality on the same dashboard. Model providers change behaviour under you; you want to find out from a graph, not from a customer.
What we build with AI
Twelve things that come up repeatedly. If your problem isn't on the list, describe it anyway. The interesting ones rarely are.
Retrieval over your documents
Answers drawn from your own content, with a citation back to the source paragraph.
Task agents
Multi-step work with tool access, a step limit, and a human checkpoint before anything irreversible.
Document extraction
Structured fields out of invoices, contracts, forms, and IDs, with a confidence score and a review queue.
Voice interfaces
Inbound and outbound calling with interruption handling and a warm transfer to a person.
Speech pipelines
Transcription with speaker separation, custom vocabulary, and synthesis for the reply.
Support assistants
Conversation across turns, grounded in your help content, with escalation rules that trigger early.
Semantic search
Search that matches meaning as well as keywords, with filters and ranking you control.
Vision
Classification, detection, and defect spotting on images and video frames.
Summarisation & reporting
Long inputs reduced to a briefing, with the numbers checked against the source.
Workflow automation
AI decisions wired into the tools you already run, with retries and an audit trail.
Fine-tuning
Task-specific tuning when a general model is close but not accurate enough, measured against a held-out set.
Evaluation harnesses
A test suite for model behaviour, so a prompt change can't quietly regress quality.
What we insist on, every time
These aren't upsells. An AI feature without them is a demo with a login page.
An eval suite before launch
No AI feature goes live without a way to tell whether the next change made it worse.
Defined wrong-answer behaviour
Every feature has a specified thing it does when it isn't confident: escalate, cite nothing, or say it doesn't know. Never quietly guess.
A cost and latency ceiling
Agreed per feature and monitored, so a change in usage doesn't quietly multiply your bill.
Clear data handling
What gets sent to a provider, what's retained, and what's excluded, written down before the first call is made.
A human in the loop where it matters
Anything irreversible or customer-facing gets a review step until the numbers justify removing it.
No model swaps without a re-run
Changing model or provider means re-running the evals. A newer model is not automatically a better one for your task.
Good places to point AI
AI is expensive per call and probabilistic by nature. It pays off where volume is high and a mistake is recoverable. It's a poor fit where neither is true.
- If a rules engine or a good search index solves it, we'll say so. Those are cheaper to run and easier to debug.
- Accuracy targets get set against your evaluation set, not quoted as a number up front.
- A model that's right 85% of the time is a product design problem, not a launch blocker, but you need to know which 15%.
- Ongoing cost is part of the design, not a surprise in the second month's invoice.
High-volume reading
Queues of documents, tickets, or applications that people currently work through by hand.
Knowledge nobody can find
Answers that exist in your docs, wikis, and past tickets but take twenty minutes to locate.
Repetitive first-line contact
The same handful of questions arriving all day, where the useful answer depends on account context.
Glue work between systems
Judgement calls a person makes to move data between two tools that don't integrate.
Unstructured input
Free text, audio, images, or scans that have to become structured records before anything else can happen.
Not sure which of these you're looking at? That's a good first conversation.
Bring us the AI project that stalled
Tell us what it does today and where it falls over. We'll come back with what we'd measure first and what we think it takes to make it releasable.