01Content audit
What material exists, where it lives, how current it is, and who may see it.
You getA content readiness report with the gaps named.AI & Automation
Generative AI that answers from your material, not the internet.
A general model knows everything except your business. We build systems grounded in your own documents, data and rules, so the answer is specific, cited, and respects who is allowed to see what.
First copilot live5–8 weeksGroundingYour documents, data and systems, with citationsAccess controlInherits your existing permissions, per userModelsCommercial or open-weight, self-hosted where requiredQualityEvaluated against your own questions, not a benchmarkOwnershipPrompts, pipelines and evaluation sets are yours
The difference that matters
The model is the easy part. Grounding it is the work.
Any team can put a chat box in front of a language model in an afternoon. What makes it useful (and what takes the actual engineering) is everything behind it: getting your content into a form the model can search, retrieving the right passages, and constraining the answer to what those passages support.
Done properly, the result is a system that answers from your policies, your contracts and your product documentation, cites where each claim came from, and says it does not know when the material does not cover the question.
Done carelessly, you get a confident, fluent, unattributable answer that is wrong in a way nobody notices for three months. The gap between those two outcomes is retrieval quality, permission handling and evaluation, none of which are visible in a demo.
That is also why the second copilot is much cheaper than the first. The grounding layer, once built, serves every use case after it.
Architecture
What sits between a question and a trustworthy answer.
The model is one layer of five, and it is the one we expect to replace most often. Everything above it is what makes the answer yours.
Your contentSource of truth
PoliciesContractsProduct docsTicketsWikisRecords
↕
IngestionKept in sync
ConnectorsChange detectionChunking for meaningMetadata & ownership
↕
RetrievalWhat we build
Hybrid searchPermission filteringRe-rankingCitation tracking
↕
GuardrailsNon-negotiable
Grounded-only answersConfidence thresholdsEvaluation suiteCost ceilings
↕
ModelsSwappable by design
Commercial APIsOpen-weight, self-hostedTask-matched routingNo lock-in
What we build
Six generative systems that earn their place.
Each is grounded in your own material and measured against questions your people ask.
01
Internal knowledge copilots
Answer staff questions from policies, procedures and product material, with the source cited so the answer can be checked.
Intranet · SharePoint · policy library
02
Customer-facing assistants
Handle product, order and account questions with a clean handover to a person the moment the conversation needs one.
Website · CRM · order system
03
Document generation
Draft proposals, reports, responses and summaries from live data in your own house style, ready for review.
CRM · templates · data warehouse
04
Contract & document analysis
Extract obligations, dates and risks across large document sets, with every finding linked to its clause.
Document store · DMS · legal repository
05
Engineering copilots
Assist with documentation, test generation and legacy code comprehension inside your own development workflow.
Repositories · CI · issue tracker
06
Meeting & call intelligence
Summarise conversations into decisions, owners and actions, written back to the system of record.
Conferencing · CRM · task toolsAI chatbot development
Chatbots, done so that people use them twice.
Most organisations have already deployed a chatbot and quietly watched usage collapse. The reason is almost never the model, it is that the bot could not see the information that would have made it useful, could not act on anything, and had no graceful exit when it was out of its depth.
We treat a chatbot as an interface onto a grounded system instead of a product in its own right. That means it can answer from your material, take real action where you allow it, and escalate cleanly with the conversation attached when it should.
- Grounded answers with citations; every response traceable to the document or record it came from.
- Permission-aware retrieval — two users asking the same question get answers scoped to what each may see.
- Action, not just conversation, raise the ticket, check the order, book the slot, update the record.
- Clean human handover, escalation carries the full conversation and context, so nobody repeats themselves.
- Multi-channel deployment, web, intranet, Teams, WhatsApp and voice from one grounded core.
- Usage and gap reporting; the questions it could not answer become the roadmap for the content it needs.
Two systems, one demo apart
Both look identical in a five-minute demo.
The gap only appears in week three, which is why so many of these projects are approved on a demonstration and abandoned on contact with real questions.
Ungrounded
A model with a chat box
- Fluent answers that cannot be traced to anything
- Everyone sees the same answer, whatever their access
- Confidently fills gaps the material never covered
- Quality is a matter of opinion, measured by nobody
- Usage collapses in the second fortnight
→
Grounded
A retrieval system with a chat box
- Every claim linked to the passage it came from
- Answers scoped to what each person may open
- Says the material does not cover it, and escalates
- Scored against your own approved answers on every change
- Unanswered questions become the content roadmap
Accuracy and risk
The six questions to ask before this touches a customer.
Generative systems fail differently from ordinary software: they fail fluently. These are the controls that make that failure mode manageable.
How do we know it is right?
An evaluation set built from your own questions and approved answers, run automatically against every change to prompts, retrieval or model.
Where did that answer come from?
Citations to the source passage on every claim. If a statement cannot be traced to your material, the system says so rather than filling the gap.
Who is allowed to see what?
Retrieval inherits your existing permissions. Access is filtered before the model ever sees a passage, not afterwards.
What stops it inventing things?
Constrained generation over retrieved passages, confidence thresholds, and an explicit “not covered” response instead of a plausible guess.
Does our content leave our boundary?
Only if you choose that. Open-weight models can run inside your own tenancy; where a commercial API is acceptable we use zero-retention terms.
What does it cost at volume?
Per-query cost instrumented from the start, with caching, smaller models for routine retrieval, and ceilings per use case.
How we deliver
Grounded first, generative second.
02Retrieval build
Ingestion, chunking, indexing and permission filtering, the part that decides quality.
You getA working retrieval layer you can query directly.03Assemble
Interface, prompting, citation handling and escalation paths built on top.
You getA usable copilot in staging, on your real content.04Evaluate
Scored against a question set written by the people who will use it.
You getAccuracy and coverage results, plus the list of content gaps found.05Operate
Monitor unanswered questions, refresh content, tune retrieval, control cost.
You getMonthly usage, accuracy and cost reporting.Questions worth asking
Before you build a copilot.
The three below are the ones this page does not already answer. Anything more specific, put it to us directly.
Our documentation is a mess. Do we have to fix that first?
No, and waiting until it is tidy is how these projects never start. Poor content shows up as specific, findable gaps once a copilot is running against it, the questions it cannot answer become a prioritised list of what needs rewriting, which is far more useful than a general instinct that the wiki is bad. We usually start with the material that is already reasonable, ship something useful, and let real usage direct the clean-up. What does need sorting first is permissions: if nobody can say who should see a document, the copilot cannot either.
Will this leak confidential information between departments?
Not if retrieval is permission-aware, which is the single most important design decision in a system like this. Access is applied when passages are fetched, before the model sees anything, so a user cannot retrieve material they could not open directly. The failure case to avoid is indexing everything into one store and filtering the answer afterwards, that leaks, and it leaks in ways that are very hard to detect. We inherit your existing groups and roles rather than inventing a parallel permission model that will drift.
How is this different from the copilot our software vendor already includes?
Bundled copilots are useful inside the product they ship with, and where one covers your need we will say so instead of build you something. The limit is that they only see their own application's data. Most real questions cross systems; the contract in the document store, the order in the ERP, the conversation in the ticketing tool. That is where a custom grounding layer earns its cost, and it is also why we would rather complement what you already pay for than replace it.
Related capabilities