Conversations and context
Sessions, execution turns, compaction, objectives, and recoverable work.
A conversation is a persistent session belonging to one agent. A run is one turn of work inside it. The run may contain many model steps and tool calls before answering, failing, waiting, or being cancelled.
Start in the right place
Choose the gateway, agent, project, and machine before sending work. Gateway selection chooses where the agent lives; the conversation's target chooses where machine work happens. A model change does not move stored history or create another profile.
Use the conversation model picker for an override and the effort control where the provider supports it. New runs use the selected model; a run's own model choice is preserved while that run executes.
What is persisted
Messages, run state, tool activity, approvals, and context checkpoints are kept by the gateway. The panel is a view of that state. Closing a browser does not cancel server work by itself.
Composer drafts are different: unsent text is retained by the client, one draft per conversation and one per agent's new chat. Attachments are not kept with that draft. Sending clears it; a failed chat creation keeps it. Deleting a chat clears its draft, and signing out clears drafts.
A message that failed to send can be retried as the same message. API clients should use the same requestKey when retrying a submission whose delivery is uncertain.
Context is not the whole database
A model request has a finite input window. Jian assembles:
- Agent instructions and identity.
- Relevant memories within the memory budget.
- Conversation history and any previous compaction summary.
- Skill/tool discovery catalogs and loaded material.
- Current request, tool results, and an open objective when applicable.
The context ring beside conversation protection shows input usage, available room, accumulated token information, and the latest compaction. It is a context indicator, not a billing guarantee; provider caching and pricing affect costs separately.
Automatic and manual compaction
As the input approaches its budget, the gateway summarizes older context using the compaction model. Recent work and the live request are preserved. The original messages remain available to history search; a summary can still lose detail.
Use Compact now in the context ring or send /compact alone to request compaction. The agent can also call compact_context. Very large tool results can be stored as artifacts and read in pages with read_artifact.
If the fixed instructions and current request cannot fit even after appropriate compaction, Jian reports an explicit context error instead of silently discarding arbitrary turns. Large permanent instructions and oversized results still need to be reduced.
Long-running objectives
A session objective records a durable goal across runs. It is opened explicitly through a tool/API or a command such as:
/objective Prepare a tested fix for the dashboard's empty-state bug and present the diff.An open objective lets the gateway queue another slice after a completed slice of work. Ordinary chat alone does not create one automatically. The agent can complete, block, or cancel the objective; the owner can send /done or /objective cancel.
An objective is a short description of the outcome, not a place for logs or shell output. For a concrete question, the agent can use ask_user, parking the run until an answer. A GitHub listener can pause continuation while waiting for an event and reopen the objective on a real wake.
Inspect before retrying effects
After an interruption, inspect the timeline and tool results before repeating a deployment, payment, message, or file write. A connection failure does not prove the external service did nothing. Run checkpoints and external state are better evidence than starting the whole task again blindly.
See HTTP API for run status, history, context, and approval endpoints.