Conversation System

Status: Design landing Reference epics: INK-825, INK-831 ADRs: ADR-016

A conversation is one of the two places the author reaches the World Agent (the other is authored edits against the workspace itself). This page describes what a conversation is in the application, how it carries the agent’s voice, and how content the agent proposes is presented inside the thread.

What a conversation is

A conversation is a persistent exchange between the author and the World Agent, scoped to a workspace. It has:

• A thread_id — the same identity used by the agent runtime (see Agent Core System) and the Conversation memory tier.
• A sequence of turns. A turn is one user message plus the agent’s response (which may span tool calls, interrupts, and multiple streamed segments).
• An optional channel assignment — a conversation can belong to a channel (a project, a recurring thread, a scheduled task) and share the channel memory tier with its siblings.

Conversations are workspace content in the sense that they are stored in inklings.db alongside pages, tags, and the rest. They are not workspace content in the sense that they do not carry origin or lifecycle — a conversation message is not a candidate page and does not cross the Submit Boundary. Writes that should cross the boundary are distinct acts, described below.

The World Agent voice

The agent that speaks in a conversation is always the workspace’s World Agent. There is no generic “assistant” voice. Every turn is a turn of this particular World Agent — the one scoped to this workspace, reading this corpus, bound by the standing and zones of this world. The properties that shape the voice are enumerated in World Agent: Six properties; this page describes how those properties surface in conversation form.

Concretely, in a conversation the World Agent:

• Uses first-person agentive language, but does not claim first-hand experience. “I read this page” is fine; “I remember when you wrote this” is not.
• Is explicit about epistemic standing. Claims grounded in the corpus are attributed to the corpus. Claims that are the agent’s own reasoning are labeled as such. Claims that live in the unknown or unknowable zone are named that way (see World Zones).
• Does not assert authored authority. If the agent thinks a canonical entry is wrong, the resolution is a deviation record (Deviation Records), not a unilateral rewrite. The agent can propose; the author decides.
• Acknowledges limits without performing humility. Unknown zones are described, not apologized for.

The voice is uniform across conversations, scheduled tasks, and subagent-driven outputs. It is the same agent talking, in the same register, regardless of who prompted the run.

Turns and streaming

A turn starts with the author’s message or with a scheduled-task trigger. The agent graph runs (see Agent Core System): context is loaded, the planner decides, tools may be called, subagents may be dispatched, and output streams back.

What the author sees in the thread:

• Streamed assistant text. The agent’s primary output, arriving incrementally.
• Tool-call markers. When the planner calls a tool, the conversation shows a compact marker (“reading page X,” “running search,” “proposing candidate page Y”). Markers are expandable; the expanded form shows the tool name, arguments, and a summary of the result.
• Interrupt surfaces. When the graph interrupts for an author decision (a destructive action, a capability grant, a candidate promotion), the interrupt appears as an inline UI element the author can act on.
• Deviation and revision callouts. When the run produces a deviation record or flags a retroactive revision, a callout appears inline with a link into the dedicated surface.

Turns are replayable in the sense that the thread stores the assistant’s output and the tool-call trail, not in the sense that re-running produces identical output. The LangGraph checkpointer ensures a turn is resumable after a cancel or a crash; it does not turn conversations into deterministic functions.

Candidate-content inline treatment

When the agent proposes workspace content during a conversation — a draft page, a new tag, a candidate block edit — it appears inline in the thread. Inline means:

• The content renders in the conversation as a compact preview of the real workspace entity it would become.
• The preview carries origin (agent-produced) and lifecycle (candidate) visibly. See Provenance.
• Below the preview are the two moves the author has at this point: promote to canonical-allowed (which is an authored act crossing the Submit Boundary) or dismiss.
• Opening the preview opens the full candidate in its real location in the workspace, where the author has the full editing surface.

Candidate content is not a conversation-only artifact. It is already a workspace entity (a candidate page, a candidate block edit, a candidate tag) — the inline treatment is a view into that entity, shown in the conversation because the conversation is where it was produced. The author can close the thread, find the candidate in its workspace zone, and act on it from there.

This is why “drop-in” is the wrong mental model. The agent does not paste text into the conversation that the author then copies into a page; the agent writes a candidate, and the conversation shows a view of that candidate.

Deviation surfaces referenced

When the agent reads the corpus and finds a contradiction between canonical entries — or between a canonical entry and new information — a deviation record is produced. The conversation does not try to resolve the deviation inline. It shows a callout: “A deviation has been recorded while working on this turn,” with a link to the deviation record’s surface.

The callout’s job is to make the author aware that a deviation happened. The deviation-record surface, not the conversation, is where triage and resolution happen. See Deviation Records: Prominence and triage.

