# The Assistant answered about the wrong record

The Assistant is told which screen you are on and which record is pinned to the tab, and it checks that claim against the database before trusting it. An answer about the wrong record almost always means the pin is older than your attention: you moved on, the tab did not. Clearing the pin, or naming the record in the question, fixes it immediately.

- **Status:** Available
- **Audience:** both
- **In the app:** #/home
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/assistant-wrong-context/

## What you are seeing

You ask about the person or the deal in front of you and get a confident, well-formed answer about a different one. The answer is usually correct about the record it chose — which is what makes it convincing and what makes it worth catching quickly.

Open the folded step list on the answer before anything else. It names the records the tools were asked about, and that single glance separates 'it read the wrong record' from 'it read the right record and reasoned badly', which are different problems with different fixes.

## The two context sources, and which wins

| Source | Set by | Lasts until |
|---|---|---|
| The screen context | Navigating; the route and the record on it are sent with your message | You navigate somewhere else |
| The pinned record | Pinning a record to the tab, or the Assistant resolving one during a turn | You clear it, or you pin another |
| The conversation | The records already discussed in this tab | The tab is closed |

A pinned record is the strongest of the three and that is the point of it — you can walk around the app while keeping one customer in view. It is also why it causes this problem: nothing about navigating away clears it, because clearing it on navigation would destroy the reason to pin.

> **Note** The screen context claim is checked against the database before it is used. If the claim and the workspace disagree — a record that has been deleted, or one your session may not read — the claim is dropped rather than trusted. That check prevents a wrong answer about a record you cannot see; it cannot prevent a right answer about a record you have stopped caring about.

## What Connect completed, and what it did not

**What Connect completed** — A genuine read of a real record, with citations naming it. The evidence trail is intact and points at what was actually used.
**What Connect completed** — The context check. Whatever record was answered about is one this session is entitled to read.
**What Connect did not complete** — The question you meant. Nothing about the record you were looking at was consulted at all.
**What Connect did not complete** — Any write, unless you confirmed one. If you did confirm an action while the context was wrong, that action landed on the wrong record and is worth [undoing](/docs/workflows/assistant-undo/) now rather than later.

> **Careful** This is the failure most worth checking before confirming a proposal. A proposal names the record it will act on; reading that line is a two-second habit that prevents an edit applied to the wrong customer.

## What you can do

1. Clear the pin on the tab.
   - Result: The next question uses the screen you are actually on, and the answer changes accordingly.
2. Or name the record in the question — the company, the person, the thread.
   - Result: A named subject in the question outranks an inherited one, so this works without touching the pin.
3. Or open a new tab for the new subject.
   - Result: Each tab keeps its own record, conversation and files, which is the intended way to hold two lines of enquiry at once instead of switching one back and forth.
4. Re-ask and check the step list, not just the answer.
   - Result: Seeing the right record named in the steps is the proof; a plausible answer is not.

## What an administrator can do, and when to escalate

There is little for an administrator here in the ordinary case, because nothing is misconfigured — the pin did exactly what pins do. What they can usefully check is whether the person is looking at the workspace they think they are, since a session belonging to one workspace and a bookmarked screen from another produce exactly this symptom on the first question of the day.

Escalate when the answer concerns a record from outside the workspace, or one the person has no right to read. That is not a context problem, it is an isolation problem, and it should be reported immediately with the record type and the screen — not with the record's contents.

## Questions

### How do I see what the Assistant thinks is on my screen?

Ask it. `record_context` is a read-only tool and answering 'what record are you working on' costs one step and settles the question faster than inspecting anything. [Checking the screen context](/docs/workflows/assistant-context-check/) does this properly.

### Does closing the tab clear the pin?

Yes, along with that tab's conversation, draft and files. If you want the conversation but not the pin, clear the pin instead of closing the tab.

### Can the Assistant answer about a record I am not allowed to see?

No. The context claim is verified against the database under your session, and row-level security applies to every read the tools make. A claim that does not survive that check is discarded.

## Related

- [Screen awareness](https://connectbyjbrh.com/docs/assistant/screen-context/)
- [Working on one record](https://connectbyjbrh.com/docs/assistant/record-context/)
- [Checking the Assistant's screen context](https://connectbyjbrh.com/docs/workflows/assistant-context-check/)
- [Troubleshooting](https://connectbyjbrh.com/docs/troubleshooting/)
- [Three independent layers of tenant isolation](https://connectbyjbrh.com/research/three-layers-of-isolation/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §8 — the screen context checked against the database
- Connect capability registry (docs-source/facts.py) — `assistant_tabs`, `rls_isolation`
- `backend/app/manager.py` — context resolution and verification