One Engine, Three Embedded Assistants: How Every Answer Stays Scoped

Three people, three products, three questions:

• Alex, a shopper on the Northmart storefront, types "I was charged twice for my last order."
• Dr Okafor, a GP in the middle of a video consult, asks whether metformin is safe for the patient on screen.
• Priya, a claims agent with a policyholder on hold, needs a roadside-assistance quote and wants to know whether similar claims get flagged.

Each of them gets a specific, sourced answer in seconds, inside the product they were already using. Behind all three is a single Wren AI engine. And none of them can see a single row that belongs to someone else.

We recorded a two-minute walkthrough of all three. This post explains what is going on inside each session, because the interesting part isn't that an AI can answer the question. It's what the answer is not allowed to include.

The hard part of embedding is the boundary

Putting a chat box in your product is a weekend project. Putting one in front of real customers, on real data, is not, because a natural-language interface has no built-in edges. A dashboard only shows what someone laid out. A question box accepts anything: "show me all orders over $500", "which patients are on warfarin", "list every claim from this zip code."

If the only thing between that question and your database is a prompt that says "only answer about the current user", you don't have a control, you have a request. Models follow instructions most of the time. Most of the time isn't good enough for a patient record or a claims file.

So in Wren AI the boundary isn't in the prompt. It travels with the session, and the engine enforces it on every query.

Step 1: the host signs who is asking

Every embedded session starts with the host application, not with Wren. The host already knows who is signed in and what they are looking at, so it puts that into a signed session token.

Here is the token the Harbor & Pine agent desktop issues when Priya picks up a verified call:

Three things are worth noticing:

• Identity is the host's, not the user's. The token is signed by the Harbor & Pine backend. The caller can't type a different policy number and widen the scope, because the scope never came from the chat.
• Session properties carry the context. agent_role, policy_id, and claim_id are what "this policy" and "my claim" resolve to.
• The token has a lifetime. It is issued when the caller is verified and revoked when the call ends. The next call gets a new token with a new scope.

The clinical workspace does the same with different keys: patient_id, clinician_id, and practice_ods. The thread can only query the record that is open in the EHR.

Step 2: the engine scopes the query, not the answer

When a question comes in, Wren AI's agent plans the query through the context layer: the same metric definitions, relationships, and access policies your team modeled once in MDL. Then Wren Engine applies the row- and column-level policies bound to those session properties before the SQL runs.

That ordering matters. We don't generate SQL across the whole database and filter the result afterward. The query that executes can only reach rows inside the session's scope, whatever the model wrote. We covered the mechanics in How Wren AI enforces role-based access control. Embedding is the same mechanism with the identity supplied by your product instead of by a Wren login.

Step 3: the answer shows its work

Scoping makes an answer safe. Sources make it usable. In all three products the reply comes with the rows and SQL behind it, because the person reading it has to act on it.

Retail. Alex's question becomes a lookup over Alex's payments only. Wren finds two $86.47 charges on order #112-7730155. One is settled. The other is an authorization that is still pending and normally drops off in three to five business days.

That answer settles most "charged twice" tickets before they're filed. When it doesn't, Alex clicks Create ticket and Wren hands the case to support with the whole conversation attached. The billing team starts from what was already found, not from "can you describe the issue?"

Healthcare. Dr Okafor asks about metformin. Before answering, Wren checks the patient's record for two things a GP would want to know: the last eGFR is eight months old and down from 52 to 41, and the patient is on ibuprofen alongside ramipril and furosemide, a combination that raises kidney-injury risk. The suggestion: recheck renal function first.

Each flag links to the lab result or prescription it came from, and the SQL is one click away. It's decision support the clinician can verify, not a verdict to trust blindly.

Step 4: some answers are totals only

The insurance demo shows the subtlest part of the boundary. Priya asks for a roadside-assistance quote and gets one priced from the policy's own rating rules: $2.40 a month, prorated to $8.86 for the 112 days left on the term.

Then she asks whether similar claims get flagged for review. That question has to look beyond this policy, so the policy allows an aggregate and nothing more:

37 of 1,284 similar collision claims in the region were referred for review, mostly for late reporting. Individual claim records stay out of reach for Priya's role, and the note is marked agent-only, so it never reaches the caller. Priya gets the benchmark she needs, and no other policyholder's file is exposed.

Why one engine instead of three

You could build each of these assistants separately. Most teams who try it end up rebuilding the same four things for every surface: identity plumbing, access policy, metric definitions, and an audit trail. Then they keep the copies in sync.

With Wren AI those live once, in the context layer. What changes from one product to the next is configuration:

• The surface. Embedded Threads drops the full conversational UI into your app with one snippet and white-label branding. The Embedded AI API gives you governed SQL and charts so you build your own UX. Over MCP, Claude, ChatGPT, or your own agent can call Wren directly.
• The session properties. A shopper ID, a patient ID, or a policy and claim, whatever your product already knows.
• The voice. Your brand and your terminology, so "refund window" or "deductible" means exactly what it means in your product.

The governance doesn't change. A new surface inherits the same boundary on day one.

Try it on your own product

The three products in the video are live, with sample data, at getwren.ai/embedded. Open one, ask the suggested questions, then try to talk your way out of scope. You can also watch the shorter cuts on the demos page.

When you're ready to see it on your own data, request a demo and we'll walk through which session properties your product should pass and which surface fits. If you are weighing building it in-house, the Embedded GenBI build-vs-buy ROI worksheet breaks down the cost.

The demos use sample products and sample data, for illustration only. Answers are read-only. Wren AI does not diagnose, prescribe, or make offers of coverage.