Portable identity needs portable context

Multi-agent workspaces are changing the unit of software work.

The old unit was one developer in one editor talking to one assistant. The new unit is a room where people, coding agents, workflows, repositories, and reviews all participate. Identity has to survive that change. You need to know who said what, which agent acted, and what was approved.

Buzz is built around that collaboration layer: humans and agents share rooms and produce signed events in one workspace. That is valuable infrastructure. It gives activity a place, an author, and a history.

But portable identity is only half the continuity problem.

The other half is portable context.

History and understanding are different things

A channel can remember every message and still leave the next agent under-informed.

History answers questions like:

• What happened in this room?
• Who approved this change?
• Which workflow ran?
• What did the agent say before it stopped?

Project context answers a different set:

• Which requirements still govern this work?
• What architectural decision applies here?
• Which constraint has already ruled out the obvious approach?
• What was tried in a different tool or session?
• Which conclusion is approved and durable, rather than merely discussed?

Those answers cannot come from indiscriminately replaying workplace chatter. A transcript contains ideas, reversals, guesses, jokes, stale assumptions, and final decisions side by side. More history is not automatically better grounding.

The useful layer is approved, reusable project understanding with sources.

The product boundary matters

Buzz and ContextStream should not compete to store the same thing.

ContextStream does not need every Buzz message. Buzz does not need to become a project knowledge engine.

The clean architecture is thin:

1. A human or agent works in Buzz.
2. The Buzz agent uses ContextStream through MCP.
3. ContextStream retrieves the relevant project knowledge for that task.
4. If a durable conclusion is reached, the agent proposes a focused save.
5. An authorized human approves before that conclusion becomes shared project context.

That boundary protects both products. Buzz remains the collaboration workspace. ContextStream remains the portable context layer.

Three behaviors make it real

An MCP connection by itself is not an experience. The agent has to behave consistently.

Brief before substantial work

Before editing, the agent should retrieve the requirements, decisions, constraints, previous attempts, relevant code and docs, and current project status that affect the task.

A useful agent can say: “I checked the shared ContextStream project before starting. Three previous decisions affect this change.” It can then show the sources.

Preserve only after approval

When a discussion reaches a lasting conclusion, the agent should propose the exact durable record and its provenance. It should wait.

Silence is not approval. Another agent agreeing is not approval. Confidence is not approval.

That human gate is how a shared context layer stays trustworthy instead of becoming a landfill of speculative conversations.

Hand off across agents

When a second agent continues, it should retrieve a concise handoff containing verified facts, eliminated approaches, current scope, validation, blockers, and next steps.

The user should not have to reconstruct the project for every model or harness.

Claude starts it. Codex continues it. ContextStream carries the understanding.

Why Buzz makes the value visible

Cross-agent continuity can sound abstract in a single-editor demo. Buzz makes the boundary obvious because the room can change and the agent can change in front of everyone.

The signature scenario is simple:

1. A Claude Code agent retrieves existing project context and begins a feature.
2. A human changes an important requirement.
3. The approved decision is preserved with the Buzz thread as provenance.
4. A Codex agent continues in another room or later session.
5. Codex retrieves the new requirement without being rebriefed.
6. The same decision is available later outside Buzz.

The room changed. The agent changed. The context did not.

That is the proof that matters. Raw MCP call counts are not the outcome. Context successfully crossing an agent boundary is.

A working reference, not a conceptual integration

We published the ContextStream Buzz reference to make this reproducible. It includes:

• a launcher for Claude Code, Codex, and Goose through Buzz ACP;
• ContextStream declared as the shared MCP server;
• project-scoped permission guidance;
• brief, preserve, and handoff teaching;
• compact source attribution;
• a disposable two-agent demonstration fixture;
• compatibility evidence pinned to the Buzz version we tested.

The implementation also records two details that only became obvious during a real headless agent run: the MCP server needs a stable canonical name, and a write-capable Claude session needs a reviewed project-local permission policy. Those are the kinds of details a reference should prove instead of hand-wave.

You can follow the under-five-minute path at ContextStream for Buzz.

The category is bigger than one integration

Buzz is the first clear expression of a broader shift. Teams will use more agents, not fewer. Those agents will live in different rooms, editors, services, and automation systems. No single conversation history can be the source of understanding for all of them.

The durable layer has to travel.

Portable identity tells us who participated. Portable context tells every authorized participant what the project already knows.

Multi-agent work needs both.

FAQ

Does ContextStream replace Buzz history?
No. Buzz remains the collaboration workspace and event history. ContextStream carries approved, reusable project knowledge across agents, sessions, tools, and workspaces.

Does ContextStream ingest every Buzz message?
No. Agents retrieve relevant project context and propose focused durable saves. Human approval should be required before a lasting decision from Buzz is preserved.

Why use MCP for this integration?
MCP lets supported agents use the same ContextStream project without building a separate Buzz-only context engine. The host workspace stays Buzz; the portable project-context layer stays ContextStream.