# Every edit survived. The application still broke. Preserving concurrent edits does not ensure they make sense together. Separate convergence, work ownership, dependency checks, and application invariants. _Architecture · 2026-10-16 · 4 min read · by Ablo Team_ Convergence preserves shared work. Correct collaboration also needs agreement about what that work means. ## Key takeaways - Converging on the same text does not prove that the program is correct. - Distinguish an atomic ownership claim from enforcement of every write. - Combine shared visibility with the checks required by the application. Two agents edit a service together. One renames a function; another adds a caller using the old name. The editor preserves both changes perfectly. Everyone converges on the same source tree, and the build fails. Nothing was lost in the merge. The incompatible assumptions survived alongside the edits. A collaboration design needs to say which layer detects that mismatch and what happens next. ## Keep the guarantees separate A text collaboration mechanism answers how edits from several participants combine. Work ownership answers who intends to change a resource. A compiler or integration test checks another set of constraints. These mechanisms can support one another, but none silently supplies all the others. ![Creatures install two components on one chassis, but their outlet and inlet do not line up.](/blog/coordination/merge-versus-meaning.webp) Keeping both contributions is different from making them compatible. The same distinction applies to concurrent source edits. AgentRoom is a useful example because it combines a CRDT-backed shared workspace with explicit claims, status, and broadcasts. Its file-claim operation rejects conflicting ownership, while compliance by arbitrary filesystem writers remains advisory. It is therefore inaccurate to frame its architecture as CRDTs instead of coordination. ## A claim needs a stated enforcement boundary An atomic claim can prevent two participants from both receiving ownership. It does not necessarily prevent a process from writing around that claim. In an advisory system, the application relies on participants to cooperate and uses observation or review to handle exceptions. A mandatory boundary must mediate the relevant writes. Neither choice should be hidden in the word “lock.” Cooperative editing may deliberately allow a teammate to make an unblocking fix. An update to a customer record may need a stricter rule. The design should explain who can bypass ownership, how that action is attributed, and which subsequent checks still apply. ## Read the evaluation at its actual scale AgentRoom reports reduced abandonment and variation with two agents in its tested coding setup. Its main tasks share an Express/TypeScript environment, and much of the quality evaluation uses judge-based composites rather than held-out execution tests. Larger groups do not improve quality monotonically. The paper also includes smaller Python and Rust checks, which it treats as bounded portability evidence. That makes it useful architectural evidence, with a specific empirical scope. It does not establish that live shared editing always beats branches, that advisory claims enforce every write, or that preserving bytes guarantees software correctness. ## Choose the boundary from the work For a collaborative codebase, we would want visibility of in-progress changes, clear ownership, dependency checks, and a reviewable integration result. For shared application records, we would ask whether a write still matches the state it depended on. Ablo’s captured-read guards address that application boundary; they do not automatically wrap arbitrary source-file edits. A focused demonstration should preserve two edits that conflict in meaning, then show the check that catches the result. That is more informative than a perfectly synchronized cursor: it reveals how the system behaves when collaboration becomes difficult. ## Sources and further reading - [AgentRoom: Concurrent Multi-Agent Coding in a CRDT-Backed Shared Workspace](https://arxiv.org/abs/2608.23740) — Cho and Lee, August 2026 preprint. Full 26-page PDF reviewed; Sections 2, 4, and 7 and Appendices B, C, and E explain advisory claims, evaluations, and limitations. - [Ablo coordination guide](https://docs.abloatai.com/coordination) — The documented boundary for claims and explicit read dependencies on shared application records. ## Frequently asked questions ### Can a CRDT prevent a broken API contract? A general text CRDT preserves and merges edits. An API contract needs additional semantic checks, such as typechecking, integration tests, or validation at the relevant application boundary. --- Canonical URL: https://www.abloatai.com/blog/shared-editing-needs-more-than-a-merge Also machine-readable on this domain: /llms.txt, /llms-full.txt, /openapi.json, /sitemap.xml, /robots.txt