Conversations

A conversation is a session that takes more than one turn: the agent answers, waits, and picks up your next message with everything it already said and did as context.

One conversation per thing

Each surface gets exactly one conversation, and every follow-up on that surface is delivered into it:

• A GitHub pull request is one conversation. So is a GitHub issue, a Linear issue, and a Slack thread. Mentioning @ellipsis there starts it; every later mention on the same PR, issue, or thread continues it.
• A top-level Slack DM message roots its own conversation, answered in that message's thread, so several workstreams can run in parallel in one DM.
• A session you start from the dashboard, CLI, or API is its own conversation. Each start is deliberately a new one; there is no surface to share.

React and cron sessions are the exception: they run once and take no follow-ups. A repeat event starts a fresh session rather than continuing the last one; for Sentry alerts, re-fires of the same issue reach agents at most once every 6 hours.

A conversation never ends on its own. It goes idle between messages, and a later mention on the same surface picks it up again, even after the PR merges or the issue closes.

@ellipsis why does the unfilled-shift digest double-count open trades?

Ellipsis answers in the PR thread with the diagnosis. The next morning, in the same thread:

@ellipsis fix it here and add a regression test

The second message needs no context restated: the agent already found the bug in this conversation, and it makes the fix from the same working tree it investigated in.

How context carries

Across turns, the agent keeps two things:

• The whole exchange. Every prior message, every answer it gave, and everything it did to produce them: the files it read, the commands it ran, its own reasoning.
• The working tree. Edits from earlier turns are still on disk, so "now open the PR" continues the work instead of redoing it.

Timing depends on whether the conversation is warm:

• A message into an active conversation is delivered within about a second. If the agent is mid-turn, it attends to the message at its next natural pause, exactly like typing to Claude Code while it works.
• After a turn, the conversation stays warm for 10 minutes. While warm, the sandbox keeps running and its compute bills like any other sandbox time (see Billing).
• After the window, the conversation's state is snapshotted and the sandbox is destroyed. The next message resumes it, working tree and memory intact, in a fresh sandbox.

Credentials never carry: every resume mints fresh scoped tokens, and the old sandbox's tokens died with it.

The whole conversation runs on one budget. budget.session caps its cumulative spend across every turn, and a resumed conversation runs on whatever remains. A conversation that has spent to its cap stops taking turns and records budget_hit; raise the budget and send another message to continue it.

Two edge cases worth knowing:

• A failed turn does not end the conversation. The agent reports the failure and stays available for your next message.
• Config changes reach a conversation when it next resumes from idle. A warm conversation keeps the config it started with, except that disabling the agent stops it at the next turn boundary.

Steering

Steer a conversation where it lives: that is where the agent posts its answers, so it is the only place a follow-up keeps question and answer in one thread.

• Mention conversations are steered on their surface. On GitHub and Linear, a comment must mention @ellipsis again to be delivered. On Slack, any reply in the thread continues it, no repeat mention needed. The dashboard and agent session connect open a mention conversation watch-only, and sending a message through the API is refused with 409: an answer to a message sent from anywhere else would land in the thread without the question ever appearing there.
• Conversations you started (dashboard, CLI, API) take messages directly: the chat panel on the session page, agent session connect from the terminal, or POST /v1/sessions/{session_id}/messages from your own scripts. See Connect and steer.

An agent whose sessions should never take a follow-up opts out in its config:

ellipsis:
  interactive: false

Stopping a session stops the current turn only; the next message re-engages the same conversation.