Asking the Assistant a question, end to end

The path a question takes#

1. Trigger — you send a message in an Assistant tab.
2. User event — the tab posts the text with the route you are on and any pinned record.
3. Authentication and workspace resolution — the session decides the workspace before a single row is read; a customer session and an operator session take different API paths to the same service.
4. Ingest — the message joins that tab's conversation, which is the only history the model is given.
5. Canonical record — the screen context claim is checked against the database, so a stale or wrong route cannot make the model answer about a record you cannot see.
6. Reasoning — the model chooses among the read-only tools: find_anything, record_context, customer_360, data_query, search_knowledge, recall and the rest.
7. 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.
8. Autonomy and approval — not consulted. A read changes nothing, so there is nothing to approve.
9. Action — no provider is called. Every tool in this path reads the workspace you are already in.
10. Result — the answer is streamed into the tab, with the status line settling to Done · N steps.
11. Relationship and memory — the turn is kept in the tab's conversation; no memory is written unless you ask for one.
12. Audit and usage — the model call is metered against the workspace's AI budget; no decision-log entry is made, because no decision was taken.

Two stages in that list do work a reader would not guess. The check at stage five is the difference between an assistant that believes the page and one that verifies it, and the budget at stage seven is why an answer is specific instead of a summary of everything the workspace knows.

Stage by stage, with what can fail#

The row worth reading twice is the last one. An answer with no sources is not necessarily wrong — 'what did I just ask you' has no source — but an answer about a customer with no sources is inference, and where an answer came from explains how to tell the two apart at a glance.

Verified success, and what it does not prove#

This flow succeeded when three things are true together: the status line reads Done, the answer names the records it drew on, and those records are ones you can open yourself. The third is the one people skip. An answer that cites a record you cannot open means the citation is describing something outside your access, which is a fault worth reporting rather than a fact worth quoting.

What a successful read does not prove is currency. The Assistant answers from the workspace as it is at that moment; a mailbox mid-sync or a call still in progress is not yet in the records it reads. When timing matters, ask what the most recent item is rather than assuming the answer is complete.

Cost and repetition#

Every question costs a model call, metered against the workspace's AI budget. Reading tools themselves cost only a query. The practical consequence is that asking one precise question is cheaper and better than asking three vague ones, and that pinning the record first removes a search step from every question that follows in that tab.

1. Open the record you are asking about, or pin it in the tab.

   Result The context check confirms it, and later questions in the tab skip the search.

2. Ask the specific question rather than the general one.

   Result Fewer steps, narrower grounding, and an answer that names two records instead of summarising ten.

3. If the answer is not what you expected, open the folded step list before rephrasing.

   Result You see whether the tools found nothing or found the wrong thing — a different fix in each case.

Questions#

Related#

• Answers that change nothing
• Where an answer came from
• Asking the Assistant to do something, end to end
• Knowledge in Connect
• Grounding an answer without pretending to have a vector database