Buzz’s event memory: When does an old conversation help?

When a production problem returns, someone usually asks how the team solved it last time. One person searches chat, another finds a code change, and a third remembers that the release was delayed for a reason. Each record may exist, but a useful memory depends on how they fit together. Giving an agent access to all of them does not answer the harder question: which part of that history was a tentative guess, and which part survived testing?

Buzz is Block’s open-source, self-hostable workspace for people and agents. It uses a Nostr relay to record messages, workflow steps, reviews and Git events as signed events. Its documented surfaces include a desktop client, an agent-oriented CLI and ACP integration for Goose, Codex and Claude Code. That shared event model changes how a team can revisit its work. It also creates a temptation to treat everything returned by a search as though it had the same authority.

A shared log is not a shared standard of evidence

Consider an engineer’s message during an incident: “This might be the cache.” The team later finds a mapping error instead. Buzz can preserve the original message, link the subsequent conversation to code activity and make both searchable. The signature helps establish who made a statement. It does not make the statement true, current or approved as a diagnostic rule.

The distinction matters for an agent that retrieves historical context. A search result can be highly relevant to the words in a new incident while pointing to a hypothesis that was abandoned in the old one. A helpful summary needs to say what the team suspected, what it checked and what it ultimately changed. If it silently drops those stages, a neat event history becomes a source of confident but stale advice.

Our previous Buzz article separated a recorded approval from an authorized one. The memory problem has a similar shape. A recorded observation is evidence that something was observed or said. A reliable instruction for today’s work requires a fresh link between that observation and the current situation. Neither a cryptographic signature nor a good search index supplies that link on its own.

An incident that looks familiar

Imagine an application where report downloads occasionally time out. During the first incident, the team discusses several possible causes in a channel, inspects a database query plan and merges a change. Weeks later, a new timeout appears. An agent searches Buzz and finds the old thread, the patch and the review. It could suggest repeating the patch immediately. That would be the quick answer, but not necessarily the useful one.

The new timeout might be caused by a storage service rather than the earlier query. The patch may already be deployed, or it may have been reverted. Even if the symptoms match, the relevant dataset and deployment version might differ. The agent should treat the previous incident as a route through the investigation, not as an order to apply the previous fix. It can identify the old evidence, compare it with current measurements and state clearly where the comparison stops.

This is where a joint workspace earns its place. Instead of copying an isolated chat quote into a separate issue, the team can follow the discussion to the associated technical events and record a new conclusion in the same context. But proximity is not causality. A patch and an outage appearing in one channel does not establish that the patch resolved the outage, let alone this week’s outage.

Label what a search result represents

A practical knowledge trail distinguishes four kinds of statements. An observation reports what someone saw. A hypothesis offers a possible explanation. A validation records the test or measurement used to check it. A decision identifies who accepted a change, for which version and under what conditions. Teams do not need a complicated form for every message. A short incident summary that points to the relevant change and test is often more useful than a long conversation with no declared outcome.

Agents should preserve those distinctions when answering. “The team examined this query plan before changing the index” reports history. “Change the index now” is a recommendation for a new environment. The second statement needs current evidence. If the agent’s answer presents both at the same level of certainty, the reader has to reconstruct the missing verification work. A signed event makes the source traceable, but traceability does not excuse the omission.

Access also needs a boundary. An agent capable of searching historical channels does not automatically need to search every customer’s discussion. Buzz gives agents their own identities and channel memberships, which can help define who sees which conversation. That is not a substitute for checking the agent’s permissions in connected repositories, services and its execution environment. A scoped channel and a broadly privileged runtime can tell two different stories about the same agent.

Try it with one recurring problem

Choose a recurring class of incident rather than importing all project history at once. Review one old incident’s thread, code change and deployment result together. Ask a colleague who was not present to reconstruct the final diagnosis from those records alone. Where do they have to guess? Perhaps the channel has plenty of messages but no link to the decisive test. Perhaps a review exists but nobody recorded which revision was deployed. Those gaps tell you what to record next time.

On the next occurrence, have the agent give three separate outputs: what the earlier records show, what has not yet been checked today and what evidence would settle the open question. The useful saving is not the ability to copy an old patch faster. It is the ability to start a careful investigation without rebuilding every piece of context from memory. A good outcome is a new decision whose historical sources and present measurements can both be inspected.

Buzz makes a team’s conversation and technical events easier to revisit together. It does not decide who may turn that memory into an operational decision or which agent should read which project history. Those boundaries belong to the organization as well as the workspace. agentic-organization addresses that complementary layer as a self-hosted, file-based platform for managing AI agents as first-class members of an organization chart.