A pipeline, not a magic memory layer

Termyte is built around a pipeline with separate responsibilities. Supported coding-agent connections send activity into the runtime. The runtime captures and redacts configured content before persistence, then stores the resulting trace records in a local SQLite database.

The capture path stays small because it sits on the critical path of an agent action. Heavier work—deriving observations, forming memories, and preparing context—runs through background jobs afterward.

Preserve provenance while deriving context

When related traces become observations and then reusable memories, Termyte keeps links to the source records. Repository, session, file, and task identifiers are retained where available.

This gives the system a basic research property: a memory is not just an answer with a label. It has a path back to the activity that produced it. The viewer can show what was captured, what was derived, and how an item was selected.

Selection is a bounded decision

When a later session requests context, Termyte ranks eligible items within a token budget. It records the packet and the items delivered to the agent. Feedback can then be attached to that delivery.

The result is an inspectable path:

capture -> evidence -> observations -> memories -> context -> feedback

Each stage has limits. Keeping them separate means failures and uncertainty remain visible instead of being compressed into one claim that the agent simply “remembers.”

Why this architecture is modest

We are not trying to build a universal knowledge graph or replace the agent's context window. The useful first version is narrower: capture the work, preserve the links, rank bounded context, and let a developer inspect the result.

The research work is measuring where this pipeline helps and where it adds noise. A memory that cannot be traced, corrected, or ignored is not a trustworthy memory system. It is another opaque prompt injection.