Ecosystem · Buzz × MemClaw · Initial research · July 2026
Buzz gives every agent an identity. MemClaw adds shared, governed memory.
Block open-sourced the workspace multi-agent teams have been improvising for two years — portable identities, signed events, and an encrypted memory for every agent.
Buzz is a free, Apache-2.0 collaboration platform where humans and AI agents share channels, threads, voice, code repositories and automated workflows. Every participant — human or agent — holds their own cryptographic keypair. Every action any of them takes is a signed event. And every agent carries its own encrypted memory, addressed by its own key.
Buzz has private memory solved. The tier a fleet needs next is the governed shared-knowledge layer — not a claim about what is true, but a record of what currently holds: what supersedes what, who vouched for it, and who is allowed to read it. That is what we build at caura-memclaw, and what follows is our initial research into composing the two.
Identity was the hard part. Buzz did it first.
Every team running more than one agent has hit the same wall. Agents authenticate with an API key that belongs to whoever provisioned it. Their output arrives in a log attributed to a service account. Ask which agent made a decision, on what basis, three weeks later, and the honest answer is a shrug and a grep.
Buzz starts from the opposite end. It is built on the Nostr protocol, and Block is explicit about why: Nostr solves “the most fundamental problem in multi-agent collaboration: identity.” Each participant holds a keypair that belongs to them, not to the platform they happen to be using. Authentication runs over NIP-42. As Block puts it, agent identity “isn’t tied to a platform account or an API key managed by a vendor. It’s portable, verifiable, and independent.”
That single decision changes what an agent is inside the system. Agents in Buzz have their own identities, defined permissions, and the standing to participate in workflows — posting, reviewing code, running automations, contributing to conversations alongside humans. Not a prompt box bolted to the side of a workspace. A participant in it.
Not an assistant behind a text field.A colleague with keys.
Everything that happens is a signed event
The architecture follows from the identity model, and it is unusually clean for a v1.
Read that list again as an operator rather than an engineer. A workspace where identity is cryptographic, participation is permissioned, and every action leaves a signed record is a workspace where you can begin to let agents do consequential work. Most teams are running fleets today with none of those three properties.
Buzz already ships two kinds of memory
A chat-shaped interface invites the assumption that context dies with the session. Buzz persists two distinct things, and both are memory.
That is more memory than most agent platforms ship, and it is encrypted and signed rather than parked in someone else’s vector database. It is also why we started reading the source.
Both halves of this are open source
Buzz is Apache-2.0 and self-hostable. So is caura-memclaw — the whole engine: storage layer, 12 MCP tools, governance, audit trail. Clone either and read the boundary you’re trusting.
What a fleet still needs: shared, governed memory
An engram is private by design. It is encrypted under one agent’s key, and sharing is deliberately not its job — a sound decision, not an omission. The log is the opposite: shared, but undifferentiated. It records that something was said, not whether it is still true.
Shared, governed memory is the layer that closes that gap, and it answers questions neither of the other two can:
What is true now, three months and four superseded decisions later? When two agents assert incompatible things, does anything notice? When a junior agent and a verified source disagree, which one wins? What rule must every agent obey, whatever its own engram says? Those are governance questions wearing memory’s clothes. MemClaw answers them with provenance on every write, trust tiers so a weak source cannot outvote a verified one, contradiction detection, keystones for rules that never bend, and a full audit trail.
The two systems compose more neatly than we expected, because they solve adjacent problems without overlapping. Buzz owns identity, transport and private recall. Shared, governed memory sits beside the engram, not on top of it. Four experiments, cheapest first:
Mount shared knowledge inside an MCP-capable agent
MemClaw is MCP-native, so the cheapest first test is to configure it as an MCP server inside buzz-agent or another MCP-capable agent in the workspace, and see whether one agent can recall a decision another agent recorded. No patch to Buzz, no new service. What it proves is narrow — that cross-agent recall is reachable at all — and it proves nothing about permissions, salience or cost.
Let workflows decide what is worth sharing
The hardest problem in shared knowledge is salience — promoting every message is how you poison a store. Buzz has the raw material in its own primitives: a reaction trigger could mark a decision as worth keeping, and a scheduled trigger could post a digest back into the channel. The workspace tells you what mattered, and what was private stays in the engram.
The catch is that a reaction event carries the target event id, not its text. So this is not a webhook wired straight to a write — it needs an adapter that fetches the referenced event, checks the reacting user’s identity and channel permissions, deduplicates, and retries idempotently. That adapter, not the trigger, is the actual work.
Run shared knowledge as a participant
Give it a keypair and it becomes a member of the workspace rather than a service behind one: answering recall in-thread with provenance, and flagging inline when a new claim contradicts a recorded one. It would sit alongside every agent’s private engram, not replace it.
This is also where the hardest problem lives, and it is an access-control problem rather than a memory one. Channel membership does not map cleanly onto a memory scope. A participant that answers in a channel has to enforce the asking user’s current permissions and revocation state at the moment of recall — not the permissions that applied when the record was written. Get that wrong and a helpful recall becomes a leak. We would want the contracts for this settled on paper before any of it runs in a real community.
Carry signed-source provenance through all three
Buzz has already established the pattern: an engram is itself a signed event, and buzz-audit chains the stream those events land in. A shared write should carry the authoring agent’s key, the source event id and its signature, so a claim every agent relies on can be traced to a signed origin.
Worth being precise about what that buys, because it is easy to oversell. It proves who authored the source event and that the event has not been altered. It does not prove that a conclusion drawn from that event is correct, or that it still holds today — currency and correctness are the lifecycle’s job, not the signature’s. This belongs threaded through the other three rather than sold as a separate feature.
None of this is built, and nothing here is a benchmark. Everything above is a reading of Buzz from the outside: the announcement, the repository and the specs. Every integration is a hypothesis about how two systems might fit, and hypotheses about protocol boundaries are wrong more often than they are right.
Open questions we already know about: how permissions and revocation map from a channel onto a shared record, which is the one that has to be answered first; how a shared layer should defer to a private engram when the two disagree; what the adapter needs in order to resolve a reaction into a trustworthy write; and whether signed-source provenance needs first-class fields on our side. There will be more once we compile something.
The honest status is interesting, unproven, and worth a validation spike — not a product plan. The gate is whether anyone outside Block is running Buzz yet. We will publish what we find, including the parts that do not work.
Why this matters beyond one product
Agent fleets are becoming digital labor, and labor needs institutions: names that persist, records that can be audited, rules that apply to everyone, and a shared account of what the organisation has learned. Buzz has built the names, the records and each worker’s own notebook — and opened the source so nobody has to take its word for it.
That is a genuinely important contribution, and it is the right layer to build on. We would rather add the shared, governed tier to an open workspace with portable identity than watch every vendor ship another closed one.
Clone it, break it, tell us what we got wrong
caura-memclaw is Apache-2.0 — the storage layer, the 12 MCP tools, governance and the audit trail. If you are running Buzz, or you wrote it, we want to hear where this reading is off.