When agents become peers in the workspace

Macro’s promise of agent-enabled work depends on more than a chatbot with access to a few APIs. The important question is whether an agent can read and change the same context that human collaborators use, while remaining subject to the same identity and permission boundaries. This chapter examines two parts of that design: the CRDT collaboration substrate that coordinates shared document state, and the workflow-shaped tools that let agents act across Macro’s blocks. The practical result is a way to separate genuine participation from a privileged automation layer that merely writes around the workspace.

Collaboration begins with shared state

A collaborative document has a deceptively difficult problem. Two people may edit the same paragraph while disconnected, then reconnect with changes that were made in different orders. A system that treats one copy as authoritative can overwrite work or force everyone to wait for a central lock. A CRDT, or conflict-free replicated data type, takes a different approach: each peer makes changes to a structured state, and the system is designed to merge compatible changes deterministically.

Macro uses Loro CRDTs for collaborative documents and related editable blocks. The CRDT is not the whole application. It is the state-reconciliation mechanism that lets multiple peers work on the same document representation. The editor, permissions, history, storage, and user interface still sit around it. This distinction matters because convergence—eventually reaching the same state—is not the same as deciding who may edit, whether an edit is desirable, or whether a document should be public.

Macro’s sync service gives each document a room backed by a Cloudflare Durable Object. A Durable Object provides a place for the room to keep live in-memory state and persistent storage. When a client connects over a WebSocket, the service obtains or creates the document’s room. The room keeps the current Loro document in memory while users are active, and stores snapshots and pending operations so the state can be reconstructed later.

The ownership boundaries are straightforward. The browser or worker produces edits. The Loro document represents the converging collaborative state. The room accepts updates and distributes them to connected peers. Persistent storage retains enough information to recover after the in-memory object is evicted. When a new user joins, the service can load the latest snapshot and pending operations, then send a complete state to that client. A recurring alarm keeps an active room warm because Durable Objects can otherwise evict in-memory state after inactivity.

That design explains several user-visible properties of Macro documents. Edits can appear as if collaborators are working on the same machine. Offline changes can be reconciled rather than discarded. Presence and cursor information can travel through an awareness channel without becoming part of the durable document body. A shared runtime can serve both the browser and non-browser workers, so an agent does not need a separate collaboration protocol simply because it is not a person at a keyboard.

It also exposes the costs. Importing snapshots is computationally expensive, so the service needs to balance memory lifetime against reconstruction work. WebSocket connections need authentication even though they are not ordinary HTTP requests. The document-storage service issues a permission-bearing token, and the sync service verifies it before allowing access. The sync-service guide explicitly notes that a future step is needed to ensure that a viewer who receives updates cannot push updates. The CRDT can merge an update; it cannot decide whether the update should have been accepted.

This is a useful boundary for evaluating collaborative systems. A conflict-resolution algorithm addresses concurrent writes. Authorization addresses who may write.