Five architectures for shared work between people and agents

A team may begin by connecting one agent to a database or repository. Once several people and agents share memory, tools, permissions, and work, the team must decide what will hold that activity together.

Wato, PromptQL, Dust, Buzz, and Simmis increasingly occupy neighbouring territory. All five treat agents as participants in durable organizational work instead of disposable prompt completions. Each provides some combination of shared context, connectors, permissions, execution, collaboration, and history.

A feature checklist can obscure the architectural difference. Each system chooses a primary object, and that choice determines what users can query, isolate, authorize, replay, or deliberately change.

Wato makes MCP the connective layer

Wato organizes its architecture around one Model Context Protocol (MCP) layer for memory, tools, workflows, agent sessions, and artifacts. Existing agents connect to Wato, so each worker does not have to reconstruct company context and credentials independently.

Wato makes a strong technical bet on interoperability. Versioned team memory and reusable skills remain available across Codex, Claude Code, Cursor, and other MCP clients. Permissions can be scoped by organization, team, user, connector, and tool. Cloud sessions add a collaborative execution environment with filesystem, browser, desktop, and environment access.

Wato and Simmis share a motivation. Company context should outlive private chats and individual agents. They differ in their primary control mechanism. Wato presents a shared MCP workspace around agents. Its public material does not describe composite branches that reconcile changes to accepted organizational state.

PromptQL governs access below the model

PromptQL starts from connected operational data. Its multiplayer AI combines shared threads and a context wiki with a virtual data layer that queries databases and SaaS systems where they already live.

PromptQL places its most distinctive architectural control below the agent. PromptQL says queries execute with the requesting user’s permissions, while its virtual SQL and HTTP layers inject credentials and enforce data policies outside the model. Its security architecture separates a customer owned data plane from a hosted control plane and sandboxes code execution.

The system can create artifacts, execute code, delegate coding work, and require approval for writes or external calls. However, its centre of gravity remains secure access to live connected systems. Its public architecture does not describe a new accepted state database with branch reconciliation.

Dust makes the enterprise workspace available to agents

Dust begins with an enterprise workspace. Administrators connect company data, divide it into open or restricted spaces, and make agents available according to those boundaries. Its permissions model ties agents and synchronized sources to workspace roles and space membership.

Dust’s newer Pods move beyond isolated agent conversations. A Pod keeps conversations, files, tasks, and connected data around one shared initiative so later work can reuse earlier decisions and context. Dust also offers structured extraction and action tools on top of its retrieval layer.

The primary object remains the workspace and its connected knowledge. Isolation principally controls permissions and data visibility. Dust does not publicly describe branches of organizational data and execution state that later reconcile through one proposal.

Buzz makes every participant an event producer

Buzz makes humans, agents, workflows, messages, and Git activity speak one event protocol. Its self hostable relay stores signed events that share an identity model and become searchable through one workspace.

This produces a useful symmetry. Agents join rooms as members, use the CLI designed for agents or Agent Client Protocol (ACP) harnesses, run YAML workflows, and leave evidence in the same event history as people. A feature branch can become a room in which patches, continuous integration, discussion, and the merge decision coexist.

Buzz’s primary record is an append oriented communication and workflow log. It offers unusually strong identity and provenance at that layer. Its public status table says workflow approval gates are still being wired up. Its Git branches do not amount to composite branching of arbitrary registered organizational state.

Simmis makes accepted state forkable

Simmis begins with immutable, queryable managed state and the work that may change it. A Team is backed by a Dvergr room. Datahike retains versioned knowledge, Yggdrasil coordinates branches across registered systems, Spindel carries forkable execution context, and Simmis turns an attempt into a semantic proposal for merge or discard.

Simmis makes a more specific bet than durable company memory alone. Consequential work should begin from an exact accepted basis, proceed on a composite branch, and become official through an explicit adoption decision. Several people and agents can fork from the same basis or from another branch while the accepted record remains unchanged.

This wider control boundary also creates a harder engineering problem. Simmis must coordinate state, files, execution, conflicts, proposals, history, and interface behaviour. Its core primitives are working, but fine grained authority, the unified operating interface, and a supported production deployment remain in progress.

The architecture map

The table is intentionally descriptive. “Not documented” means only that the public architecture does not make a capability part of its native control model. Integrations may still reproduce narrower versions of it.

These systems increasingly share features. Their deeper difference is the object each one makes authoritative.

ARCHITECTURAL AXIS	Simmis	Wato	PromptQL	Dust	Buzz
Primary substrate	Immutable, versioned managed state	One MCP layer for memory, tools, workflows, and sessions	Virtual data layer plus shared context wiki	Workspace, spaces, connected data, and Pods	Signed event log on a relay
Collaboration unit	A persistent Team backed by a Dvergr room	Shared workspace, team memory, and collaborative cloud sessions	Project and multiplayer thread	Workspace, space, conversation, or Pod	Community, channel, thread, and room
Knowledge model	Queryable facts and accepted-state history	Versioned memory, decisions, skills, and artifacts	Live connected data plus a context wiki	Synced sources, retrieval, files, and conversation history	Searchable messages, media, workflow events, and Git events
Agent execution	Dvergr agents with tools, schedules, budgets, and Spindel contexts	Cloud agents with desktop, filesystem, browser, and computer use	Sandboxed code plus delegated local coding agents	Configurable agents using data and action tools	ACP harnesses, agent CLI, and YAML workflows
Isolation boundary	Composite branches across registered data, files, and execution context	Cloud session and Git isolation. Composite state branching is not documented	Authorization for each user and sandboxed execution. No branch model is documented	Data boundaries for each space. No composite branch model is documented	Identity, channel, community, and Git boundaries
Change adoption	Semantic proposal, conflict handling, merge or discard	Tool permissions and traces. No merge model for accepted state is documented	Writes and external calls require approval	Roles, space membership, and tool-specific action controls	Signed actions and Git merge evidence. Workflow approval gates are in progress
Interoperability bet	Vertically integrated open stack with replaceable models and tools	One MCP endpoint for many compatible agents and connectors	Connect data where it lives and enforce access below the model	Managed enterprise connectors, APIs, and model choice	A shared event protocol, self hosted relay, CLI, ACP, and Git

first-party sources

Simmis architecture · known limits

Wato product

PromptQL overview · security

Dust permissions · Pods

Buzz repository · architecture

Where the category is converging

These systems agree on more than they disagree:

• Useful organizational memory must outlive one chat and one model.
• Agents need explicit identities, tools, and bounded access.
• People and agents need a shared place to see and continue work.
• History and traces matter once agents perform consequential actions.
• The worker should be replaceable without erasing the organization’s context.

Where the category still diverges

The unresolved question is what “shared state” should mean. An MCP memory layer makes context portable. A virtual data plane lets agents act on existing systems under defined access controls. An enterprise workspace makes conversations and sources reusable. An event log makes every participant and action legible. A versioned state graph makes organizational change branchable and mergeable.

Those architectural choices determine what a reviewer can inspect. Review may mean approving a tool call, reading an artifact, inspecting a Git diff, following an event trail, or reconciling a semantic proposal against an accepted operating record.