Key Takeaway
AI features that hold up in a multi-tenant SaaS need tenant isolation, permission-aware retrieval, evals and cost controls built into your data model, not a chatbot on the side.
Your customers have started asking. Some ask in sales calls. Some ask in churn surveys. A few have already shown you what a competitor shipped.
The fast answer is a chat widget that sends questions to a model with some help docs attached. It takes a sprint. It also tends to get used for a week and then ignored, because it doesn’t know anything about the customer’s own data and can’t do anything in the product.
The features customers actually come back for are different. They answer questions about the customer’s own records. They take actions in the app. That puts them right in the middle of your data model, your permission system and your multi-tenant architecture. That’s also why they’re hard.
Why teams get stuck
Retrieval-augmented generation sounds simple. Embed your content, store it in a vector database, fetch the relevant chunks and pass them to a model. Tutorials cover it in twenty minutes.
Those tutorials assume one user and one dataset. Your product has thousands of tenants, each with its own data, and users inside each tenant who can see different things. A retrieval system that ignores those boundaries is a data breach waiting for the right query.
Agents add another layer. Once a model can call your APIs, every permission question you’ve answered for your UI comes back again. Can this user delete that record? Should the agent be allowed to, even if the user can?
Your engineers can absolutely learn this. But they’re also carrying the roadmap, and these decisions are expensive to get wrong in the first version.
What we build
Retrieval with tenant isolation
Isolation comes first, before anything else gets built.
Depending on your scale and compliance needs, we isolate tenants with separate indexes or namespaces per tenant, or with a shared index and mandatory metadata filters enforced at the query layer. The choice affects cost, performance and how hard it is to prove isolation to an auditor, so we make it with you based on your actual tenant distribution.
Either way, the tenant boundary is enforced in code your application controls. It never depends on the model following instructions. The model never sees a query result that crossed a tenant line, because the retrieval layer never returns one.
Permission-aware retrieval
Tenant isolation isn’t enough on its own. Inside a tenant, a sales rep shouldn’t retrieve HR documents just because they’re in the same workspace.
We carry your existing permission model into retrieval. Each indexed chunk keeps the access metadata of its source record. At query time, retrieval filters by what the current user can see, using the same rules your application already applies. When permissions change in your app, the index reflects it.
This is the part most teams underestimate. Getting it right means understanding your authorization system in detail, including the edge cases like shared links, archived records and role inheritance.
Retrieval quality
Once retrieval is safe, it has to be good. We tune chunking to your content types, since a contract, a support ticket and a product record need different handling. Most products benefit from hybrid search that combines vector similarity with keyword matching, plus a reranking step. We measure retrieval quality directly with eval sets, separate from answer quality, so you can tell whether a bad answer came from bad context or from the model.
In-product agents that take real actions
The agent layer turns your product’s capabilities into tools the model can call. Each tool has a typed schema, a clear description and a server-side implementation that runs through your existing business logic and authorization checks.
The agent acts as the user, with the user’s permissions. If the user can’t archive a project in the UI, the agent can’t archive it either. The tool layer enforces this, not the prompt.
For actions that change data, we build confirmation into the interface. The agent proposes what it’s about to do and the user confirms. Read-only actions can run immediately. Destructive or bulk actions get an extra step. Every tool call is logged with the user, tenant, inputs and result.
Supporting infrastructure
Behind the features sits the infrastructure you’ll run long after launch:
- An embeddings pipeline that indexes new and changed records incrementally, with backfill for existing tenants
- Vector storage sized for your data, often in a database you already run, such as Postgres with pgvector
- Evals for retrieval, answer quality and tool use, running in CI on every change
- Cost controls, including per-tenant usage tracking, rate limits and model routing so simple requests use cheaper models
Where humans stay in control
Your users stay in control of their data. Agents propose and users confirm before anything changes. Your team stays in control of the system, with a kill switch per feature and per tenant, usage dashboards and traces for every request. When a customer asks why the assistant said something, support can look it up.
What makes it production-grade
A demo answers questions about sample data for one user. A production feature does that for every tenant and every role, under load, at a cost you can predict. It also has to pass your security review.
That means isolation you can demonstrate, permissions you can test and evals that catch regressions before customers do. It means the index stays in sync with your data, and the feature degrades gracefully when a model provider has a bad day.
Your part
Tell us the feature you want and the problem it solves for customers. Give us repo access and a product owner who can sign off on the spec and the confirmation flows. We’ll need about an hour with whoever knows your authorization model best.
How the build works
You describe the feature. We scope it with you and agree on a fixed price tied to what gets delivered, before work starts.
AI agents do the build under the supervision of senior engineers, who own the architecture, the tenancy and permission design, and every code review. The result is production-grade code in your repo, following your conventions, documented and handed over so your team can maintain and extend it. Your engineers stay on the roadmap while it gets built, and you own the code and infrastructure from day one.
Delivery takes days to weeks, depending on scope.
Frequently asked questions
Do we need a new database for vectors?
Often not. If you run Postgres, pgvector handles a lot of workloads. We recommend a dedicated vector store only when your scale or query patterns need one.
How do you prove tenant isolation to our customers?
Isolation gets enforced at the retrieval layer and covered by automated tests that try to cross tenant boundaries. We document the design so your security team can walk customers through it.
What does it cost to run?
It depends on usage and model choice. We build per-tenant cost tracking in from the start so you can price the feature with real numbers.
Can we build the agent features first and add RAG later?
Yes. The tool layer and the retrieval layer are separate. Many products start with agents that act on structured data and add document retrieval in a second phase.
