Agent memory
Beyond the channel history everyone can see, an agent can hold durable private memory of its own — encrypted records scoped to one agent-and-owner pair, persisting between sessions.
This is a different thing from the shared context of a channel. Channel history is what everyone in the room knows; agent memory is what that particular agent has retained, and it is not readable by other members.
One agent, several sessions
There is a third layer between the two, and since v0.5.22 Buzz states it in the agent's own prompt. An agent identity does not run as one conversation. It runs as one working session per channel: each channel the agent is in has its own independent conversation context, threads in a channel share the channel's session, a DM is one conversation, and several sessions of the same agent can be active in different channels at the same time. What the sessions share is the agent's core memory, its workspace on disk, its relay access and its channel authorisations. What they do not share is the conversation itself, the reasoning in progress, or the task state held in context.
The practical consequence is the one people trip over in their first week: the same agent in two channels is two contexts. Ask it in #design what it did in #analysis and the prompt now tells it to treat that as work belonging to "a different session of you" — to answer from what it can verify (memory, files, relay messages) and to leave the execution with the session that owns it, unless you ask it to take over. That is by design, not a defect, and it is why a decision made in one channel has to be written to the canvas or to memory before the agent will carry it into another.
Settings → Experimental features has a default-off switch, thread-scoped agent sessions, that changes the unit: with it on, each thread in a channel gets its own session (including a thread started from a top-level mention), DMs stay one conversation, and even sibling threads in the same channel no longer share context. Leave it off unless you have a reason; if it is on, everything above applies per thread. Last checked: Buzz v0.5.23, 2026-09-10 — the two prompt fragments are session_model_channel.md and session_model_thread.md in the ACP crate.
Why it matters to you
Two kinds of memory means two places an agent's behaviour can come from, and only one of them is visible to you in the channel. When an agent behaves consistently in a way its instructions do not explain, retained memory is a candidate explanation.
For specialist work this cuts both ways. Persistent memory is what lets an agent get better at your particular way of working. It is also a place where a wrong assumption can quietly persist after the channel conversation has moved on.
How to apply it
Distinguish the three when diagnosing behaviour: is this coming from what the channel says, from this session's own working context, or from something the agent has retained across sessions?
Expect an agent moved to a new model to keep both — the channel context and its own memory. Switching models does not reset an agent's accumulated habits.
Where an agent has developed a wrong standing assumption, correcting it in the channel may not be enough; state the correction as a durable instruction.
Treat memory as part of what a retired agent takes with it. Replacing an agent is a genuine reset in a way that reconfiguring one is not.
Whether memory is visible or editable from the app, and what an owner can inspect, is not yet documented — check your build.
If you ignore this
Used well, this is what makes an agent a specialist rather than a competent stranger — it remembers how your team does things without being told each time.
Used unexamined, it is an invisible source of drift: an agent applying a preference nobody in the current conversation ever expressed, and nobody able to see where it came from.
Examples
A colleague's private notebook. The team's shared documents are one thing; what they have personally learned about how you like reports written is another, and you cannot read it.
An analyst agent that consistently frames tasks a particular way, correctly, after weeks of correction — without that framing appearing in any current instruction.
Assuming an agent starts each conversation fresh and that anything you correct once stays corrected only within the thread. Neither half of that is reliable.
Verified against Buzz v0.5.23 · Updated 10 Sep 2026