Unity and DevelopmentUnity and codeAdvanced~7 min

Multi-Agent Ownership, Handoffs, and Conflict Avoidance

Snapshot

~85 sec

Multi-agent work scales through ownership, not agent count. An orchestrator defines scope and acceptance evidence; read-only explorers gather context; narrow workers own disjoint files or assets; and a reviewer integrates handoffs. Do not allow simultaneous writes to the same file. MCP exposes capabilities, but it is not a scheduler or conflict resolver.

You will learn

Separate orchestrator, read-only explorer, narrow worker, and integration responsibilities.
Partition parallel work by disjoint file, asset, and external-state ownership.
Require handoffs with scope, diff, tests, evidence, risks, and unresolved integration work.

Target outcome

You can design a multi-agent task graph that limits write conflicts and makes each result independently reviewable.

01
Six roles and artifacts
- Orchestrator
  Defines the objective, partitions ownership, writes acceptance criteria, and reviews evidence.
- Read-only explorer
  Maps context and dependencies without changing files, assets, or external state.
- Narrow worker
  Owns one bounded, disjoint write set and produces verification evidence.
- Ownership map
  Names exact write paths plus read-only dependencies and forbidden shared surfaces.
- Handoff
  Reports scope, diff, tests, evidence, risks, and work still owned by the integrator.
- Integrator
  Reviews combined state, resolves sequencing, runs cross-cutting checks, and decides acceptance.
02
Fan out only after ownership is disjoint
The orchestrator first maps the task. A read-only explorer may reduce uncertainty; workers then run in parallel only when their write sets do not overlap.
Orchestrator
Define acceptance
Name outcome, constraints, exact evidence, and shared-state boundaries.
Partition ownership
Parser file goes to Worker A; separate documentation fixture goes to Worker B.
Read-only explorer
Map dependencies
Inspect an invented settings module and scene-reference registry without writing.
Worker A
Implement parser
Worker A writes only src/settings/parser.ts and its owned test fixture.
Worker B
Write usage fixture
Worker B writes only docs/settings-example.md with no parser edits.
Integrator / review
Submit evidence
Each worker reports exact diff, tests, risks, and unresolved integration.
Review combined state
Integrator checks both handoffs and runs cross-cutting validation.
- Define acceptanceMap dependenciesasks read-only
- Map dependenciesPartition ownershipreports dependencies
- Partition ownershipImplement parserowns disjoint file
- Partition ownershipWrite usage fixtureowns disjoint file
- Implement parserSubmit evidencedelivers
- Write usage fixtureSubmit evidencedelivers
- Submit evidenceReview combined stateenables
The orchestrator first maps the task. A read-only explorer may reduce uncertainty; workers then run in parallel only when their write sets do not overlap.
Reading order
1. Define acceptance
  Name outcome, constraints, exact evidence, and shared-state boundaries.
2. Map dependencies
  Inspect an invented settings module and scene-reference registry without writing.
3. Partition ownership
  Parser file goes to Worker A; separate documentation fixture goes to Worker B.
4. Implement parser
  Worker A writes only src/settings/parser.ts and its owned test fixture.
5. Write usage fixture
  Worker B writes only docs/settings-example.md with no parser edits.
6. Submit evidence
  Each worker reports exact diff, tests, risks, and unresolved integration.
7. Review combined state
  Integrator checks both handoffs and runs cross-cutting validation.
Connection explanations
1. Define acceptance → Map dependencies (asks read-only)
  Exploration stays read-only so dependency discovery cannot collide with implementation.
2. Map dependencies → Partition ownership (reports dependencies)
  The ownership plan is based on observed dependencies rather than guessed file boundaries.
3. Partition ownership → Implement parser (owns disjoint file)
  Worker A receives one exact implementation surface and no shared registry write.
4. Partition ownership → Write usage fixture (owns disjoint file)
  Worker B can proceed concurrently because its write path is disjoint.
5. Implement parser → Submit evidence (delivers)
  Implementation is not complete until its diff, tests, and remaining risk are visible.
6. Write usage fixture → Submit evidence (delivers)
  A content handoff follows the same evidence contract as a code handoff.
7. Submit evidence → Review combined state (enables)
  The integrator accepts combined work only after reviewing both local and cross-cutting evidence.

Disjoint parallel work versus shared-file contention

