Technology · Discipline

Context engineering and persistent agent memory

Agents forget between sessions, so I built the memory that remembers for them: every tool call captured, extracted and re-injected into later sessions, and a council shell with durable state in PostgreSQL.

Lifecycle hooksPostgreSQL · vectors and full textScoped grounding packets
Two sessions · memory between them Session one
every tool call captured, extracted, embedded, stored
Session two
the next session starts with relevant facts injected
1 contexta view rebuilt for every model
  • 7lifecycle events hooked, from session start to sub-agent stop
  • ~6,000tokens of grounding per turn, the budget for one scope

Memory that outlives the session

In FAFOHive, my coding agents used to forget everything between sessions and rediscover the same facts about my code over and over. Hooks on the coding agent's lifecycle events capture every tool interaction, and a worker pool hands each one to a configurable model provider, local models included.

A hook captures the interaction
A model extracts title, narrative, facts, type and concepts
Embedded and stored
Ranked, near-duplicates suppressed
Injected at the next session or prompt
PostgreSQL · vectors and full text, a Redis hot cache

Context that matters has to survive compaction, so it lives in a store and is injected again; the same diagnosis shaped AgentOS, told in Why long agent runs fail. In very long sessions, older tool outputs are compressed into references the agent can expand on demand, so compaction loses nothing. The service tracks what each fact cost to discover against what reusing it saved, so I can see whether memory pays for itself.

The design follows an open-source session-memory plugin for coding agents (AGPL-3.0), which I credit as its origin. No code was copied; the layer is my own Rust implementation. Local-model extraction, the de-duplication stages, the token accounting and the ties to code intelligence are mine.

Shared state outside every model

In Helix, once several people and several models share one conversation, no single model's memory can be the truth, because models join late, leave and get swapped. So I made one authoritative context, and every model receives a view of it rebuilt for the current moment.

M1own session
M2own session
the authoritative context
M3joins late, same picture
M4swapped out

Knowledge outlives any model session, so the system owns the context and each model holds only its own continuity.

This design is the subject of U.S. Provisional Patent Application No. 64/147,766, "Methods and Systems for Maintaining Unified Conversation Context Across Heterogeneous Reasoning Backends Using a Provider-Neutral Substrate and a Transcript Authority Decoupled From a Scoped Semantic Store" (patent pending).

Scoped grounding packets

That context draws on many sources: the conversation itself, files, decisions and constraints captured along the way, and the project's code and reference material in FAFOHive. It is organised as a hierarchy, and each participant gets context for its own place in it. Retrieval follows the scope a request comes from and never widens to the whole estate by default.

System
Project
A sibling work order · never visible
This work order
conversation
conversation
A sibling work order · never visible
A project sees everything beneath it.

Each turn the model receives a bounded grounding packet for its scope, carrying the objective, recent activity, decisions, constraints, open questions, and the relevant code and documents. A fixed budget per scope keeps the model on what is relevant and makes cost predictable.

Revisions, and a source that is missing

The memory changes over time under explicit revisions. Every packet states which revision of the scope and of each source it reflects, so a model can tell current knowledge from knowledge that is still catching up. If a source is unavailable, the packet names it and the turn goes ahead with what is there.

One grounding packet
Scope · revision stated
Decisions and constraints · revision stated
Code index · still catching up
Reference documents · unavailable, named
The packet against its fixed budget for the scope
Band heights and fill are illustrative.

The conversation itself never disappears. What participants decide and discover goes back to the exact scope it belongs to, ready for the next participant.

Spoken and written, one conversation

A person can also speak to Helix. They hear a short spoken answer while the full written answer appears in the attached chat location, and both belong to one conversation. Helix keeps the people and the machinery in that exchange apart.

OPthe operator
EMPthe employee acting
Mthe model executing
VOXthe voice session