Enterprise RAG: knowledge that completes the action

Three years ago, wiring an embedding model to a vector index and getting a grounded, cited answer out of a pile of PDFs was a project. Today it is close to a commodity: the components are mature, the tutorials are good, and a competent engineer can stand up a passable retrieval augmented generation platform over a documentation set in a week.

That is genuine progress, and it is also why so many RAG platform pitches now sound identical. Everyone can find the passage. Everyone can cite the source. Everyone can render a tidy answer with a link back to the paragraph it came from. If that is the whole product, the differentiator is a UI and a price.

The interesting question is what happens after the right paragraph has been found. In most companies, the person who asked did not want to read the refund policy. They wanted the refund issued. The retrieval was never the goal; it was the evidence.

Retrieval finds the paragraph. Execution finishes the job.

Before we talk about actions, it is worth being honest about the enterprise-grade table stakes — the properties that separate AI knowledge base software that a company can rely on from a weekend prototype that happens to work on a clean corpus:

• Ownership and freshness. Every source needs an owner and a refresh path. A policy document that changed in March and was indexed in January is not a stale answer — it is a confidently wrong one.
• Access rights that survive retrieval. An employee must not see through an assistant what they cannot see in the underlying system. Permissions have to be enforced at retrieval time, per user, per tenant — not bolted on as a filter over results that were already assembled.
• Traceability to the source. Not a plausible citation — the actual passage, the actual version, so a human can check it.
• Isolation. One tenant’s knowledge never becomes another tenant’s context. This is an architectural property, not a configuration flag.
• Scope discipline. A knowledge layer that answers everything answers nothing reliably. Narrow, owned, current beats broad, orphaned, drifting.

These are the parts we have shipped: knowledge import and indexing, structured company data used to verify state, and roles with tenant-scoped permissions. They are unglamorous and they are the floor. They are also not, by themselves, a reason to buy anything.

Consider an internal AI assistant that a support agent asks about a duplicate charge. It retrieves the correct clause of the refund policy, quotes it accurately, cites the document, and stops. The answer is correct. The customer is still charged twice.

What happened is that the assistant handed the work back. A person now has to read the clause, decide it applies, open the billing system, find the invoice, check the amount, and issue the refund — which is the work that was expensive in the first place. The AI removed the cheapest step, reading, and left the costly ones intact.

This is the structural limit of a knowledge-only product. It can be measured on answer quality, and it can score extremely well on answer quality while changing nothing about how the business runs. The metric that matters is not whether the passage was right; it is whether the operation completed. We took that argument apart in detail on the support side, in resolve, not deflect.

Being precise about what we are not: this is not about exploring data, building dashboards, or querying warehouses in natural language. ai.NEST is not an analytics surface. Knowledge and data exist here for one purpose — to justify and verify an action that is about to be taken.

The connection between retrieval and execution is what we call a grounded proposal. The agent does not merely quote the refund policy; it proposes the specific refund that the policy permits — say, €48.00 against invoice INV-2231 — and it carries the evidence for that proposal with it. (Illustrative numbers: this is a mechanism, not a customer.)

For that to be safe, retrieval has to be joined to a bounded catalogue of actions. The agent cannot invent an operation because a document mentioned one. It can only propose from a finite, explicitly configured set — refund, plan change, access grant — and each proposal must be filled in from two sources: the knowledge that says an action is permitted, and the live data that says the preconditions are actually true. Policy says duplicate charges are refundable. Data says this customer really was charged twice. Neither alone is enough.

Then the proposal leaves the model’s hands entirely. The Policy Engine checks it against your rules — the requester’s role, whether that action is in the catalogue at all, whether the amount sits under the auto-approve threshold. Above the threshold, it waits for a human, who sees the proposal, the evidence it was grounded in, and the rule that routed it to them. Only then does the Executor call your API. Every step is written down: what was proposed, what it was grounded in, which rule decided, who approved, what ran.

Retrieval justifies the action. The Policy Engine authorises it.

Note the division of labour. Retrieval is never trusted to authorise anything — it supplies evidence. Authorisation lives in explicit rules that a human wrote and can read. That separation is what makes it acceptable for a probabilistic component to sit upstream of a real, irreversible-looking operation.

The failure modes below are mild when knowledge only produces text. They become serious the moment knowledge produces actions — which is precisely why they belong in the design from day one, not in a hardening sprint later.

• Stale knowledge becomes a confidently wrong proposal. A superseded refund policy in the index does not just yield an outdated answer; it yields a refund that should never have been offered — issued fluently, with a citation. Freshness is a safety property, not a hygiene one.
• Permissions bypassed through the retriever. The classic enterprise leak: the assistant has broad read access and cheerfully summarises a document the asking employee was never allowed to open. If access is not enforced per user at retrieval time, the assistant becomes a permission-laundering machine.
• No record of the grounds. Many systems log the answer and discard the evidence. When an action was taken on the basis of a retrieved passage, the passage is the justification — and a decision you cannot reconstruct is a decision you cannot defend, tighten, or safely repeat.
• Chunking that severs the condition from the rule. “Refunds are permitted” and “…within 30 days, excluding annual plans” landing in different chunks is a text-quality annoyance and an execution-grade bug.
• Unbounded scope. If the agent can act on anything it can read, the blast radius of a bad document is the whole system. A finite action catalogue keeps a retrieval error an inconvenience instead of an incident.

Being straight about status matters more than sounding finished. Shipped: the knowledge layer (import and indexing with tenant isolation), the data layer used to verify state before anything is proposed, and roles — Owner, Editor, Viewer — with tenant-scoped permissions. In private beta: chat end to end, and the Actions and Policy Engine that turn a grounded proposal into a governed, logged execution. The trust chain is how the product is designed and built; the action half of it is not yet generally available, and we will not pretend otherwise.

One more constraint worth stating plainly, because it decides who we are a fit for: ai.NEST is delivered as a managed, dedicated, EU-hosted instance. We do not ship a self-hosted distribution. The reasoning — and the honest trade-offs — are in the managed alternative to self-hosted AI. If you want the shorter version of the whole thesis, it is on our about page.

The bet underneath all of this is simple. Retrieval quality will keep improving and keep commoditising. What will not commoditise is the governed path from a piece of knowledge to a completed operation, with a record that holds up when someone asks why it happened — a record that also makes evidence for regimes like DORA or the AI Act far cheaper to produce.