Screen awareness
The Assistant is told which route you are on and which record that page is showing, so 'summarise this' has a subject. That claim arrives from the browser and is therefore not trusted: every identifier it carries is re-read from the database, inside your workspace, before the model sees it. Anything that does not resolve is dropped rather than described.
What is sent#
The context is small and specific. It is the hash route you are on, the type and identifier of the record the screen is displaying, and — if you have highlighted something — the text you selected. It is not a copy of the page, not a screenshot, and not the contents of every row in a list you happen to be scrolling.
| Element | Example | Why it is there |
|---|---|---|
| Route | #/inbox, #/pipeline, #/calls | Tells the Assistant what kind of work you are doing |
| Record type and id | a person, company, deal, thread or call | Gives 'this' and 'they' something to resolve to |
| Selection | text you highlighted before asking | Narrows a question to one passage — see Asking about selected text |
| Pinned record | set in the tab rather than by the page | Overrides the screen when you have deliberately chosen a subject |
The check that runs before it is believed#
Screen context is a claim made by a browser about what a browser is showing. Treating it as fact would mean the model could be pointed at a record by anything able to put an identifier into a request — including a stale tab left open after a row was deleted, and including a deliberately altered one. So the identifiers are verified against the database before the model is given anything at all.
The verification is an ordinary read through the workspace-scoped path, which means the three isolation layers apply to it exactly as they apply to a screen: the tenant allowlist in the middleware, the SQLAlchemy workspace kernel, and row-level security in PostgreSQL. A row belonging to another workspace does not come back as forbidden — it comes back as nothing, because to that query it does not exist.
- The panel sends the route, the type of thing on screen and its identifier.
- Connect reads that row inside your workspace.
- If it resolves, the verified row — not the claim about it — becomes context.
- If it does not resolve, the context is dropped and the model is told nothing about a subject rather than something wrong about one.
What this does not protect against#
The check proves that a row exists and is yours. It does not prove it is the one you meant. If you are on a company page and ask about 'the last call', the Assistant will resolve that against that company; if you were thinking of a different account you saw a moment earlier, the answer will be correct about the wrong thing.
Nor does it make the contents of a row trustworthy. A thread's body is text somebody else wrote, and instructions hidden inside inbound mail are treated as content to be reported, never as directions to be followed. Prompt injection arrives as ordinary business mail covers that boundary.
Making the subject explicit#
Pin the record you mean in the tab, rather than relying on the page underneath.
Result Every question in that tab resolves against it, including after you navigate somewhere else.
Name the thing in the question — 'the renewal deal for Acme Traders', not 'this one'.
Result The Assistant has a way to disambiguate without guessing, and its answer names what it used.
Select the passage you are asking about when the page is long.
Result The question is scoped to that passage instead of to the whole record.
Questions#
Does the Assistant see my whole screen?
No. It receives the route, the identifier of the record on display and any text you selected — not the rendered page. Everything it knows about that record is then read from the database rather than from the browser.
What happens if the record was deleted while I had the page open?
The identifier no longer resolves, so the context is dropped. You get an answer that has no record behind it rather than one describing a row that is gone, and reloading the screen shows you the same thing.
Can screen context reach another workspace's data?
No. The read is scoped by the same three layers every other read uses — the allowlist, the workspace kernel and row-level security — so an identifier from elsewhere resolves to nothing at all.