Conversations

Talking to an agent should feel like talking to someone who remembers you — you speak, it remembers. The LLM behind the agent has no memory across context windows. To deliver that experience, you need to reconcile context across sessions.

One agent, many conversations

A Cast agent often runs many conversations at once. Each one belongs to a counterparty — a specific person, or a specific peer agent. When Alice and Bob both message the same agent, the agent runs two separate conversations, with two separate histories and two separate context windows. Alice and Bob don't see each other.

Cast routes each inbound turn to the right conversation. The human doesn't choose — they just talk to the agent. They see one continuous stream; the agent sees a specific conversation with a specific counterparty.

Cast's answer to the reconciliation problem is bounded conversations with explicit memory reconciliation. Each conversation has a start, runs some turns, and ends. On opening, it reads from memory; on close, it distills the conversation back into shared memory. Memory is the shared substrate that lets otherwise-isolated conversations bridge across users, surfaces, and time.

How reconciliation works

Cast doesn't prescribe how to reconcile memory. It provides three primitives; the author composes them into whatever shape fits the agent.

• Bootstrap — runs at the start of a new conversation, before any user turn. The author writes the script; the framework injects its output as opening context.
• Cleanup — runs at the close. The author writes the script; the framework swallows its output. Whatever cleanup writes to /memory/ persists for next time, and summaries written to a specific slot auto-inject into future conversations with the same counterparty.
• Cross-conversation push — a tool the agent can call mid-turn to drop a message into another ongoing conversation under the same agent. For handoffs, notifications, status broadcasts.

Bootstrap and cleanup can be used for other things too — reflection, alerts, post-processing, whatever the author wants to run at those boundaries.

Container and isolation

Each conversation runs in its own container while it's open. The container reads and writes the agent's filesystem — memory, attachments, working storage — and exposes the agent's tools through its own private socket. When the conversation closes, the container exits.

Two conversations on the same agent run in two different containers. They share the agent's files on disk, but their processes run independently. Neither sees the other's prompt, context, or history.

Other shapes a conversation can take

Conversations can also:

• Close after a single turn — every inbound turn opens a fresh conversation, the agent responds once, and it closes. Nothing carries between calls. Useful for untrusted input, peer query/answer exchanges, audit-style edges.
• Run on a different model than the agent's default — a cheaper model for cleanup-time summarization, or a sharper one for a high-stakes question path.
• Expose a subset of the agent's tools — narrowing what the agent can do on this conversation.
• Not persist history — useful for high-volume notification flows, or for conversations you don't want the agent reading back after the fact.
• Restrict who can send and who can receive — only certain counterparties allowed in either direction.

Each is a variation on the same underlying conversation. An agent can run many of these in parallel — different counterparties on different shapes, all live at once.

What to read next

• Channels — where you configure each of the shapes above.
• Conversation grid — when several people share one agent, how each gets their own private conversation, laid out as a grid.
• Scheduling & triggers — what else can open a conversation, beyond a person sending a turn.