Summary
A process specialist proposes a new approval node that reads checked_total while design agents concurrently propose renaming that field to validated_total; each edit is sensible against the current workflow and they do not fit together. This is ordinary concurrent editing, made sharper because some editors are agents that propose quickly and in parallel.
The design environment’s first distinction is between conversation and change: a chat agent interprets what is said and separates discussion from design intent, so nothing said in chat modifies the workflow directly — which is what keeps the chat useful as the record of reasons while edits remain separate objects that can be accepted or rejected. Editing happens inside a workflow room that holds current workflow state, chat state and agent-session state, and that also acts as an authorization boundary tying a design agent’s permissions to the session that invoked it.
The design agents are specialists rather than one general assistant — process architect, layout designer, code agent, prompt engineer, system integrator, data scientist, policy officer, risk manager, QA agent, transformation specialist — coordinated by a service that decomposes requests, dispatches tasks and consolidates results into a proposed delta. The architectural answer to the opening problem is that the collaboration service is the single authority for workflow state: proposals are resolved into versions and outcomes are broadcast to everyone in the room, with the reconciliation specifics treated as implementation detail.
The design trace then serves explanation (why does this node exist?) and learning (reviewed design patterns improving later sessions), with a boundary held firmly: accepting an edit into a version is a design decision, not approval for production. The cost of server-authoritative design is concentrated coordination — conflicts and latency all land on one service, especially when many agents propose at once.