The shared document is not an agent's private scratchpad

A creative brief is rarely finished when someone asks an agent to improve a paragraph. Another collaborator may still be editing it. The useful question is not just whether the agent can produce better wording, but how that wording enters the work the team already shares.

Automatically treating the model response as the next document state would make generation and editorial approval the same operation. They are not the same thing. A team may want to keep a useful suggestion as a comment, use a different part of it, or decide not to apply it.

Make the proposed edit inspectable

Breatic's document proposal card receives a structured proposal rather than merely displaying an opaque chat reply. For rewrite proposals, the component parses the proposed body with the document schema and computes a word-level diff against the proposal's original text. Removed words and added words are rendered separately.

The card also identifies the document and location. Its actions include locating that place, adding an eligible proposal as a comment, and applying a rewrite or insertion. The UI distinguishes work in progress from an applied result.

These are deliberately separate affordances. Seeing an agent's text is not the same as asking it to write into the shared document. A visible diff helps a person evaluate the change; an explicit action expresses the decision to use it.

Read the proposal-card component.

Keep synchronization and editorial intent separate

Breatic uses Yjs/Hocuspocus for collaboration and React Flow for its canvas. A CRDT is valuable for shared editing, but convergence alone cannot tell a team whether an agent's suggestion is appropriate after the surrounding work changes. That requires application behavior and user-facing decisions.

In the proposal card, the displayed state is re-read when the document version or card state changes. This is a useful implementation detail to inspect; it is not a claim that every stale-proposal or concurrent-edit case has been solved. Readers evaluating their own editor should test what happens when a teammate edits the target while a proposal is pending, when the target is removed, and when someone revisits an applied proposal.

Documents and canvases belong to the same project

The intended workflow is straightforward: write a brief in a Document Space, keep reference material and visual iterations in Canvas Spaces, and use the project's agent to help refine the work. People retain the choice of what becomes part of the project.

This is also why the repository is useful beyond a screenshot of an AI feature: developers can inspect how the application connects collaborative editing, canvas interactions and reviewable agent operations.

RepositoryUsage guideDevelopment setup

Deployment and contribution scope

License update (2026-11-03): the current main branch uses Elastic License 2.0 (Elastic-2.0), replacing the earlier Breatic Source-Available License. It is source-available; personal and organizational internal use, including business use, is permitted under its terms. Providing third parties with a hosted or managed service exposing substantial software functionality is prohibited. See the current LICENSE for the full conditions. Running the application still requires Cloudflare R2 and model services to be configured separately; public source does not make those services free or offline.

Feedback and contributions around collaborative editor/canvas interactions and setup documentation are welcome. This article is based on the public source at commit 8eaa0da9888cc6a1a8967b98faaa3e8b80f4e91d, not a new performance benchmark or independent deployment test. It was prepared with AI assistance and reviewed before publication.