An assistant inside a product you already ship
An assistant embedded in a product you already ship, scoped to that signed-in user's own data and permissions.
“Our users keep asking support the same questions they could answer themselves if the product could just tell them.”
What does the system look like?#
How does a request move through it?#
- Ask inside the product
A user asks a question or requests an action from wherever they already are in the product, not a separate chat window bolted on elsewhere.
- Assemble in-product context
The current record, page, and the user's own permission set are pulled into the prompt automatically, so the user never has to explain who they are or what they're looking at.
- Call through a model gateway
The request goes through a model-agnostic call layer rather than a hardcoded SDK call, so a provider change is a config edit, not a rewrite.
- Route through scoped tools only
Tools reach only the product's own APIs, scoped to exactly what an in-product assistant needs, never a broader internal surface.
- Treat retrieved and product content as untrusted
Anything the assistant reads from the product, a ticket, a note, a field a user filled in, is validated before it can drive a tool call, the same as an anonymous request would be.
- Scope every action to the signed-in user
A tool call inherits exactly the permissions the signed-in user already has, never the assistant's own broader service account.
- Trace and eval every turn
Every question and action is traced and sampled into an eval and injection-red-team review, the same discipline as any other production AI feature.
What are the pieces, and what breaks without each one?#
Context assembler
Pull the current record, page state, and the user's own permission set into the prompt automatically.
Breaks without it: The assistant answers generically instead of about the specific thing the user is actually looking at.
Model gateway
Route every call through a model-agnostic layer instead of a provider SDK called directly from application code.
Breaks without it: A provider price change or outage becomes a rewrite across every call site instead of a config change in one place.
Scoped tool router
Expose only the product's own APIs the assistant genuinely needs, never a broader internal surface.
Breaks without it: A successful injection or a wrong model decision can reach far more of the product than the assistant's actual job requires.
Injection guard
Treat anything read from product content, tickets, notes, uploaded files, as untrusted input, the same as an anonymous request.
Breaks without it: A note or ticket crafted to read like an instruction gets executed with the assistant's real tool access.
Permission scoping
Execute every tool call under the signed-in user's own permissions, never a broader service account.
Breaks without it: One user's assistant session can read or act on data that user could never see through the product's own UI.
Trace & eval loop
Log every turn and sample a slice into a golden set and an injection red-team review.
Breaks without it: A quality or safety regression ships and is discovered by a user, not by the team that shipped it.
Where does this need a decision, not a default?#
| Decision | Default choice | Why |
|---|---|---|
| Model gateway | Build a thin abstraction layer in front of whichever provider you start with, sized to your actual call sites | You do not need a full routing product on day one, but hardcoding one provider's SDK into product code is exactly what turns the next price change into a rewrite. |
| Tool access | Wrap the product's existing internal APIs rather than build new endpoints just for the assistant | A parallel API surface built only for the assistant tends to drift from the permission model the rest of the product already enforces. |
| UI surface | Embed the assistant in existing product chrome, contextual to the page a user is already on | A separate chat panel that does not know what the user is looking at pushes the context-gathering work back onto the user, which defeats the point. |
| Observability | Add a dedicated LLM trace store rather than stretch an existing APM tool to cover prompts and tool calls | General-purpose APM was not built to store or query full prompt and completion text, and bolting that on tends to produce a worse version of a purpose-built trace store. |
What actually drives the bill?#
- Token volume that rides along with product usage, not a fixed feature cost
- Context-assembly calls into the product's own APIs on every turn
- Tool calls into product backends per action the assistant takes
Dominant cost Token volume scaling with active seats rather than a flat per-feature number, so cost per active user matters more than a single aggregate estimate.
The lever A model cascade for simple in-product questions plus stable-prefix caching on the (largely fixed) system instructions and tool definitions.
Model your own numbers with the AI Cost Calculator →How do you know it actually works?#
Tool-call argument validation rate
Confirms every tool call the assistant makes traces to a real value, not one it invented.
Injection red-team set against product content
Plants adversarial instructions inside notes, tickets, and uploaded content, beyond the direct chat prompt.
Task completion rate on live traffic
Tracks whether the assistant is actually resolving what users ask, past whether it answered fluently.
Drift detection against a live-traffic sample
Catches a provider-side model update that silently changes behavior between releases.
What will your reviewers ask about this?#
Attack-surface mapping for every content ingestion point
Every place untrusted product content reaches the model is named, with what is reachable downstream of it.
Secrets held out-of-band from the model context
Credentials for tool calls are injected by the orchestration layer directly, never placed in the prompt the model reasons over.
Field-level minimization on assembled context
Only the fields the current turn actually needs enter the prompt, not the full record by default.
Which patterns and failure modes tie in?#
How long does a first version actually take?#
6-10 weeks to a first scoped assistant inside one part of the product, most of it spent on tool scoping and the injection threat model, not the model call itself.
When is this the wrong shape?#
- The product has no clean, scoped API for the assistant to call yet. Automating a UI nobody wired up for machine access first is its own project, ahead of this one.
- You want the assistant to act with the same broad permissions for every user. That is exactly the blast radius this architecture exists to bound, not a shortcut it supports.
- The task the assistant would help with is rare enough that a good search bar or a help article already solves it for most users.
Sources
- OWASP - OWASP Top 10 for Large Language Model Applications
The ranked risk list our security review checks are organised against. Retrieved 2026-08-24.
- MITRE - MITRE ATLAS
The catalogue of adversary tactics against AI systems our findings are labelled with. Retrieved 2026-08-24.
A Ship Audit checks which of these an existing or planned system actually needs, against what is most likely to break first.