Execution
Description
Section titled “Description”Execution is the runtime phase where a planned task is implemented by an agent. This page covers the operational concerns of running work chiefly the parallelism decision, which is where most avoidable cost and error enters the system.
Parallelism vs Serialism
Section titled “Parallelism vs Serialism”Running too many tasks in parallel increases the chance of generating conflicts. Conflicts are expensive in orchestrator and agent overhead: they force new task executions to address the conflict, likely by fresh agents that have lost the original implementation context, which introduces an error surface and burns tokens.
Like with humans, working in parallel necessitates infrastructure that either prevents conflict in the first place (broadcast systems, A2A communication, surface partitioning) or resolves it after the fact. Both incur a penalty. Parallelism is only ideal for work that does not conflict.
This is the local, operational view of the principle the Coordination Model establishes system-wide: reads parallelise, writes do not. The two conclusions were reached independently and agree.
Safe and Unsafe Parallelism
Section titled “Safe and Unsafe Parallelism”| Parallelise freely | Serialise or partition |
|---|---|
| Read-only exploration code search, research, log triage | Two agents writing interdependent code |
| Reviewing one diff along independent dimensions | Concurrent edits to the same files/modules |
| Independent tickets on different repos/PRs | Anything where implicit decisions can collide |
When concurrent implementation is genuinely necessary, partition the write surface: give each agent a disjoint set of files, modules, or services, isolated via git worktree-per-task, and merge only after each branch passes verification. This is how parallel writing is made safe without coordination overhead the surfaces cannot conflict because they do not overlap.
Execution as the System of Record
Section titled “Execution as the System of Record”Where execution runs matters as much as how it parallelises. Cloud execution produces the durable, auditable, isolated runs that make the system governable; local execution is a development and resilience tier. See Execution and Feedback and Agent Architecture for deployment modes, and Orchestrator for the durable-execution discipline that makes long runs recoverable.
Related Concepts
Section titled “Related Concepts”- Coordination Model - The system-wide reads-vs-writes parallelism rule.
- Planning and Execution - Produces the plan execution implements.
- Verification & the Outer Loop - The gate before a parallel branch merges.
- Orchestrator - Durable execution and conflict-aware dispatch.
- Guardrails - Per-run operational limits.