Checking the Assistant's screen context
When you ask the Assistant something, the browser sends a claim about where you are: this route, this record. The claim is not believed on sight. It is checked against the database in your workspace before any of it reaches the model, and a claim that does not hold is dropped rather than corrected — which is why an answer can be usefully specific and can also say it does not know what you meant.
The path a context claim takes#
- Trigger — you open the Assistant, or send a message in a tab that is already open.
- User event — the tab posts your text together with the route you are on and any record it believes is pinned.
- Authentication and workspace resolution — the session resolves the workspace before a single row is read; an operator session and a customer session take different API paths to the same service.
- Ingest — the message joins that tab's conversation, which is the only history the model will be given.
- Canonical record — the claim is checked. The identifier is looked up in your workspace, and what comes back is the record as stored, not the version the browser was holding.
- Reasoning — only what survived the check is described to the model. A dropped claim leaves the model with your words and nothing else.
- Knowledge, memory and rules — grounding is assembled to a fixed budget: roughly 2,000 characters and four facts of Knowledge, about 700 characters of memory, about 600 for the contact block.
- Autonomy and approval — not consulted at this stage. Establishing where you are changes nothing.
- Action — the tools the model chooses run against the verified workspace, so a tool cannot reach a record the check just refused.
- Result — the answer refers to the record by name when the claim held, and asks which one you mean when it did not.
- Relationship and timeline — nothing is written by the check itself; a question is not an event in a relationship.
- Audit and usage — the model call is metered against the workspace's budget. No decision-log entry is made, because no decision was taken.
Stage five is the whole page. Every other stage would work identically if the browser were simply believed — and an assistant that believes the page it is sitting on is an assistant that can be told anything by a stale tab.
What is claimed, and what is verified#
| The browser claims | What is verified | If it does not hold |
|---|---|---|
| A route — the screen you are on | That it is a real route in this application | The route is ignored; the question is answered without it |
| A record identifier | That the record exists and is visible to this workspace | The record is dropped, not substituted |
| A record's fields, as rendered | Nothing — the stored record is re-read instead | The rendered copy is never the source of an answer |
| Selected text you highlighted | Treated as text you typed, because it is | Nothing to verify; it carries no authority of its own |
The third row is the one that surprises people. Even when the claim holds, the values the model sees come from the database rather than from the screen. A page left open while somebody else edited the record answers with the new values, not the ones in front of you — and that is the correct behaviour, because the record is the fact and the screen is a photograph.
Why the check exists at all#
A claim about which record you are looking at is input from the browser, and input from the browser is input from whoever can reach the browser. Without verification, a crafted or simply stale request could name any identifier and get an answer about it. The check turns that into nothing: an identifier outside your workspace does not resolve, so there is no answer to give.
It sits alongside the isolation the platform already has rather than replacing it — the tenant allowlist in the middleware, the workspace kernel in the data layer, and row-level security in PostgreSQL. The context check is the layer that matters for this particular mistake: a request that is authenticated, permitted and pointed at the wrong thing.
- A dropped claim is not an error. The question is still answered; it is answered with less to go on.
- Nothing is guessed in its place. Connect does not pick the nearest similar record, because a confident answer about the wrong customer is worse than a question back.
- The tools inherit the same boundary. A read tool cannot fetch what the check refused.
What you see when the claim is dropped#
- A question instead of an answer
- The most common outcome: the Assistant asks which record you mean, because you referred to *this one* and there is no this one.
- An answer that is general where you expected it to be specific
- Your question stood on its own well enough to answer without a record, so it was.
- A repeat of a name you did not expect
- Usually a pinned record in a tab you had forgotten — each tab keeps its own record, and the tab you are typing in is the one that counts.
- No visible difference at all
- The claim held. That is the normal case and it announces nothing.
If the Assistant keeps answering about the wrong record rather than about no record, the cause is usually a tab rather than the check. The Assistant answered about the wrong record separates the two.
Questions#
Does the check slow the answer down?
It is one lookup in the workspace you are already authenticated to, before any model work begins. Compared with the model call that follows it, the cost is not the thing you are waiting for — and the alternative is not a faster answer but a less trustworthy one.
Can I make the Assistant answer about a record I am not looking at?
Yes — name it in the question. Naming a record sends the Assistant to look it up with a tool, which runs against your workspace under the same isolation. What you cannot do is have a screen claim carry a record the check would refuse; the two routes end at the same boundary.
What happens on a page with no record at all?
Nothing is claimed beyond the route, so nothing is dropped. The Assistant answers from the conversation, from Knowledge and memory, and from whatever its read-only tools find. Opening it on a list screen and asking a general question is a perfectly normal way to use it.