Inside Opus · Part 4 of 13
This series follows a hypothetical supplier-invoice exception workflow. So far the articles have covered how the executor runs it (Part 2) and what happens inside its Agent node (Part 3). This article moves to design time: how the workflow gets built and changed. Part 1, “A piece of work through Opus”, is the map.
Two sensible edits that do not fit together
The Code node in our invoice workflow consumes the Agent’s extracted fields and emits a checked_total field. The final Integration node reads that field when it records the approved outcome. A process specialist proposes a second approval for invoices above a threshold: a new Human Task that reads checked_total after the Code node.
At the same time, design agents propose renaming the Code node’s output to validated_total and updating the existing final Integration node to read that name. Each proposal works against the current workflow. Applied together, however, the new Human Task still asks for checked_total, which the renamed Code output no longer supplies. The new approval’s input mapping needs to be resolved before those changes can form a coherent version.
This is the ordinary problem of concurrent editing, made sharper by the fact that some of the editors are agents that can propose changes quickly and in parallel.
The requirement
The system must let several people and several agents work on one workflow at once, must have a single answer to “what is the current version,” and must record how the design got there. The third clause matters as much as the first two. A workflow is production software, and the reasons for its shape are worth keeping.
Talking is not editing
The first distinction the design environment makes is between conversation and a proposed change. Participants in a design session share a chat. Much of what is said there is discussion: a question about why a node exists, a suggestion, a disagreement. Some of it is actionable: “add a second approval above this amount.”
A chat agent interprets what is said and separates discussion from design intent. A question is answered. A request for a change becomes a design task for specialist agents. Nothing said in chat modifies the workflow directly. This sounds obvious, but it is what keeps the conversation useful as a record: the chat is where the reasons live, and the edits are separate objects that can be accepted or rejected.
Workflow rooms
In this design, a workflow is edited inside a room. Users and agents join the room to view its context, submit edits or take part in the session. The room holds the current workflow state, the chat state, and the state of any agent sessions working on it.
The room is also an authorization boundary. The described authorization model requires permission to join a workflow room and ties a design agent’s permissions to the session that invoked it. Part 7 explains how that model applies to collaboration and execution.
Specialist agents, coordinated
The design agents are not one general assistant. The specialists include a process architect, a layout designer, a code agent, a prompt engineer, a system integrator, a data scientist, a policy officer, a risk manager, a quality-assurance agent and an AI transformation specialist. A platform service coordinates them; I will call it the design-agent coordinator.
The coordinator decomposes a request into tasks, dispatches them to worker agents, tracks what is pending, and consolidates results. A worker agent, before proposing anything, retrieves the context it needs: the current workflow, relevant workspace and organizational context, marketplace components it might reuse, and prior design learnings that apply in this scope. It then generates a proposed change, expressed as a delta to the workflow, and reports back.
In the invoice example, the request “rename the checked total consistently” goes to the code agent, which proposes changing the Code output from checked_total to validated_total, and to the system integrator agent, which proposes updating the existing final Integration node to read validated_total. The coordinator consolidates those complementary changes into a proposed edit. That delta must still be reconciled with the person’s concurrent approval-node proposal.
From proposal to authoritative state
Here is the mechanism that answers the opening problem. The collaboration service is the authority for workflow state. Users and agents may propose edits, but only changes that the service has resolved become part of the controlled workflow version. Once resolved, the service broadcasts the outcome to every connected participant: accepted, rejected or updated.
So the process specialist’s new approval node and the agents’ coordinated changes to the Code output and final Integration mapping arrive at the collaboration service as proposals. The service resolves them against the current state, determines the resulting version, and tells everyone in the room what the workflow now looks like. In this example, resolving both means bringing the new approval’s field mapping into agreement with the Code output, or declining one of the proposals. A proposal can be rejected or returned for revision, and the participant who made it sees why.
The specifics of how conflicting proposals are reconciled are an implementation detail I will not go into here. What matters architecturally is where the authority lies and what participants observe: one server-side authority, proposals resolved into versions, outcomes broadcast to everyone.
The state is persisted through a queue so that configured workflow versions, chat traces and agent-session traces are retained independently of any client. Their recorded content and availability remain subject to the applicable capture, audit, access and retention settings.
Keeping the design trace
The design trace can record chat messages, user edits, agent actions, proposed changes, accepted changes, rejected changes and resulting workflow versions under those settings. This is the design-time counterpart of the execution trace from Part 3.
The trace has two uses. The first is explanation. Six months from now, someone may ask why the second approval node exists and why the Code node emits validated_total. Where that history remains available, the retained chat and accepted edits can help answer. The second is learning. Reviewed patterns from design sessions can improve later sessions, subject to the same scope and permission rules that govern runtime learning. If the coordinated rename was accepted and the resulting workflow performed well, that is evidence a later design agent in the same scope might use. Part 5 explains where that evidence may be used; Part 6 explains how it qualifies.
One boundary to hold: accepting an edit into a workflow version is a design decision. It is not the same as approving that version for production. Release is a separate step, and Part 11 covers it.
The authority boundary is the same when a proposal begins in chat. The coordinator prepares the edit that the collaboration service must resolve.
The alternative, and the cost
A single editor with an assistant is simpler and entirely adequate for sequential work. If one person owns the workflow and asks an agent for help, there is no conflict to resolve.
Distributed replicas, where each participant holds a copy and the copies converge, serve other collaboration needs well, particularly when participants are often offline. They trade a single authority for eventual convergence.
The server-authoritative design gives workflow changes one acceptance point, making the design trace coherent and providing a defined place to apply authorization to proposed edits. Its cost is that coordination is concentrated: the collaboration service has to handle conflicts well and quickly, and latency to it is felt by every participant. When many agents propose in parallel, the resolution step is where the pressure lands.
Next
The design agents in the room retrieved prior learnings before proposing anything. When the team comes back tomorrow, or when a different team in the same organization opens a similar workflow, what should those agents remember, and what must they not? Part 5 is about scope.