Brainy Memory

Most applications that need memory build it themselves on top of a vector store: a table for the records, a scoring formula in application code, a reranker in a worker, a nightly script that tidies up. Brainy Memory puts that whole shape inside the engine, where the data already is.

A memory is an ordinary record with a known face: the engine knows which fields mean when it was learned, where it came from, how important it is, how easily it comes back, and whether it has been retired. Because it knows, it can index, rank, expand, rerank, decay, consolidate and sync memories without the application explaining them on every call.

That is the shape hosted memory services sell to agent builders today. Ours is embedded, sovereign, on the same triple-intelligence engine, with time travel and sync. A support desk remembering a customer, an assistant on a phone, a game character with a past: all the same profile.

Works with any model, or none

Brainy Memory does no generation. recall() returns rows, scores, citations and the plan it ran; the application hands those to whichever language model it uses, or to none at all. There is no language model inside the engine and nothing ever leaves the machine the brain runs on.

The profile

A brain declares the profile once; the declaration persists with the store, so every writer and reader agrees.

await brain.declareProfile('memory')TS

From then on a memory record carries these fields, each with an engine role:

Long lists a memory carries (evidence quotes, seen sets) are stored whole and unindexed, so they never hit the indexed-array bound.

The doors

const { id, generation } = await brain.memory.remember({
  content, layer: 'episode',
  source: { kind: 'conversation', ref: conversationId },
})

const r = await brain.memory.recall({
  query, limit: 8, budgetMs: 300,
  rank: { signals: ['importance', 'retrievability', 'recallCount', 'citationRank'], recency: { halfLife: '30d' } },
  expand: { via: ['in', 'cites'], where: { retired: false } },
  rerank: { topK: 32 },
  asOf: { generation: 4120 },       // what did I know then
  validAt: '2026-06-01',            // what was true then
})
r.rows[0].scores   // { vector, rank, rerank }
r.plan             // each stage's milliseconds
r.asOf             // the generation answered

await brain.memory.reinforce(id, { outcome: 'useful' })   // the feedback door
await brain.memory.retire(id, { reason: 'superseded' })   // leaves recall, stays in the storeTS

recall() is one native call with four stages and one budget: retrieve (vector plus filters), fuse (rank signals with a recency half-life), expand (the graph, with a filter on the neighbours), rerank (the cross-encoder, in Rust). A stage that cannot finish inside the budget refuses by name; nothing degrades silently. The fences a memory profile declares (an imagined world, an internal visibility, a retired row) apply by default and open per call.

Housekeeping that never forgets

Four jobs run on the engine's background job runtime, resumable across restarts, yielding to every foreground call, each with a budget:

• Decay follows the spaced-repetition curve, so recall never computes it per query.

• Episodes link memories close in time and source into an episode node. The engine builds the structure; the application writes the words.

• Consolidate links near-duplicates and retires the older one with a reason; importance rises for rows that keep being recalled or cited.

• Retire as demotion. Nothing is deleted. A retired memory leaves the recall path and stays in the store, in history, in diffs, and behind asOf.

Where it stands

The profile, the doors and the jobs ship in 11.3. Every measured number lands on this page as it is taken, on a copy of a real brain, never projected.