How Chat Works

Chat assembles each turn from your workspace before dispatching it, so the model answers with your Dotabases, your HUMAN.md, and the tools you enabled in front of it. This page covers how that turn is built, how the model reaches your rows, and what is recorded afterwards.

How A Turn Is Assembled

When you send a message, Chat builds a system prompt from four blocks joined in a fixed order: the chat persona, the constraints of the conversation's current mode, the sources enabled for this turn, and the guidance that tells the model how to write inline citations. The enabled-sources block names each Dotabase the turn may reach by label, and names the ones switched off as well, so the model knows the shape of what it has been given.

Around that system prompt sit the rest of the turn's inputs:

• Conversation history — the recent back-and-forth, projected into plain user and assistant messages. Tool calls, mode changes, and status chips stay internal. The most recent forty messages carry; this is a recency cap, not a token budget.
• Your HUMAN.md — the document describing who you are and how you work. It is injected for a remote model, which has no other way to see it, and skipped for a local coding agent, which reads the file off disk itself. You can turn the injection off globally or pick a different document for one conversation.
• An invoked Superpower — a Superpower you pick in the composer is resolved at send time and prepended to the system prompt as content. A Power-Up Playbook goes further and walls retrieval down to the rows it names.
• Attachments — passed through to the model as you sent them.

How The Model Reaches Your Knowledge

Retrieval is something the model does, not something that happens before it runs. Enabling a Dotabase for a conversation does not paste its rows into the prompt; it authorizes the model to go and look. A remote model is offered vault tools and calls a search tool when it decides it needs something, choosing keyword, semantic, or hybrid matching per query. A local coding agent retrieves through the dots CLI instead, the same way you would from a terminal.

What comes back is a compact projection rather than a whole row — a human-id, a title, a short snippet, its DIIICE type, and its tags — so the model spends its context on what it chose to open. The enabled sources are a hard wall around all of it: a Dotabase you did not enable reads as absent, so a turn cannot leak even the existence of knowledge it was not given.

How A Turn Is Dispatched

The assembled turn goes to the model you chose. Chat runs each conversation as its own queue, so turns within one conversation are handled strictly in order while separate conversations proceed independently. Where the model and transport support it, the reply streams back token by token over a server-sent event stream; where they do not, the same turn buffers and returns the identical result, so nothing about what is recorded depends on how it arrived.

What Each Turn Records

Every turn is persisted exactly once — the message, the reply, and the accounting around it: input and output token counts, the duration, the provider and model identifier it actually ran against, and the computed cost. Failures throw before anything is written, so a half-finished turn never lands.

Replies can cite the rows they drew on. Chat recognizes two forms: end-of-statement source markers that render into a Sources list, and inline double-bracketed human-ids that become clickable links to the row itself. Both are instructions the model follows rather than guarantees the platform enforces, so a citation on a claim that matters is worth opening.

Chat As A Front-end

Chat reads and writes the same Dotabases as the CLI and the web app, so anything it captures — a decision, a memory, a saved artifact — is a row the other surfaces read too. The conversation itself is stored in the Conversations Dotabase: one row per conversation, with its messages held in that row's body.