Status: Proposal
Summary
Seed should not compact a long conversation by replacing early history with a rolling summary. Instead, an agent may continue its work in a fresh session when the current conversation is no longer the right working context—for example, when the user changes subject, a phase ends, or the model context becomes crowded.
A continuation is a visible, durable transition:
the original session remains complete and unchanged;
the agent creates a deliberate projection of what its successor needs;
Seed creates a fresh session linked to the original;
the UI follows the transition while preserving obvious navigation back;
people and agents can inspect the handoff and reopen its exact sources.
The user experiences one continuous interaction. The agent gets a clean context without pretending that generated prose is the historical record.
Terminology
Continuation
A continuation is the durable, user-visible primitive: carrying work from one session into a fresh successor session. It defines lineage, lifecycle, and navigation.
Projection
A projection is the successor's initial model context: a purpose-built view of relevant state and history with exact references back to its sources. It is derived context, not canonical history.
The product primitive should therefore be Session Continuation; its context payload is a Context Projection.
Goals
Give an agent a fresh, coherent context at semantic boundaries.
Preserve the complete source conversation without mutation or hidden loss.
Keep the user oriented while the UI moves into a successor session.
Make the handoff traceable to exact source events and resources.
Carry structured runtime state exactly rather than asking prose to preserve it.
Let the successor recall exact earlier material when its projection is insufficient.
Avoid accumulated errors from summaries of summaries.
Non-goals
Deleting or rewriting transcript history.
Hiding session boundaries.
Treating a generated handoff as authoritative state.
Splitting every conversation at an arbitrary token threshold.
Reusing delegated child-session semantics. A child is expected to report back; a continuation becomes the new foreground conversation.
Core model
A continuation has four durable parts:
Predecessor session — the complete original conversation.
Continuation edge — why, when, and by whom the transition was made.
Projection manifest — the exact sources and state selected for the handoff.
Successor session — a fresh session initialized from that projection.
Session A
└─ continuation edge
├─ reason: topic_change
├─ projection manifest
│ ├─ exact event ranges from A
│ ├─ referenced Seed resources
│ ├─ structured state revisions
│ └─ agent-authored handoff
└─ Session B (active foreground)Continuation needs a distinct predecessor/successor relationship. Seed's existing parent/child relationship represents delegation and eventual return, which has different behavior.
A predecessor may have several successors if someone revisits it and branches in another direction. Each successor has one immediate predecessor. Following predecessor links reaches the original session.
When continuation happens
The agent may initiate continuation when:
the user changes to a substantially different subject;
one phase completes and another begins;
the active task requires a different working set;
old tool traffic overwhelms useful context;
the user explicitly asks for it;
the model approaches its context budget.
Continuation should be a semantic decision, not merely a token threshold. Context pressure may prompt the decision, but Seed should not silently manufacture a lossy summary.
Continuation normally happens at a turn boundary. The agent should not split while side effects are unresolved. Pending children and obligations must be transferred explicitly or settled first.
Agent primitive
Expose a first-class continue_session tool:
continue_session({
reason: 'topic_change' | 'phase_change' | 'context_pressure' | 'user_request' | 'other',
title: string,
description?: string,
handoff: {
purpose: string,
currentRequest: string,
establishedFacts?: string[],
decisions?: string[],
openQuestions?: string[],
nextActions?: string[],
cautions?: string[]
},
sources: Array<
| {kind: 'session_events', sessionId: string, fromEventId: string, toEventId: string, relevance: string}
| {kind: 'session_event', sessionId: string, eventId: string, relevance: string}
| {kind: 'resource', url: string, version?: string, blockId?: string, relevance: string}
| {kind: 'memory', path: string, cid?: string, relevance: string}
>,
transfer?: {
plan?: 'carry' | 'close' | 'omit',
pendingRuns?: string[],
pinnedTools?: string[],
pinnedResources?: string[]
}
})The prose handoff provides orientation. sources provide accountable breadcrumbs. The runtime—not the model—adds immutable lineage and identity fields.
Calling this tool ends the predecessor's active turn. The successor run produces the response, avoiding one answer split across two sessions.
Runtime lifecycle
1. Decide
The agent receives a message and decides the response belongs in a fresh context. It calls continue_session instead of answering in the predecessor.
2. Validate
The runtime verifies that sources exist and are accessible, state transfers are valid, unresolved effects will not be orphaned, and the edge cannot create a cycle.
3. Create atomically
In one transaction Seed:
creates the successor;
writes the continuation edge;
stores the projection manifest and handoff;
transfers allowed structured state;
records the successor on the predecessor;
creates the successor's initial run.
The call needs a stable idempotency key so replay cannot create duplicate successors.
4. Project context
The successor's first model context contains:
the normal system prompt and agent definition;
exact current identity, grants, permissions, and available tools;
exact transferred plan, obligations, pending runs, and pins;
the agent-authored handoff;
a runtime-generated lineage block;
selected exact source excerpts that fit the budget;
handles for omitted sources, available through recall.
The user message that caused continuation must be included exactly and referenced by event ID. It must never survive only as paraphrase.
5. Navigate and respond
The server emits session-continued. A client still following the predecessor navigates to the successor, whose run starts automatically and answers there. The predecessor retains a durable transition card linking to the response.
Projection manifest
The manifest protects against an opaque, lossy handoff. It records:
predecessor, successor, and origin session IDs;
continuation edge and initiating user event IDs;
creation time, actor, and reason;
selected event IDs or ranges;
resource URLs, versions, and exact block IDs where relevant;
transferred state revisions;
projection compiler and model versions;
token cost;
items omitted for budget reasons;
hashes or CIDs where available.
The system can then explain: “This successor received these events, this plan revision, and this generated handoff; these other sources remained linked but cold.”
Breadcrumbs and recall
Every successor receives runtime-generated lineage—not an agent-authored approximation:
<session_continuation>
<origin session="session-a" />
<predecessor session="session-c" edge="continuation-4" />
<initiating_event id="event-92" />
<projection manifest="projection-4" />
</session_continuation>The agent can inspect the predecessor transcript, walk back to the origin, read the projection manifest, retrieve an exact event range, and open cited Seed resources and versions.
A successor should not ingest every ancestor eagerly. Breadcrumbs guarantee reachability; relevance and explicit recall decide what becomes hot context.
UI
In the predecessor
The old session ends with a durable transition card:
> Continued in “Session continuation proposal”
> Topic changed · 10:54
> Carried the current request, two decisions, and four source references.
> Open continuation · Inspect handoff
In the successor
The new session starts with a banner:
> Continued from “Rethink Seed compaction”
> Topic changed · Back to previous · View handoff
A lineage control can reveal the whole path:
Rethink compaction → Session continuation proposal → Implementation plan“View handoff” shows both the readable handoff and its exact source manifest.
Automatic navigation
Redirect only when the user is still viewing the predecessor, that client is following the active turn, and the user has not navigated elsewhere. Other clients receive the event but are not forcibly redirected. Browser history and Back must work normally.
Returning to an old session
The predecessor remains readable. If a user returns and writes there, Seed should offer to open the current continuation or branch into another continuation. Silently appending independently to predecessor and successor would make the lineage ambiguous.
Structured state transfer
Narrative and exact state must remain distinct.
State | Default behavior |
|---|---|
Initiating user message | Include exactly; retain source event identity |
Plan | Agent chooses carry or close; preserve step IDs and resolution state |
Pending delegated runs | Transfer explicitly; retain run and tool-call identities |
Grants and account identity | Recompute from current policy |
Expanded tool contracts | Carry only still-relevant scoped pins |
Seed resources | Preserve exact URLs, versions, and block IDs |
Attachments | Link by immutable identity; do not duplicate blobs |
UI window context | Recompute in the successor client |
The rule is: carry exact state as state, and narrative understanding as narrative.
Context budgeting
The projection compiler fills context in this order:
control and safety instructions;
exact identity, grants, obligations, and structured state;
initiating user message and immediate turn boundary;
agent handoff;
exact pinned sources;
recent relevant exchanges;
additional relevant excerpts.
Anything that does not fit remains linked-but-not-loaded in the manifest. Later continuations should consult exact sources and manifests, not merely summarize the previous handoff. Multiple projections over the same history are valid because relevance depends on purpose.
Failure and recovery
Wrong handoff: inspect and recall exact sources; create a corrected successor without changing history.
Failed successor run: retain the edge and successor with retry controls and a back link.
Missed navigation: the transition card and session list still reveal the successor.
Replayed tool call: return the successor created for the stable call identity.
Changed source: retain the exact version or CID selected by the manifest.
Revoked source: show an unavailable breadcrumb; never silently substitute newer content.
Continuation loop: reject cycles and rate-limit pathological transitions.
Relationship to other session types
New session: no inherited conversational lineage.
Child session: delegated work expected to return to its parent.
Continuation: successor foreground conversation replacing its predecessor in the active UI.
Fork: an alternative path from an earlier point, usually initiated explicitly by a person.
Continuation and fork may share an edge model later, but their intent and default UI differ.
Minimum viable implementation
Phase 1 — explicit continuation
Add a typed continuation edge distinct from parent/child lineage.
Add an idempotent continue_session tool.
Persist the handoff, reason, initiating event, and source references.
Start the successor run automatically.
Add predecessor card, successor banner, Back, and guarded automatic navigation.
Replay the exact initiating message plus handoff in the successor.
Phase 2 — inspectable projections
Add the full projection manifest.
Show included and omitted context in the UI.
Add exact event-range reads and lineage traversal.
Transfer plans, pending runs, and scoped pins safely.
Phase 3 — assisted selection
Estimate budgets before continuation.
Recommend relevant event ranges and resources.
Support purpose-specific projections and recall ranking.
Measure repeated recalls of omitted sources as a projection-quality signal.
Open questions
Should agent-initiated continuation require approval, or is a visible reversible transition enough?
Should the initiating message render in both sessions, with provenance in the successor, or only in the predecessor?
May one predecessor advertise several active successors?
Which pending run types can safely transfer ownership?
Should manifests become signed objects or begin as account-scoped database records?
What minimum breadcrumb coverage should runtime validation require?
Does the successor automatically inherit the predecessor's access policy?
Recommendation
Name the primitive Session Continuation and its derived handoff Context Projection.
“Continuation” describes carrying work into a fresh conversational space. “Projection” describes the selective context supplied to it. Neither implies that Seed destroyed or rewrote the original record.
> A continuation may reduce what is loaded, but it must never reduce what is reachable, attributable, or inspectable.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime