Chat & history

​

Two kinds of record, one timeline

​

Chatting with an agent

{
  "capabilities": {
    "chat": true,
    "streaming": true
  }
}

​

What a turn actually does

​

Tool calls and evidence in the transcript

• Tool calls render as their own rows — which tool, with what arguments, and what came back — interleaved with the agent’s narration in the order they happened.
• Consecutive tool calls are grouped into rounds, so parallel calls issued in one model turn read as one round of work rather than a flat list, and each result stays with the call it answers.
• Data the agent pulled and drafts it produced appear as their own transcript entries rather than being flattened into prose.
• Timestamps are stamped when an event is emitted, not when it reaches the control plane, so the order and spacing you read is the order and spacing that happened.

​

Resumable sessions

​

Waiting for a worker

data: {"type":"queued","queued_behind":2}
data: {"type":"dequeued"}
data: {"type":"text-delta","delta":"Checking the latest deploy…"}
data: {"type":"message","message_id":"msg_…"}
data: [DONE]

• queued_behind is a queue position, not a duration — the number of runs for the same agent that a worker would claim before this one. 0 therefore means nothing is ahead of it: the wait is for a worker to come free or come online, not for a queue to drain.
• The frame is resent whenever that position changes, so a client can count it down. A queue that is not moving sends nothing.
• Nothing is sent for the wait’s first look at the run. Every run starts out queued, so reporting the first look would put a queue notice in front of the reader on every single message. The trade-off is deliberate: the notice appears one poll into a real wait rather than instantly.
• dequeued marks the end of the wait, sent when a worker claims the run. A claimed run is still silent while it starts up and thinks, so the end of the wait has to be announced or the notice outlives the queue.
• A queued run that never reaches a worker sends no dequeued. Cancelled or failed outright, there was no handoff to report, and the terminal frame that follows carries its own content.

​

When an agent cannot answer

​

Continuing from a run

• In KAOP chat. The new session opens as a real transcript rather than one machine-formatted prompt: the run’s own input becomes the prior user turn, its output — or, for a failed run, its failure reason — becomes the prior assistant turn, and your follow-up is the next message. A trailing line names the run so the agent can fetch its full transcript, logs, and trace rather than working from an excerpt.
• By re-running the agent. When the run saved a session snapshot it is revivable: Re-run the agent re-executes it with its tools and the earlier context, producing a new run in the same thread. That is different from talking about the run, and it is the right choice when you want the work redone rather than explained.
• By handing it to a local coding agent. Claude Code or Codex, or the prompt copied to your clipboard. These handoffs carry only your follow-up, the run id, and the run’s URL — never the evidence itself. The coding agent fetches the run over the KAOP MCP server under your own permissions, so nothing sensitive lands in shell history or a clipboard manager. See Connect coding agents.

​

The History ledger

• Chat rows absorb their turns. The per-turn runs behind a conversation are folded into the session’s row rather than listed a second time, so a long chat does not bury everything else.
• The list is capped, and says so. When a page comes back full, the table prints a truncation notice rather than implying you are looking at everything. Search is evaluated on the server — over run and session ids, a row’s title, and the agent’s display name or slug — so looking for something older than the current page finds it.

​

Chat API

​

Next steps