Durable state
Continuity & Provenance
Work survives across turns, restarts, clients, and agents because the daemon owns state and memory stays inspectable.
Continuity is core
Many AI tools lose context the moment the UI closes, the tab refreshes, or the operator starts a new thread. tamux is built to avoid that failure mode. The daemon owns the enduring state, so a line of work can survive disconnects and reconnect from another client surface.
Where continuity lives
SQLite state
Threads, tasks, goals, checkpoints, provenance, telemetry, operator model, and collaboration records.
Memory files
SOUL.md, MEMORY.md, and USER.md as curated durable artifacts with strong semantic roles.
Skills
Procedural memory derived from successful workflows and reusable operating patterns.
Recall systems
Search and retrieval over history, telemetry, structural context, and optional external recall integrations.
The persistence split
tamux deliberately uses a persistence split:
- Structured state: SQLite for threads, tasks, goals, provenance, telemetry, and runtime records.
- Editable artifacts: markdown memory, skills, ledgers, and selected on-disk outputs.
This keeps the system both durable and operator-auditable. Not everything should be a text file, and not everything should be hidden in a database.
Provenance-backed memory
Durable memory writes in tamux are provenance-backed. The system can track where a fact came from, when it was written, which thread or goal produced it, whether it has been confirmed or retracted, and what later event invalidated it.
Continuity across multi-agent work
Handoffs, visible participants, hidden delegation, subagents, and collaboration sessions all create additional memory-bearing state. Because that state is daemon-owned, multi-agent coordination does not destroy continuity.
- Handoffs preserve thread context.
- Goal runners preserve objective-level continuity.
- Operator profile learning preserves working-style continuity.
- Provenance preserves trust continuity.
Long-running goals
Goal runners add another layer of continuity by persisting plan state, step state, events, reports, reflections, and checkpoints. That means a long investigation is not just “a big chat” — it is a durable object with inspectable history.
Operator continuity
USER memory is not just a note file. tamux learns structured operator profile state from onboarding, explicit profile edits, behavior patterns, revision history, and interaction signals. That gives future sessions a better model of how the operator works.
What continuity enables
| Capability | Enabled by |
|---|---|
| Resume work after restart | Daemon-owned state + goal/task persistence |
| Reconnect from another client | Shared runtime authority in the daemon |
| Trust durable facts | Curated writes + provenance |
| Compound skill over time | Procedural memory and generated skills |
| Preserve multi-agent context | Shared memory and thread continuity |
Deep storage direction
A more advanced continuity model is that memory should not only remember facts, but know what it knows: source, confidence, lifecycle state, and explicit retraction relationships. tamux is already close to that direction through provenance-backed memory.
What breaks continuity
Continuity gets weaker when operators constantly start fresh threads for the same mission, use chat turns for work that should be a goal run, or treat memory as a dumping ground rather than a curated layer. tamux is designed to preserve continuity, but the workflow still needs to respect the model.