Memory systems · Cognilode R&D

Search should land on a node, not become the memory system.

Long-running AI systems need a deterministic way to enter their accumulated knowledge, move from broad context to exact evidence, and know what is missing. We use a rooted hierarchy with stable segment identity; search, embeddings, graph links, and reranking remain optional shortcuts.

The problem

Flat retrieval gets harder as memory becomes more valuable.

A vector store is excellent at finding related text. It is less good at answering a different question: where should an agent begin when it needs a coherent understanding of a large evolving system? If every read begins with an unconstrained search, the agent has to reconstruct hierarchy, scope, time, supersession, and source authority on every turn.

That cost compounds. Large memories develop duplicates, stale summaries, competing “current” documents, conflicting source classes, and large numbers of individually relevant chunks that do not tell the reader how they fit together.

Selected architecture

One root. Stable segments. Bounded descent.

The public-safe pattern is simple:

  • Enter through one deterministic root.
  • Descend into the responsible project or role.
  • Read a broad synthesis before opening narrower time cells.
  • Expand exact source evidence only when the decision requires it.
  • Use search as a jump into that same tree, never as a second source of truth.

The tree does not require a separate semantic database. Stable handles can be projections over existing source, subject, and synthesis identities. If a search index is rebuilt or unavailable, navigation still works.

Time and semantics

Keep the physical hierarchy small; project the rest.

Time is one useful backbone because it is naturally compressible. Our canonical nested time chain is all-time → year → quarter → month → day → half-hour. Calendar weeks are useful views but do not form canonical parentage because they cross month boundaries.

Semantic dimensions are facets over the same stable objects rather than copied folder trees. For our internal documentation work we keep six distinct lenses: design state, data state, observed work/effectiveness, and long-, medium-, and short-term strategy.

Economics of memory

Every summary has a benefit and a carrying cost.

A useful memory system should expose more than relevance. A cell can be evaluated by semantic value, physical bytes, cognitive tokens, value per token, value per byte, source coverage, residual uncovered value, and confidence.

Those measurements make compression a planning problem rather than a ritual. High-value dense summaries should rise toward the root. Large low-value carriers should not dominate retrieval merely because they contain many matching words. Most importantly, unknown value stays unknown; the system should not manufacture a score simply to make a dashboard look complete.

Operational boundary

Memory, evidence, code, and operator surfaces stay separate.

The hierarchy is a view over underlying evidence. Exact human statements, raw artifacts, repository history, role-specific continuity, operator controls, and public documentation have different custody requirements. They can share stable identities and navigation without being flattened into one giant store.

This separation matters in production: a public article can explain the architecture without publishing private histories; an operator panel can render the same project-owned actions without copying subsystem logic; and a model-facing tool can return a stable segment handle rather than a detached chunk.

What we built

A single contract across CLI, HTTP, MCP, and operator tooling.

The implementation uses the same small vocabulary everywhere: root, children, parent, expand, sources, path, search, and heatmap. Search results return a stable segment handle and breadcrumb. The operator and model-facing surfaces call the same project-owned implementation instead of maintaining private adapters.

The acceptance boundary is also explicit: source code being committed is not deployment; a queued request is not a host effect; a running process is not a useful downstream outcome. Runtime acceptance requires actual installation, deterministic acceptance tests, and successful readback through the selected surface.

Working on agent memory or reliability?

We can apply this architecture to an existing system.

If your agents keep losing context, retrieving the wrong version of reality, duplicating work, or spending too much context on raw history, bring the current architecture and one concrete failure mode. We can diagnose the information boundary and implement the smallest durable correction.

Discuss agent memory