An agent is only as good as the knowledge layer underneath it.
Most AI projects fail on grounding, not on the model. The retrieval layer is where correctness, permissions and freshness are decided — and it is the part nobody wants to own. We build it as a platform with a name, an owner and a test suite.
“It hallucinated” is usually a data problem wearing a model's clothes.
When an assistant gives a confidently wrong answer, the instinct is to change the prompt or swap the model. Nine times out of ten the real cause is upstream: the right document was never retrieved, or it was retrieved in a form the model could not use, or it was three versions out of date, or the user should never have been able to see it at all.
One index, one embedding, one hope
A single vector store over a folder of PDFs answers similarity questions reasonably and factual questions badly. Ask it how many open contracts a client has and it will find a paragraph that sounds like an answer.
Nobody owns freshness
The index was built once, during the pilot. Six months on, no one can say which documents are in it, when they were last refreshed, or what happens when a source system changes a field.
Permissions bolted on afterwards
Retrieval that ignores who is asking will eventually surface a salary review, a board pack or another client's data. Filtering after retrieval is not access control; it is luck.
Three tiers, because knowledge is three different shapes.
This is the Knowledge Store pattern from our own research. Each tier answers a kind of question the others answer badly, and the routing between them is part of the design rather than an afterthought.
Structured records
Facts with a schema: customers, contracts, tickets, invoices, entitlements. Counts, sums, dates and joins come from here, where they are exact, rather than from a paragraph that happens to mention a number.
Vector retrieval
Chunking that respects document structure, hybrid keyword and semantic search, re-ranking, and metadata filters applied before the search rather than after it. Tuned against a golden set, not by feel.
Relationship graph
Which system talks to which, which contract belongs to which entity, which policy supersedes which. The context that makes an answer defensible instead of merely plausible.
Ingestion & freshness
Connectors to the systems you already run, incremental refresh, change data capture where it exists, and a dashboard that shows what is in the index and how old it is.
Permission-aware retrieval
The caller's identity is carried into the query, so the search itself never returns what the person cannot see. Enforced at the store, not in the prompt.
Evaluation harness
A golden set of questions with known answers, retrieval precision and recall measured on every change, and a regression run before anything ships. You keep the harness whether or not you keep us.
Governance and evaluationFour to ten weeks, depending on how many source systems are in play.
Inventory
What knowledge exists, where it lives, who owns it, how sensitive it is and how often it changes. This usually surfaces two or three systems nobody remembered were authoritative.
Golden set
Fifty to two hundred real questions with agreed correct answers, written with the people who will use the system. This becomes the definition of done.
Build
Ingestion, the three tiers, routing and permission enforcement, in your cloud account, with cost and latency measured from the first week.
Hand over
Runbooks, the evaluation harness, refresh schedules and a named owner on your side. We would rather you did not need us for the next one.
It is a platform, not a project.
The same knowledge layer serves the internal assistant, the customer-facing agent and the automation that quietly resolves tickets at three in the morning. Building it once, properly, is what makes the second and third use case cheap.
Questions we get asked
Do we need a data warehouse before we start?▼
No. A warehouse helps if you already have one, but the structured tier can read from operational systems through well-behaved, rate-limited queries or a read replica. What matters is that there is one agreed source of truth per fact, not that it lives in a particular product.
How do you stop the assistant answering from stale documents?▼
Every chunk carries its source, version and ingest timestamp, retrieval prefers the current version, and superseded documents are either excluded or returned with an explicit note. The freshness dashboard makes the age of the index visible rather than something you discover during an audit.
Can this run entirely inside the EU?▼
Yes. The store, the embeddings and the model endpoints can all be pinned to EU regions in your own cloud account. We design for that by default with Irish and European clients, and we document where every piece of data comes to rest.
What does “permission-aware” mean in practice?▼
The identity of the person asking is passed into the retrieval query and used as a filter at the index, so restricted material is never a candidate for the answer. It is the same principle as row-level security in a database, applied to search.
Do we keep the evaluation set if we stop working with you?▼
Yes, and we would encourage you to keep using it. The golden set, the harness and the infrastructure code all live in your repositories and your cloud account from day one. There is no platform of ours to be locked into.
One free hour. No pitch, no obligation.
Bring the problem you are stuck on — an integration that keeps breaking, a cloud bill nobody can explain, an AI project that is all demo and no product, or a platform you are about to invest in. You will leave with a straight answer and a written summary, whether or not you ever work with us.
- Architecture and integration review
- AI feasibility — what will actually work, and what will not
- AWS, Azure and Google Cloud cost and design
- Business process audit and ISO readiness
- Technical due diligence before you invest or acquire