# A useful assistant starts with the situation.

Identity, screen, live state and permissions change the right answer. Learn how to assemble the smallest useful context before generation.

Version 1.0 · 2026-07-29 · 8 min

## Short answer

Documentation explains stable rules. A useful answer also depends on who is asking, where they are, which record is active, what the system knows now and what the person may do next. Resolve those facts before generation. Filter restricted knowledge before it reaches the model, retrieve only what is relevant and expose only the tools valid for the current workflow. Context is not a larger prompt. It is a controlled view of the situation.

## Key points

- Treat browser state as a hint until the server validates it.
- Separate stable knowledge from live product state.
- Build the smallest useful context instead of sending everything.

## The same sentence can require three different answers

“Can I approve this?” is not a documentation question. A customer may only see status. An operator may correct missing information. An administrator may review an approval proposal. The wording is identical, but identity and current state change both the evidence and the next step.

When these distinctions are left to a prompt, the model is being asked to recreate an access-control system from text. That is fragile by design. The host application should establish the boundary first, then give the model a view that already respects it.

## Build context in a fixed order

Ordering matters because later stages should never widen a boundary that an earlier stage closed.

### 1. Identify

Resolve the signed-in user, tenant, site and effective role from the host application.

### 2. Validate the screen

Check the route, selected record and module on the server. A browser-provided identifier is not authority.

### 3. Retrieve knowledge

Search permitted documentation and stable knowledge using filters before ranking and generation.

### 4. Observe live state

Use scoped read tools for facts that can change, including status, history and available options.

### 5. Select eligible tools

Expose only operations relevant to the module, role and workflow. A denied tool should not enter the candidate set.

### 6. Return evidence and limits

Distinguish an empty result, missing evidence, denied access and a tool failure. They demand different next steps.

## Examples

### A maintenance procedure

The document is stable. Equipment state, site, operator certification and open work order are situational. Both layers are needed.

### A finance exception

Policy explains the rule. The current entry, account period, attachments and role explain whether this person can resolve it.

### A product support question

The guide explains the feature. Plan, current configuration and screen explain which instructions apply now.

## Common failure modes

- Trusting tenant, role or record identifiers sent by the browser.
- Sending the complete knowledge base to the model and calling it context.
- Using stale documents for facts that belong in a live tool.
- Treating no result and no access as the same state.
- Letting semantic routing override a deterministic security decision.

## Checklist

1. Identity is resolved by the host product.
2. Page and record context are server-validated.
3. Knowledge filters are applied before generation.
4. Live tools use the same tenant and role boundary as the UI.
5. Tool eligibility is reduced by workflow or module.
6. Evidence includes source type and freshness where useful.
7. Empty, denied, partial and failed states are tested separately.

## Limitations

- More context can lower quality when irrelevant details compete with useful evidence.
- Retrieval cannot compensate for missing or contradictory source material.
- Current state may change between answer and action, so writes require a fresh server-side check.

## Sources

1. [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/wp-content/uploads/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf) — Amershi et al., Microsoft Research, 2019; type: research.
2. [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://arxiv.org/abs/2005.11401) — Lewis et al., 2020; type: research.
3. [ReAct: Synergizing Reasoning and Acting in Language Models](https://openreview.net/forum?id=WE_vluYUL-X) — Yao et al., 2023; type: research.
4. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks](https://openreview.net/forum?id=m1YYAQjO3w) — Debenedetti et al., 2025; type: research.

## Practical questions

### How much context should be sent to the model?

Only what the current question and workflow require. Measure retrieval and answer quality as context changes instead of assuming that more is safer.

### Can the model decide which permissions apply?

No. It may explain a policy result, but the host application should calculate and enforce access deterministically.

### What if the current screen is not enough?

Use it as one signal. The system can ask a focused clarification or call an approved read tool rather than inventing missing state.

---

Canonical: https://scoperail.fokalabs.io/en/guides/why-ai-assistants-need-context
Author: Ramzi Laieb, FokaLabs