Current chapter · Six-part field guide
Part 4 of 6 Building an AI-first development system
Parallel agents need boring contracts too
Multiple agents create leverage only when scopes, ownership, dependencies, invariants, evidence, and stop conditions are explicit.
Parallelism without ownership is just faster confusion.
More agents are not a strategy
It is tempting to treat agent count as a measure of sophistication. If one agent is useful, five agents working simultaneously should be five times as useful. Real repositories do not cooperate with that arithmetic. Features share routes, schemas, components, design tokens, tests, and assumptions. Parallel work amplifies those relationships whether the plan acknowledges them or not.
I use parallel agents when the work can be divided into independently reviewable outcomes. Research, implementation, test design, content work, and evidence collection can often proceed together. Two changes that both redefine the same source of truth usually cannot.
The important capability is not spawning more work. It is describing ownership well enough that each participant can move without silently changing the ground beneath another participant.
A sanitized collision in a shared route
In a sanitized routing exercise, one agent was asked to add a new feature route while another reorganized the shared navigation and fallback behavior. Each change passed its focused checks. When combined, the route was registered twice and the new fallback order made one deep link resolve through the wrong branch.
Neither agent had behaved irrationally. Both had been given permission to edit the same coordination surface without being told that the other task existed. The failure happened in the contract between the tasks, not inside either local implementation.
The artifact I use here is an agent work contract. It records the objective, required inputs, allowed and protected surfaces, dependencies, invariants, acceptance evidence, handoff format, and stop conditions. It also names the shared sources of truth that the agent may read but must not redefine. A short contract prevents more confusion than a long prompt that describes the feature but ignores ownership.
What I automate
I automate dependency discovery and work allocation where the repository provides enough evidence. The system can identify files, routes, schemas, and components touched by several tasks. It can propose a dependency graph, reserve shared surfaces, sequence conflicting work, and dispatch genuinely independent tasks in parallel.
The agents can report progress in a structured form: assumptions introduced, files changed, checks run, requirements covered, and new dependencies discovered. If an agent reaches a protected surface or finds that its task depends on an unresolved product decision, it should stop and return the conflict instead of expanding its authority.
After the parallel work returns, automation can assemble the evidence, run aggregate checks, compare assumptions, and flag overlapping changes. A passing local test is useful, but the integration gate must evaluate the combined product behavior.
What remains a human decision
Humans decide whether the decomposition makes sense at the product level. File boundaries are not always responsibility boundaries. Two tasks may touch different components while still changing the same user workflow, permission rule, or state transition.
A human also decides which task owns a cross-cutting concern and when parallelism should be reduced. If a route contract, shared state model, or component API is still being defined, serializing that decision can be faster than asking several agents to build against moving assumptions.
The final review has to consider the combined experience. Did the user path remain coherent? Did one implementation invalidate another task's evidence? Did a shared abstraction become more confusing even though each individual diff looked reasonable? Those are system questions, not merge questions.
The trade-off is coordination before motion
Contracts introduce overhead. For small independent tasks, a lightweight scope and acceptance check may be enough. For tightly coupled work, pretending that a detailed contract makes the tasks independent can be worse than acknowledging the dependency and sequencing them.
I am comfortable leaving some work sequential. The goal is not maximum concurrency. The goal is the highest amount of bounded autonomy the system can support without losing ownership or proof. Sometimes one decision has to become stable before several implementation paths can open.
A scalable agent workflow is therefore quieter than the dramatic version. Tasks have names, boundaries, handoffs, and stop conditions. Shared truth has an owner. Conflicts become visible early. The agents can move quickly because the contracts are boring enough to trust.