Conversely, an author asking the agent to work on something does not suppress deviation records. If the agent spots a contradiction mid-run, the record is produced regardless of whether the author’s immediate ask relates to it. The conversation shows the callout; the author decides when to triage.

Retroactive-revision surfaces referenced

When an authored edit to a canonical entry invalidates earlier derivations (see Retroactive Revision), the re-validation queue gains entries. The conversation does not walk the queue during the turn. If the agent surfaces a re-validation decision during a conversation (say, because the author asks about something that depends on an entry now flagged), the conversation shows a callout pointing into the retroactive-revision surface.

The queue is walked elsewhere — by the author or by a scheduled re-validation task (Scheduling System). The conversation system’s job is to make the callout visible when relevant, not to own the queue.

Permission interrupts and capability grants

When the agent needs a scope it does not currently hold — to perform a write at a sensitive path, to read an isolated zone, to run a sandbox call with elevated capabilities — the graph interrupts. The interrupt surfaces inline in the conversation: “I need permission to do X. Grant?” with scoped options.

The author’s answer comes back as a Command(resume=…) to the runtime (see Agent Core System). The conversation records both sides: the request and the decision, as ordinary turns. The capability grant itself is handled by the Permission System; the conversation is where the dialogue happens.

Channels

A channel groups conversations that share context — a project, a recurring thread, a scheduled task. A conversation in a channel reads the channel memory tier at turn start and writes to it when the planner decides.

Channels are the mechanism by which a scheduled task can say “we worked on this last Tuesday; picking up from there.” They are also how a long project can span many conversations without each conversation having to rehydrate everything the last one learned.

A conversation can belong to zero or one channels. Moving a conversation into a channel, or out of one, is an authored act. The agent does not silently re-home conversations.

Scheduled-task conversations

A scheduled task is an agent run on a thread, exactly the same shape as a conversational run (see Scheduling System). The output of that run lives in a conversation surface. The author can read it, respond to it (which continues the conversation as an interactive run), or leave it.

The agent’s voice does not change between scheduled and conversational runs. A scheduled task produces agent turns with the same voice, the same tool-call markers, the same candidate-content inline treatment. The only difference is that the turn was triggered by a time or event, not by an author message. The conversation makes that explicit — the first turn is marked as “triggered by schedule: [name].”

Interactive continuation

An author replying to a scheduled-task conversation interactively continues that thread. The thread_id is the same; the channel is the same; the memory is the same. The agent picks up with full context.

Conversely, an author starting a new conversation is starting a new thread. Unless explicitly placed in a channel, it has only the workspace and account memory tiers — not the channel tier of any other thread. This is deliberate: channel membership is explicit, so the author knows what context is in play.

Cancel, pause, resume

A running turn can be canceled by the author. The graph is interrupted at the next await; state is checkpointed; the conversation records “canceled.” The author can send a new message on the same thread; the agent resumes from the checkpoint or starts a new turn, depending on what the planner decides.

A conversation does not expire. It remains on disk, resumable, until the author explicitly deletes it. Memory consolidation (Agent Memory System) may roll up the conversation tier at session close, but the conversation itself remains.

What the conversation system is not

• Not a chat log format. Conversations are structured — turns carry tool-call traces, interrupt records, candidate-content previews, deviation callouts. Rendering them as plain chat would lose half the information.
• Not the submit boundary. A conversation message is not a workspace write. Workspace writes that happen during a conversation cross the boundary through the MCP tool path described in MCP System, not through being messages.
• Not a privileged channel. A conversation does not grant the agent scopes it does not otherwise hold. Permission interrupts surface here because the UI surface is convenient, but the authority is in the Permission System.
• Not a substitute for the workspace. The author’s real surfaces — pages, the deviation-record queue, the retroactive-revision queue — are not duplicated inside conversations. Conversations reference them.

Relationship to other systems

• Agent Core System — a turn is a run of the agent graph against the conversation’s thread_id.
• Agent Memory System — conversation and channel memory tiers are keyed by conversation and channel identity.
• World Agent — the agent that speaks here is bound by the six properties defined there.
• Submit Boundary — candidate content shown inline is the view of a workspace entity that crossed this boundary.
• Deviation Records and Retroactive Revision — the surfaces called out by conversation callouts.
• Scheduling System — scheduled runs produce conversation output with the same shape.

What this page does not do

• It does not describe how the UI renders the conversation surface. That is a frontend concern (see Frontend System).
• It does not describe call-scoped prompt-overlay roles applied to turns. See Role Primitive.
• It does not describe tool semantics or argument shapes. See MCP System.
• It does not describe candidate-content domain semantics. See Provenance and Submit Boundary.
• It does not describe agent voice in non-conversation surfaces (e.g., inline agent annotations on pages). See World Agent: Voice framing.