A chat demo is a weekend. Putting that demo in front of paying customers is usually a quarter, because the model was never the hard part.
I kept hitting the same six problems while wiring agents into other people's SaaS products. Isolation, citations, permissions, a real computer, work that outlives the request, and a cost number you can actually bill back. Each one is "just engineering" until it isn't.
This is the shape that held.
1. Keeping customers apart
If tenant id comes from the request body, someone will change it. If it lives in a metadata filter on a shared vector index, one forgotten filter= leaks another customer's neighbors. Namespaces help. They still don't cover the cache, the logs, or the write path.
The boundary has to be in the data plane: a project is a tenant, the API takes the tenant from a short-lived token, never from the body. A missing filter should fail closed, not fan out.
2. Grounding the answer
"Here are some chunks" is not a citation. Founders of document-heavy products need document, page, and quote, or they need the model to refuse. Layout-aware parsing matters; OCR only on the pages that need it matters; a reindex when you swap embedding models matters.
If you cannot point at the clause, do not ship the sentence.
3. Deciding who may do what
Tool calling makes prompt-injection load-bearing. A permission system the model can talk its way past is not a permission system. Capabilities belong on the token, intersected with a project ceiling, checked again per request. A tool the model decides to call without the capability is refused before it runs.
4. Letting it do real work
Answers are half the product. The other half is: clean this CSV, chart it, hand me a PNG. That means a Linux sandbox per conversation, files in and out, no network unless you allow it, idle sleep, and an audit trail. Rolling your own is a graveyard of leftover containers.
5. Outliving the request
"Every Monday, summarise new filings" dies the first time you deploy on a Sunday. You want durable one-shot and cron, DST-safe, signed webhooks, retries, dead letters. The schedule is part of the agent, not a sidecar you forget.
6. Knowing what it cost
Provider invoices arrive a month late and they are not per customer. If you cannot slice spend, latency, and traces per project and per end-user as the calls happen, you cannot bill it back and you cannot cap it.
What I shipped
I got tired of rebuilding those six, so they are the product. Oberik is the agent layer you drop into a SaaS: mint a capability-scoped JWT from your backend, stream the answer into your own UI. Your models, your keys, your product. Free while we launch.
Docs need no signup: https://oberik.com/docs
If you are mid-LangChain on a multi-tenant app, I would rather you try this than spend the quarter on Pinecone namespaces. Roast the landing page if it is wrong for you.
Top comments (0)