Blog · 2026-06-05
Four People, One RAG Platform — and What They Actually Need
A multi-tenant RAG platform does not sell on features. It sells on the problems of real roles: the IT lead with no DevOps team, the knowledge officer who has to answer for what the bot says, the DevOps engineer at a regulated insurer, the CISO who has to sign off. Four people, four constraints — and what the platform does for each of them.
Product pages show features. But nobody buys a feature — what gets bought is the solution to a specific problem that a specific person has. So for our multi-tenant RAG platform we wrote down the people first and the functions second. Four of them appear here, with what they actually say and with what the platform does about it. If you recognise yourself in one of them, you will know afterwards whether the offer fits you.
Anna wants to arrive, not to onboard
What the platform does for Anna. She creates her tenant herself, points
it at the OIDC provider she already has — her Microsoft Entra — and starts
connecting sources straight away, with no sales call in between. Her
Confluence goes in through a ready-made connector; after the first push she
has a chat endpoint with an API key that she can hit from outside via curl,
with no further configuration. Every tenant gets its own container stack: one
tenant, one stack, one predictable line item — not a bill that grows with
every page indexed. And where that stack runs is part of the contract, not a
quiet US default.
Claus is accountable for what the bot says
What the platform does for Claus. Every tenant has two states: a stage to try things out on, and the live state that end users see. Claus tests changes against the stage — he sees how the bot actually answers with the new text before anyone outside lays eyes on it. A diff preview shows what changes relative to live; one click promotes the stage to the live state. Nothing reaches a customer that Claus has not seen first — and "let's just test it in production" stays what it should be: a test, not a risk.
Dirk is not allowed to hand anything over
What the platform does for Dirk. For tenants with stricter requirements the connector runs as an agent inside Dirk's own cluster — as a container image he rolls out declaratively, not as a web installer he clicks through. What matters is what leaves that agent: only chunks and vectors travel to the platform, not a single byte of raw content. The answer to the regulator's question — "where does the data go?" — is therefore: it stays in the building. An SBOM ships with it, the audit log is available locally too, and his configuration lives as YAML in his GitOps repo, with four-eyes review and rollback by revert.
Erika signs off — or does not
What the platform does for Erika. She gets documents rather than a slide: a threat model that names which threats are covered and which are not; an audit trail built on GDPR logic; a sub-processor list. Because every tenant holds its own key, deletion is provable — the key is destroyed, and everything encrypted with it becomes unreadable, backups included. That is proof resting on mathematics rather than on the completeness of a search. It lets Erika explain to her board, on a single page, where data sat, who could see it, and how it leaves again.
Why it takes the combination
These four have little in common — except that no off-the-shelf solution serves all of them. Generic SaaS RAG tools give Anna her self-service but not Dirk's "not one byte leaves the building". A home-built wiki bot gives Dirk his control but neither Anna's quick start nor Claus's preview. Only the combination closes the gap: two ways to connect content — an agent for those who may not hand anything over, an upload for those who want convenience — plus a container of its own per tenant and the customer's own identity provider. That way each of the four finds their own path without having to carry the compromises of the others.