Documentation is not product context.
Design the context contract that joins stable knowledge, live data, current screen, identity, permissions and eligible tools.
Short answer
Documentation says how a product should work. Product context says what is happening for this user now. Keep those layers separate and join them through a typed context contract: validated identity, route, active entity, tenant or site, effective permissions, relevant knowledge, live observations and eligible tools. Retrieve and observe only after the access boundary is known. The model receives a controlled view, not authority to decide what it may see.
Key points
- 01
Stable knowledge and changing state need different sources and freshness rules.
- 02
The context envelope should be typed, minimal and derived server-side.
- 03
Security filters happen before model context assembly.
01 / SITUATION
A correct article can still produce the wrong answer
A help article may correctly explain how approval works while the current record is incomplete, the workflow has changed or the user lacks the relevant role. Retrieval quality cannot solve that mismatch because the missing information is not in the document corpus.
The architecture should therefore treat documents, live state and tools as different evidence classes. Each class has its own authority, freshness, access checks and failure modes.
02 / MECHANISM
The context envelope
Build one server-owned object that describes what the assistant may know and do for the current turn.
- 01Identity
User, organisation, tenant or site and effective role, resolved from the authenticated session.
- 02Navigation
Validated route, module, selected entity and product version or feature state where relevant.
- 03Access
Read and write boundaries calculated by the host application. These are data, not prompt advice.
- 04Knowledge
Permitted stable sources with identifiers, versions and retrieval scores useful for evaluation.
- 05Observations
Live tool results with scope, timestamp, partial or empty status and safe provenance.
- 06Eligible tools
A reduced list of typed operations available for this role and workflow, including when not to use them.
03 / In real work
Policy versus current status
A policy document defines the approval rule. A read tool reports whether the current request satisfies it.
Navigation versus authority
The browser route suggests a record. The server resolves the record again inside the signed-in tenant before loading it.
Knowledge versus tool
A guide explains the process. A tool confirms whether the next step is currently available.
Common failure modes
- Combining every input into an untyped prompt string.
- Using browser-provided scope without server validation.
- Allowing retrieved text to override deterministic access rules.
- Caching live state without a freshness contract.
- Passing tool results without status, provenance or error semantics.
Implementation checklist
- Context classes are named and typed.
- Identity and scope come from the authenticated host.
- Stable knowledge and live state have separate freshness rules.
- Retrieval applies access filters before generation.
- Tool results preserve empty, denied, partial and failed states.
- Eligible tools are reduced before model selection.
- The final envelope can be inspected in redacted traces.
What this approach does not claim
- A context contract must be adapted to the host product’s data and access model.
- Provenance does not guarantee that the underlying source is correct.
- Some questions still require clarification because no system holds the missing fact.
Sources and reference types
- 01Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksLewis et al. · 2020Research
- 02ReAct: Synergizing Reasoning and Acting in Language ModelsYao et al. · 2023Research
- 03Model Context Protocol specificationMCP maintainers · 2025-11-25Standard
- 04AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Research
Practical questions
Should the context envelope be shown to users?
Not in full. Show useful evidence and limits. Keep internal identifiers, policies and sensitive traces out of the interface.
Can one context service support several assistants?
Yes, if each surface requests a purpose-specific view and retains its own identity and tool boundary.
Is this just a richer RAG pipeline?
No. Retrieval is one stage. Product state, access, tools, action gates and traces belong to the wider control graph.