Approach	Write ownership	Coordination cost	Review evidence	Conflict behavior
Two workers edit one registryBoth workers add entries to the same central file while their turns overlap.	Neither worker has exclusive authority over the current file state.	Every edit depends on message timing, rebasing, and knowledge of the other worker's pending diff.	A passing local test may describe a file version that no longer exists.	Text merges can succeed while semantic ordering or registrations are duplicated.
Workers own separate surfacesWorkers implement independent files; the orchestrator owns the later shared registry integration.	Each write set is exclusive and the shared file has one later owner.	Workers need the contract and acceptance criteria, not continuous edit-level synchronization.	Each handoff maps directly to an exact diff and targeted tests.	Cross-cutting failures appear during the explicit integration step instead of hidden concurrent writes.

Continue next
MCP Observability: From Tool Calls to Task Success
Once ownership is traceable, measure whether the combined task actually reached its verification gate.
04
Make a worker handoff independently reviewable
Invented worker brief and delivery. It names both write ownership and read-only context, then returns evidence without claiming the integrator's remaining work.
Languagetext
```
TASK
Implement the invented settings parser only.

OWNERSHIP
- Write: src/settings/parser.ts
- Read: src/settings/schema.ts, tests/settings/**
- Do not edit: build config, scene assets, shared registry

DELIVERY
- Summary: parsed bounded key/value input
- Diff: src/settings/parser.ts only
- Tests: settings parser 8/8
- Evidence: invalid keys rejected; existing format preserved
- Risks: caller still owns registry integration

STATUS
Ready for orchestrator review. No commit created.
```
Code annotations
1. Lines 1-8
  Bound the worker before execution
  Task, exact write path, read-only dependencies, and forbidden shared surfaces are explicit.
  Effect: The worker can progress without guessing whether it owns a registry or asset.
2. Lines 10-15
  Report proof and limits
  Summary, diff, test result, evidence, and risk describe what was actually completed.
  Effect: The orchestrator can verify the work without reconstructing the worker's entire context.
3. Lines 16-17
  Do not claim integration
  The worker declares review readiness and no commit, while registry integration remains with the orchestrator.
  Effect: Completion status matches the worker's owned scope.
Expected output
Reviewable handoff
The orchestrator can inspect one owned diff, reproduce the targeted tests, evaluate the stated risk, and decide when shared registry integration should occur.
Warning
A worktree isolates files, not every shared resource
A Git worktree gives an agent a separate working tree and typically a separate checked-out branch, which reduces file-state collisions. Linked worktrees still share the repository's object database and refs, and they do not isolate external services, caches, build outputs, ports, Unity Editor state, or other resources outside the worktree. Assign those resources explicitly too.
Anti-pattern
MCP is not a scheduler or conflict resolver
MCP can expose task data and operations, but it does not partition ownership, lock files, order agents, resolve semantic merges, or validate handoffs. Those controls belong to the orchestrator and repository workflow. Codex subagents can help with bounded read-heavy exploration or disjoint implementation, but each one spends tokens and adds briefing, messaging, verification, and integration cost. Overlapping write-heavy work often costs more coordination than it saves. Use a single owner or explicit serialization for shared MCP writes, prefer the smallest useful agent set, and do not rank clients by agent count.
Partition an overlapping plan
Two workers are ready to implement separate MCP lesson bodies, but both also need to edit the same lesson registry and run one shared Unity Editor instance. What should the orchestrator change before parallel work starts?
Expected reasoning
Give each worker exclusive ownership of separate body files and keep the shared registry with one later integration owner. Treat the Unity Editor as a serialized shared resource or keep it out of the parallel body-writing tasks. A read-only explorer can map registry requirements first. Require each worker to hand off its exact diff, targeted tests, evidence, and risks. Worktrees may isolate file state, but they do not make the shared Editor or shared refs conflict-free.

Go deeper

Git documentation: git-worktreeOfficial reference for isolated linked working trees when parallel work needs filesystem separation.
Codex documentation: SubagentsCurrent guidance for bounded delegation, parallel work, and collecting worker results.
Codex documentation: AGENTS.mdCurrent repository instruction and scope hierarchy used to constrain agent work.

You will learn

Target outcome

Six roles and artifacts

Orchestrator

Read-only explorer

Narrow worker

Ownership map

Handoff

Integrator

Define acceptance

Partition ownership

Map dependencies

Implement parser

Write usage fixture

Submit evidence

Review combined state

Reading order

Connection explanations

Disjoint parallel work versus shared-file contention

Code annotations

Bound the worker before execution

Report proof and limits

Do not claim integration

Partition an overlapping plan

Go deeper