Memory

Memory is the brain's own state — bb does not impose a store. Keep facts in a map, or in a KV via bb.MemStore() / bb.FileStore(dir) (a Get/Put backend), and read/write it inside a handler, weaving recalled facts into the persona:

if facts := mem.recall(); len(facts) > 0 {
    chat.Add(bb.NewMessage("You remember: " + strings.Join(facts, "; ")).As("system"))
}

That's the whole API surface on purpose. The engine gives you durable execution and a KV; what to remember and how to recall it is the author's — deliberately, so a memory strategy never gets in the way of the next one you want to try. A memoryful "model" is visibly unlike the providers it imitates, and that difference is entirely in your handler, not in a framework-owned memory subsystem you have to configure around.

Continuity: transcripts vs. memory

The chat API is stateless: the client sends history each request, and the engine keeps no server-side conversation. Transcripts belong to the client; durable facts belong to memory. Memory is the only continuity there is — if a fact matters past the current request, it has to end up in your store, because nothing else survives.

Working state within a run

The chat threading through a flow chain is the run's working state: each flow appends its replies, and the next flow sees them. Beyond that, an agent handler holds ordinary Go variables for the span of a turn. Long-term facts are memory (above); the chat is the scratch a single run carries between flows — don't reach for a store to pass something two flows down the same chain.

See cmd/jarvis-demo for a complete memory + tools + briefing brain: a keyword router into remember/recall capabilities, a Group-based briefing that reads several sensors concurrently, and facts that persist across turns via bb.FileStore.