What Termyte stores
Termyte keeps current work and past work separate.Captured work
sessions group events from one agent run. traces form the replay-safe event ledger. A trace can include a prompt, final response, tool input and output, file paths, redaction details, and the original platform event ID.
The ledger feeds four simpler views:
promptstool_callscommandsfile_changes
Current Work Threads
The task tables hold:- the objective and status;
- requirements and whether they are confirmed;
- ordered steps and their verification rules;
- decisions and failures;
- verification evidence;
- every state transition;
- Git checkpoints and cross-agent handoffs.
termyte task.
Sessions and episodes
A session is one agent run. An episode is one piece of work inside that session. Termyte can start a new episode when a prompt clearly switches tasks or when failed evidence closes the current work. Episodes link captured traces, evidence, context packets, and outcomes. Outcome values aresucceeded, failed, partial, abandoned, and unknown.
Past experience
Background processing createsobservations, memories, and summaries. Provenance tables link them back to the source traces. Search documents and local embeddings support later retrieval.
Memories can be useful and still become outdated. Current code and current task state take priority when they disagree.
Feedback and outcomes
Feedback records what a user or client said about a specific memory that was shown. An outcome records how the episode ended. When both point to the same context injection, Termyte can store a conservativehelped, hurt, or unknown effect.
That link is useful evidence for review. It is not proof that the context caused the result.
Durable work
Thejobs table stores queued background work, leases, retries, failures, and dead jobs. This lets processing resume after a worker crash instead of relying on one long-running hook process.