Continuity Without False Memory: Context, Evidence, and Recovery
Reasonix’s context and evidence systems answer a harder question than “can the agent remember?” They ask what kind of information should influence the next turn, what must remain exact, and what a host can prove about an operation after the workspace has changed. Understanding these layers lets you keep a long coding task coherent without treating a summary as the original record or a confident model statement as evidence.
A dependency migration is a useful test. The agent may need to remember a project convention, find yesterday’s failed test, inspect the current dependency file, edit several call sites, and verify the result. Those facts do not have the same authority or freshness. Reasonix handles them through different paths: standing instructions, background memory, session history, a provider-visible context projection, and a read-to-write evidence lifecycle.
Four kinds of continuity
Standing instructions are rules that should be present on every relevant turn. In Reasonix, files such as REASONIX.md, AGENTS.md, and CLAUDE.md contribute to the cache-stable system prefix. Their stability is useful because a rule such as “do not edit generated files” should not depend on a search matching the right phrase in the current request. It is also costly: every paragraph placed in this layer travels with every relevant turn. Instructions should therefore contain durable rules, not every fact that might someday help.
Background memory stores facts that can help later but may become stale. A project memory entry might record a non-obvious service constraint or a release branch. A global memory entry might be a user preference. The distinction from instructions is important: a fact can be relevant without being binding. Reasonix retrieves memory as a bounded, low-authority suffix on the current user turn rather than silently rewriting the system prompt.
Session history is the place for original wording, tool output, and decisions that have not earned a durable fact. If the exact error from yesterday matters, a summary should not be the only source. History is also the durable record against which later branches, recovery actions, and receipts can be understood.
The provider-visible projection is what the current model request can fit into its context window. It is derived from the canonical conversation, not a replacement for it. A projection can summarize older messages or prune oversized tool results while the original transcript remains available. This is the layer that makes a long run affordable for the model, not the layer that defines the complete history.
These distinctions prevent two opposite failures. If every remembered statement becomes an instruction, stale information acquires authority. If every instruction is treated as a searchable fact, a missed retrieval can remove a rule that should have governed the turn. Reasonix’s design keeps authority, freshness, exactness, and model-window fit separate.
Memory is retrieval, not authority
Automatic recall is deliberately conservative. A generic message such as “continue” does not provide enough distinctive language to retrieve a useful fact, so it does not trigger ordinary recall. When the request is specific, Reasonix uses BM25-style lexical matching; for CJK text, the documented matcher uses character bigrams. Project facts receive a relevance preference over equivalent global fallbacks, and stale facts are down-ranked rather than silently erased.
The bounds matter as much as the ranking. The default recall includes at most four facts and 2,400 characters. Storage paths are omitted from provider-visible snippets, and home-directory prefixes are replaced with a stable placeholder. The recalled text tells the model it may be wrong and cannot override the current request or standing instructions. These are not cosmetic safeguards. They keep “something once written down” from becoming a hidden command channel.