Adding more agents to a coding workflow can create more motion without creating more progress.
The reason is simple: a repository, specification, document, or deployment plan is not just a collection of files. It is a changing set of decisions. When two agents touch the same decision surface, the problem is not merely whether their outputs can coexist. It is whether each change still means what its author believed it meant when it was proposed.
“Last writer wins” resolves a collision. It does not resolve responsibility.
A later change can silently erase a constraint, replace a stronger explanation with a weaker one, reintroduce an assumption that another task already invalidated, or make a narrow test pass while the broader task becomes incoherent. None of those outcomes requires bad intent or a broken tool. They happen when the workflow treats writing as the only event that matters.
Parallel work is safe only when the work boundaries and reconciliation duties are as explicit as the tasks themselves.
Git worktrees are useful because they make it easier for people or agents to work in separate directory views. The Git worktree documentation also makes clear that some repository information is shared. That is a healthy reminder: physical separation is not the same as semantic isolation. A separate work area does not answer who owns a decision, what assumptions a change depends on, or how competing proposals will be reconciled.
Distinguish parallel exploration from shared change
Not all parallel work has the same coordination cost.
- Work shape: Independent research — Good use of parallelism: Compare sources, alternatives, or design options — Primary risk: Duplicate effort or inconsistent evidence posture — Useful control: Shared question, source standards, and synthesis owner
- Work shape: Independent analysis — Good use of parallelism: Inspect separate modules, logs, or requirements — Primary risk: Different agents draw incompatible conclusions — Useful control: Explicit assumptions and a common decision record
- Work shape: Disjoint changes — Good use of parallelism: Prepare isolated edits or drafts with little shared meaning — Primary risk: A hidden dependency crosses the boundary — Useful control: Declared work surface and integration check
- Work shape: Shared mutable change — Good use of parallelism: Alter the same contract, workflow, or user-facing behavior — Primary risk: Lost updates, stale assumptions, and unclear responsibility — Useful control: Bounded ownership plus reconciliation before promotion
The first three shapes can benefit substantially from parallel effort. The fourth needs coordination before it needs more writers. Anthropic's accounts of a long-running application-development harness and a multi-agent research system provide first-party examples of structured task artifacts and the uneven parallelizability of different work. They do not establish the packet proposed here, but they help explain why shared-change coordination differs from broad research fan-out.
This is why raw task count is a misleading measure of agent throughput. If every task eventually touches the same narrow decision, adding workers can increase review and merge cost faster than it increases useful output.
The Change Ownership Packet
The Change Ownership Packet is a proposed lightweight record for a task that may alter a shared or consequential work surface. It is not a lock, a permission system, or a claim that every change needs a committee. It gives a team enough shared context to decide whether work can proceed independently or requires an owner and a reconciliation point.
- Packet field: Work surface — What it records: The user-visible behavior, contract, document section, or decision area expected to change — Why it matters: Makes ownership about meaning, not just a filename or ticket title
- Packet field: Intended outcome — What it records: The condition the change is meant to improve or preserve — Why it matters: Keeps a technically valid edit from drifting away from the actual task
- Packet field: Observed base and preconditions — What it records: What the agent inspected, what it assumes is true, and what would invalidate the plan — Why it matters: Reveals when a proposal was built on a stale view
- Packet field: Owner and boundary — What it records: Who is responsible for advancing this surface and which neighboring work remains out of scope — Why it matters: Gives collaborators a reason to coordinate before crossing a boundary
- Packet field: Effect allowance — What it records: What kind of change may be proposed, prepared, or applied under the current task rules — Why it matters: Separates technical ability from authorization to make an effect
- Packet field: Validation evidence — What it records: What review, test, comparison, or source check can support the change — Why it matters: Prevents “it ran” from becoming the entire quality argument
- Packet field: Reconciliation decision — What it records: Who compares concurrent work, how conflicts are resolved, and what becomes the current accepted state — Why it matters: Makes integration a named responsibility rather than an accidental side effect
The packet need not be bureaucratic. A small change may carry these fields in a concise task record; a large effort may need a richer change brief. The point is that the same facts are explicit before several agents build on them independently.
Why the final diff is not enough
A final diff can show what changed. It cannot always show:
- why the agent believed the old behavior was wrong;
- what source, test, or requirement supported the new behavior;
- which assumptions had to remain true while the work was underway;
- whether another task intentionally changed the same area; or
- whether the agent had authority to apply rather than merely propose the change.
This missing context is especially costly in agent workflows because agents can operate quickly and serialize their conclusions fluently. A reviewer may see two individually reasonable proposals and still lack the information needed to decide whether they are compatible.
The remedy is not to forbid parallel work. It is to make the preconditions and reconciliation rule visible before conflict becomes a surprise.
Choose a topology before launching writers
Before assigning work, ask one question: are these tasks independent in their meaning, not only in their files or tools?
If yes, use parallelism for exploration, drafts, or separately bounded changes. Give each worker the same objective, source standards, and a clear handoff format.
If no, choose one of three healthier patterns:
- Single owner, multiple advisers. Several agents investigate, test, or critique, but one owner synthesizes and advances the shared change.
- Sequential handoff. One task establishes a stable decision or interface, then a later task builds on that declared base.
- Concurrent proposals, deliberate reconciliation. Multiple agents may prepare alternatives, but none is treated as current until a named reconciliation step compares them.
These patterns are not less ambitious than a free-for-all. They allocate parallelism to the parts of work that can actually benefit from it.
Reconciliation is a product decision
The word “merge” can make coordination sound mechanical. For agent systems, reconciliation often requires a product or architecture judgment:
- Do both proposals preserve the same user intent?
- Did one rely on evidence the other disproved?
- Is a difference merely stylistic, or does it change a boundary, promise, or operational posture?
- Are there unresolved disagreements that should stay visible rather than being averaged away?
- What evidence supports the accepted version?
The reconciler may be a human, an agent with explicitly bounded review authority, or a staged combination of both. What matters is that the workflow names the role and retains the decision rationale.
This is also where an agent should abstain rather than write over a conflict it cannot resolve. A contradiction in assumptions is not a formatting issue. It is a request for a decision owner or a new source check.
Validate both locally and at the boundary
Local validation asks whether a proposed change behaves as expected inside its own task. Boundary validation asks whether it remains compatible with adjacent work, user intent, approval conditions, and the shared system state.
Both are necessary.
- Validation level: Local — Question: Did this proposal satisfy its stated outcome? — Example evidence: Focused tests, source checks, or review against its own acceptance condition
- Validation level: Boundary — Question: Did the proposal preserve the conditions other work depends on? — Example evidence: Contract comparison, integration review, compatibility cases, or designated-owner approval
- Validation level: Lifecycle — Question: Is the proposal still valid when it is promoted? — Example evidence: Recheck of the observed base, unresolved dependencies, and relevant task constraints
The terms are intentionally broad. A documentation change, a data workflow, and an application change all need different evidence. The shared habit is to validate the change in the context where it will be relied upon, not only in the context where it was created.
Make ownership expire or be renewed
Ownership is useful only while its premises remain current. If a task waits while another change lands, a previously valid packet can become stale. If a blocker changes the problem, a team may need to reassign the work or reopen the intended outcome.
Treat ownership as a claim that can be renewed, narrowed, transferred, or released. A resumed task should verify its observed base and boundaries before it acts as though nothing changed. This avoids two opposite failures: holding a surface forever because an old task still appears to own it, or allowing a stale task to overwrite newer reasoning.
This does not require a complicated lease mechanism. It requires a visible question at the right moment: “Is this still the same work surface, with the same conditions, and is this worker still the right owner?”
Useful measures
Teams can learn whether their coordination model is helping by tracking:
- Overlap rate: How often do supposedly independent tasks touch the same decision surface?
- Reconciliation yield: How often does review discover a meaningful difference rather than merely formatting variation?
- Stale-base rate: How often is a proposal based on an observation that changed before promotion?
- Owner clarity: Can a reviewer identify the current decision owner without reconstructing the whole thread?
- Boundary regression rate: How often does a locally successful change violate an adjacent constraint or expectation?
- Parallelism value: Did concurrent work reduce time to a trusted result, or only increase the number of artifacts to reconcile?
These are not productivity quotas. They are signals that show whether parallelism is producing independent evidence and useful alternatives, rather than collisions.
A practical adoption path
- Pick one workflow where multiple agents currently produce overlapping edits or contradictory conclusions.
- Define the work surfaces in user-facing terms: a behavior, contract, decision, or document promise.
- Add the seven packet fields to tasks that may change a shared surface.
- Route research and critique to parallel workers; assign a single owner when the work becomes mutually dependent.
- Require an explicit reconciliation decision before treating a concurrent proposal as current.
- Add one stale-base scenario and one conflicting-assumption scenario to the review suite.
- Retire fields that add no clarity, but keep the evidence and ownership fields that prevent repeat failures.
The point is not to make every agent ask permission to type. It is to make shared changes legible enough that speed does not erase responsibility.
What we are learning building Virillio Code
Virillio Code is in development. Broad work on durable tasks, concurrency, and work boundaries suggests that safe multi-agent progress depends on more than separate execution contexts. Teams need a way to preserve who owns a changing decision, what the work depends on, and how the final state was reconciled. The Change Ownership Packet is a proposed educational framework, not a description of released product internals.
Sources and further reading
- Git worktree documentation — Git supports multiple linked working trees while some repository information remains shared.
- Harness design for long-running application development — Anthropic — Structured task artifacts and explicit state help work continue across many model turns or sessions.
- How we built our multi-agent research system — Anthropic — Multi-agent collaboration has coordination limits, and coding work has fewer naturally parallelizable tasks than broad research.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.