Retrieval over your data
RAG across your documents, tickets, catalogue or codebase — chunking, hybrid search, reranking and citations that link back to the source so answers can be checked.
Services / AI
Not a demo.
A product.
AI built into a product to do a defined job — retrieval over your own documents, agents that take real actions, automation that removes an actual hour from someone’s week. Grounded in your data, with the failure modes handled.
Start a project- RAG & search
- Agents & tool use
- Workflow automation
- Evaluations
- Guardrails
- Private deployment
Where we win
The gap isn’t the model.
It’s everything around it.
A retrieval prototype takes a weekend. Making it survive contradictory documents, a stale index, an ambiguous question, a hallucinated citation and a user who pastes in forty pages takes considerably longer — and that part decides whether anyone still uses it in month three. We build for the second one, with evaluations you can point at instead of a vibe check.
What we build
Six things
we do here.
Agents & tool use
Systems that call your APIs and do the work, with scoped permissions, human approval where it matters and a full audit trail of what ran.
Workflow automation
Classification, extraction, summarising and routing wired into the tools your team already has open, rather than another tab to remember.
AI inside existing software
Search, drafting, support and recommendations added to a product you already run, without rewriting it first.
Evaluation & guardrails
Test sets, regression runs, cost and latency budgets, prompt-injection handling, and a way to tell whether a change made things better or worse.
Deployment
Hosted APIs, your own cloud, or open-weight models running inside your network when the data can’t leave the building.
The toolkit
What we
work with.
Models
- Claude
- OpenAI
- Gemini
- Open-weight models
- Local inference
Retrieval
- pgvector
- Qdrant
- Pinecone
- Hybrid search
- Rerankers
Plumbing
- TypeScript
- Python
- MCP
- Queues & workers
- Tracing
What you get
In your hands,
not ours.
- A defined job the system has to do, agreed before we build it.
- An evaluation set and a baseline, so “better” is something you can measure.
- Cost and latency per request, budgeted and then instrumented in production.
- Citations and audit logs on anything a customer can see.
- A written note on what the system should not be trusted with.
- Your keys, your data, your infrastructure.
Questions
The awkward
ones.
Will our data be used to train a model?
Not unless you ask for it. We use enterprise API terms that exclude training by default, and where the data is sensitive we can run open-weight models entirely inside your own infrastructure.
How do you stop it making things up?
Ground every answer in retrieved sources, cite them, and constrain what the model is allowed to do — then test against a fixed evaluation set on every change. Hallucination isn’t eliminated; it’s contained, measured and made visible.
Which model should we use?
The cheapest one that passes your evaluations. We benchmark two or three against your actual data during scoping, and design so the model can be swapped later without a rewrite.
We don’t know what we’d use AI for.
That’s a better starting position than a solution looking for a problem. We run a short paid discovery — where the time goes, what’s repetitive, what data already exists. If the honest answer is that AI isn’t the fix, we’ll tell you that.
How much does it cost to run?
It depends on volume, context size and model choice. We estimate it during scoping and instrument it in production, so it stays a line you can watch rather than a surprise invoice.
Can it work with our existing systems?
That’s usually the whole job. The interesting part is rarely the model — it’s connecting it safely to the CRM, the warehouse, the ticketing system and the permissions that decide who may see what.