What you want and why
When a user starts a new session, there is currently no way to resume a previous conversation. All context — including agent variables, chat history, and emitted events — is lost between sessions.
Supporting conversation continuity would allow users to pick up where they left off, making the agent much more useful for long-running tasks, multi-session workflows, and iterative work. This is a foundational capability for production use cases.
How it could work
Resuming a previous conversation requires restoring all stateful components from the prior session:
- Chat history — the full message thread (user + assistant turns) should be reloaded into the context window or summarized appropriately.
- Agent variables — any variables set during execution (e.g. via
set_variable or Python execution state) should be persisted and rehydrated.
- Events — tool call results, observations, and intermediate outputs that were emitted during the session should be available for reference.
- Session ID / conversation ID — a unique identifier should be associated with each conversation so it can be looked up and resumed.
The CLI and/or SDK could expose a --resume <session-id> flag or equivalent API to load a prior session before the agent begins processing the new user turn.
Storage backends (e.g. local file, database, or external store) should be configurable so this works in both local dev and deployed environments.
Links or extra context
- Related to the memory subsystem and persistent state management.
- Should consider interaction with the
component: memory layer for storage and retrieval.
- May overlap with conversation summarization strategies when histories are long.
What you want and why
When a user starts a new session, there is currently no way to resume a previous conversation. All context — including agent variables, chat history, and emitted events — is lost between sessions.
Supporting conversation continuity would allow users to pick up where they left off, making the agent much more useful for long-running tasks, multi-session workflows, and iterative work. This is a foundational capability for production use cases.
How it could work
Resuming a previous conversation requires restoring all stateful components from the prior session:
set_variableor Python execution state) should be persisted and rehydrated.The CLI and/or SDK could expose a
--resume <session-id>flag or equivalent API to load a prior session before the agent begins processing the new user turn.Storage backends (e.g. local file, database, or external store) should be configurable so this works in both local dev and deployed environments.
Links or extra context
component: memorylayer for storage and retrieval.