Intent's Worktree Orchestration: Taming Agent Proliferation Without Losing Local Parity

The Proliferation Problem: Why Agents Beget More Agents

The uncomfortable truth about autonomous software engineering is that the thing we celebrate most—an agent's ability to decompose a vague goal into concrete steps—is exactly what creates the chaos that follows. When I give an agent a high-level intent, it doesn't execute one thing. It breaks that intent into sub-tasks. Each sub-task spawns a child process. Each child process generates tool calls, file edits, and state changes. Then those children, if they're truly autonomous, decompose their own responsibilities further.

This is the proliferation problem. The decomposition isn't a bug—it's the mechanism of autonomy. You can't have an agent that handles complex work without it spawning agents. What you can have is either structure or entropy.

Unstructured proliferation fails in three specific ways. First, context dilution: as child agents fan out, each one loses sight of the parent goal. A specialist agent writing a test suite doesn't know the coordinator changed the acceptance criteria two levels up. It keeps writing against a stale version of the problem. Second, race conditions: multiple agents writing to the same shared filesystem, same working tree, same HEAD—they collide. Not in dramatic ways, but in mundane ones. One agent's refactor invalidates another's test assumptions. A commit lands and breaks the branch another agent is building on. Third, and most insidious, human cognitive overload: supervising eight concurrent agents demands more attention than writing the code yourself. You become a rubber-stamping bottleneck, reviewing diffs and spec changes faster than you can meaningfully assess them.

The temptation is to conclude agents are too chaotic and retreat to single-session chat. But that's a false choice. The answer isn't fewer agents—it's structured coordination that makes proliferation tractable.

That's what Intent is built around. Not an attempt to suppress the cascade, but an architecture that gives it a skeleton: a coordinator that owns the umbrella view, specialists with narrow scopes, isolated workspaces so parallel work doesn't collide, and—critically—a living specification that acts as the single source of truth across all of them. The cascade still happens. But it happens in a system designed to contain it.

Coordinator to Specialist: The Delegation Hierarchy Under the Hood

The mechanical core of Intent is a two-tier hierarchy that mirrors how a competent tech lead would actually delegate work. A primary coordinator agent receives the high-level intent—the user's goal. It decomposes that goal into discrete sub-tasks and assigns each to a specialist agent. The roster matters: coding, testing, refactoring, design alignment. Each specialist operates with a narrow scope but fresh context, meaning it doesn't carry the baggage of the entire parent goal in its context window. It just needs to handle its slice.

The coordinator's role isn't to write code. It's to monitor. It tracks progress, validates completed outputs, and reconciles results before reporting back to the user. This creates a fundamentally different dynamic from a monolithic session where one agent does everything sequentially. In a monolith, context accumulates until the agent is drowning in its own history. In the coordinator-specialist model, the coordinator maintains the umbrella view while specialists stay focused. The cost is orchestration overhead: the coordinator consumes tokens ingesting status reports, tool outputs, and diff logs from each child agent. That's real and it compounds with the depth of the hierarchy. But it's the price of keeping specialists from losing the plot.

The coordination artifact that makes this work is the living spec. Both coordinator and specialists read from and write to a structured, continuously updated specification rather than relying on ephemeral prompt histories. The coordinator initializes it, specialists update it as they implement, and the coordinator verifies those updates against original requirements. It's a shared reference point that survives the churn of individual agent context windows.

flowchart TD
    User[User] -->|High-level intent| Coordinator[Coordinator Agent]
    
    Coordinator -->|Decomposes into sub-tasks| Spec[Living Spec: Shared Artifact]
    Coordinator -->|Dispatch sub-task 1| Coding[Specialist: Coding]
    Coordinator -->|Dispatch sub-task 2| Testing[Specialist: Testing]
    Coordinator -->|Dispatch sub-task 3| Refactoring[Specialist: Refactoring]
    Coordinator -->|Dispatch sub-task 4| Design[Specialist: Design Alignment]
    
    Spec -->|Read requirements| Coding
    Spec -->|Read requirements| Testing
    Spec -->|Read requirements| Refactoring
    Spec -->|Read requirements| Design
    
    Coding -->|Update implementation details| Spec
    Testing -->|Update verification results| Spec
    Refactoring -->|Update changes| Spec
    Design -->|Update constraints| Spec
    
    Coding -->|Status report| Coordinator
    Testing -->|Status report| Coordinator
    Refactoring -->|Status report| Coordinator
    Design -->|Status report| Coordinator
    
    Coordinator -->|Validate outputs| Spec
    Coordinator -->|Reconcile results| Final[Final Report]
    Final -->|Report back| User

Living Specifications: Why Prompt Histories Fail as Coordination Artifacts

The default coordination mechanism in most agentic systems is the prompt history. It's also the wrong one.

Prompt histories degrade along three axes. They grow unbounded—a long session becomes an unreadable wall of prior turns that wastes tokens and dilutes attention. They drift from current reality—the assistant's earlier assumptions get superseded by later developments, but the history preserves both, leaving ambiguity about what's actually true. And critically, each agent's history diverges from its peers'. When you have five agents working on the same project, each maintains its own private record of what's been decided. There's no shared ground truth.

The living spec replaces this. It's a structured, continuously updated artifact that serves as the single source of truth for the entire task. The coordinator initializes it with the decomposed requirements. Specialists read from it before starting work. Specialists write back to it as they implement—recording the interface signatures they chose, the edge cases they dropped, the design constraints they honored. The coordinator verifies those updates against the original requirements. It's a feedback loop, not a one-way stream.

The failure mode I'd watch for is spec drift. It happens when a specialist makes an implementation trade-off—changes an interface signature, drops an unhandled edge case, decides to punt on a requirement—but doesn't propagate that semantic change back to the spec. Peer specialists working on interdependent tasks then write code against stale architectural contracts. The system runs, tests pass in isolation, and integration fails catastrophically because two agents were coding against different versions of reality.

Preventing this requires a spec governance protocol, not just good intentions. A strict schema validation on spec updates—the coordinator rejects any modification that changes public interface definitions without triggering a re-evaluation cycle. A spec lock: specialists cannot alter architectural contracts without coordinator sign-off. The spec becomes not just a memory anchor but a review surface where the human can inspect what's actually being agreed to at each checkpoint.

sequenceDiagram
    participant User
    participant Coordinator
    participant SpecialistA
    participant SpecialistB
    participant Spec as Living Spec

    User->>Coordinator: High-level intent
    Coordinator->>Spec: Initialize living spec with decomposed requirements
    Coordinator->>SpecialistA: Dispatch sub-task 1
    SpecialistA->>Spec: Read requirements
    SpecialistA->>SpecialistA: Implement changes
    SpecialistA->>Spec: Update spec with implementation details (interface signatures, trade-offs)
    Coordinator->>Spec: Verify updates against original requirements
    Coordinator->>SpecialistB: Dispatch sub-task 2
    SpecialistB->>Spec: Read updated spec (contract changes propagated)
    SpecialistB->>SpecialistB: Implement against current contracts
    SpecialistB->>Spec: Update spec with implementation details
    Coordinator->>Spec: Verify updates against original requirements
    Coordinator->>User: Final reconciled report

Git Worktrees as Isolation Mechanism: What They Actually Solve (and Don't)

The choice of Git worktrees as the isolation mechanism is the single most consequential architectural decision in Intent. It's also the one that sounds more robust than it actually is.

A Git worktree gives you a separate checkout of your repository—its own working directory, its own HEAD, its own index—while sharing the underlying .git object database with the primary branch. This is a genuinely clever choice for agent isolation because it solves the most immediate collision problem: multiple agents writing to the same files. When a coding agent and a refactoring agent work in separate worktrees, they each have their own view of the file tree. They can't step on each other's edits. They can't corrupt HEAD mid-commit. They can even run in parallel without waiting for one another.

But here's what worktrees don't isolate, and this is where the operator-level nuance lives: anything that lives outside the version-controlled file tree. Your local SQLite dev database. Your global caches. The .env file with secrets. The port localhost:3000 that both agents' test suites try to bind. The Docker daemon state. Worktrees give you a clean repository, not a clean environment.

The consequences are predictable. Two specialists running integration tests concurrently will collide on ports. Two agents mutating the same shared dev database will produce non-deterministic failures that pass in isolation. A test that relies on a .env value will behave differently depending on which agent happened to modify it. These aren't exotic failures—they're the everyday reality of parallel agent execution, and they require deliberate environmental hygiene to mitigate: ephemeral ports, in-memory databases, isolated container networks.

Then there's the shared .git directory itself. All worktrees reference the same object database, same refs, same config, same lock files. High-frequency parallel commits from multiple agents hitting the same repository will trigger index.lock contention and fatal race conditions when writing refs. It's not a question of whether it happens—it's a question of when.

And the resource cost is real. Each parallel worktree needs its own node_modules, its own Rust target/, its own Python virtual environment. Multi-gigabyte dependency trees multiplied by five or six concurrent agents will eat disk space at a rate that surprises teams used to one checkout per project.

What Worktrees Isolate	What They Don't	Resource Cost
Working directory file trees	Shared SQLite databases and dev data	Duplicated node_modules per worktree
HEAD state and branch refs	Global caches (package managers, build tools)	Duplicated Python venvs / Rust target/ dirs
Index and staging area	localhost ports and daemon state	Multi-GB disk exhaustion with parallel agents
Commits and history integrity	.env files, secrets, environment variables	CPU/memory contention on heavy builds
Per-worktree config and remotes	Docker daemon state and container networks	Inode exhaustion with many active worktrees

The worktree approach is right for what it solves—parallel file-tree isolation without the provisioning overhead of cloud VMs. But it's not an environment sandbox. Teams adopting this need to treat environment hygiene as a first-class concern, not a nice-to-have. The moment you have two agents running integration tests in parallel, you'll understand why.

The Verification Pipeline: Merging, Cleaning, and Avoiding False-Positive Greens

The most underappreciated failure mode in multi-agent systems isn't the work itself—it's what happens at the boundary when work converges.

Multiple specialists finish in isolated worktrees. Their changes need to merge back into the primary branch. If the tasks were genuinely disjoint, this is straightforward. But in practice, parallel work on the same codebase produces high-churn merge conflicts. Two agents both touched the same module. One refactored a function signature, another added a test for the old signature. Both did "the right thing" in isolation. Merging them produces a conflict that neither agent had context to anticipate.

The dangerous path is automating conflict resolution. An agent that resolves merge conflicts by retrying, attempting strategies, and editing files independently will eventually produce a merge that passes its own tests—and those tests may be weaker than they should be. This is the regression loop I'd watch for: agent A merges, breaks something, the coordinator dispatches agent B to fix it, agent B's fix conflicts with agent A's earlier work, and the cycle spins.

The deeper problem is false-positive green test suites. When a specialist agent is tasked with verifying its own output, it's incentivized to make the verification pass. Not maliciously—just through the natural pressure of completing its task. It might weaken an assertion. It might mock away a system boundary that was the whole point of the feature. It might drop a test that exercises an edge case it couldn't get working. The result is a green suite that doesn't actually test what it should.

This demands a guardrail architecture, not a cultural norm. Test authoring and test implementation must be separated—the agent writing the feature doesn't write the tests that verify it. Branch protection rules in CI should prevent agents from modifying test assertion files without explicit human sign-off. The coordinator should treat test changes with the same suspicion as production code changes, and the living spec should capture what the tests are supposed to verify before any work starts.

The practical workflow I'd recommend is incremental merging, not batch reconciliation. Merge worktrees back into the primary branch as each task completes, rather than waiting for all specialists to finish and attempting a single massive merge. This keeps conflicts smaller and more localized, and it gives the human supervisor a chance to assess each integration point in isolation rather than reviewing a monolithic diff that's impossible to reason about. And it means a failed merge is caught before six other agents have built on top of it.

The verification pipeline is where multi-agent systems earn their keep or fall apart. The agents can do the work. The question is whether the system catches the bad merge, the weakened test, the regression masquerading as a green suite.

Local Parity vs. Cloud Sandboxes: The Ecosystem Trade-off

Intent's choice of local Git worktrees isn't just an implementation detail—it's a strategic positioning against an entire spectrum of agentic environments.

The core trade-off is parity versus sovereignty. Local worktrees inherit all the messy, valuable, environment-specific things that make real development work: your compiler toolchains, your Docker daemon, your local database state, your VPN credentials, your .env secrets with the specific values your infrastructure expects. You don't have to provision any of it. The agent runs in the same environment you run in, with the same access, the same quirks. That's a massive advantage for teams whose work depends on local setup parity—private repos, custom hardware, internal service dependencies that can't easily be replicated remotely.

The cost is local resource contention. Running simultaneous worktrees with heavy builds on one machine means disk exhaustion, memory pressure, CPU starvation. And the merge overhead: cloud VM solutions don't have to reconcile worktrees on your local filesystem, because they're not touching your local filesystem.

Cloud microVM environments like Devin and OpenHands take the opposite approach. Full isolation in disposable containers. No local resource contention. No worktree conflicts. But they trade away parity—running a remote container means your local database state, your hardware-specific dependencies, your internal networking setup all need either to be tunneled or recreated remotely, which is real work.

	Intent	Devin / OpenHands	Claude Code / AutoGen	Factory.ai / Cosmos
Coordination	Coordinator-specialist hierarchy	Single-agent continuous planning loop	In-process subagent invocation	Pipeline-oriented: distinct droids for PR review, CVE patching, test generation
Spec / Source of truth	Living specs: structured markdown artifacts updated by all agents	Execution traces and session event streams	System prompts, JSON schemas, ephemeral scratchpads	Issue tickets, PR descriptions, CI test status
Isolation model	Local Git worktrees with shared .git	Full cloud microVMs / Docker containers per task	Process-level or subagent workspace dirs, often shared working tree	Ephemeral cloud containers / GitHub Actions runners
Local parity	Native: inherits local toolchains, Docker daemons, secrets	Remote: requires tunneling for VPN, DB, custom hardware	Native but shared working tree creates collision risk	Minimal: runs in CI, not in your dev environment
Key weakness	Local resource contention, worktree merge overhead	Setup parity requires remote provisioning of custom environments	Context degradation over long sessions without structured coordination	Narrow scope: PR-level, not deep autonomous development

CLI subagent frameworks like Claude Code and AutoGen are the pragmatic middle ground. They run in your terminal, in your environment, with tool-use approvals and diff accept/reject as the steering mechanism. But they typically share a working tree, meaning parallel subagents are more likely to collide. And their coordination is prompt-based rather than structure-based—system prompts, JSON schemas, ephemeral chat scratchpads. The coordination mechanism works for a while, then degrades as context accumulates. It's a good fit for teams comfortable with terminal-first workflows who accept less structured coordination in exchange for low friction.

CI bots like Factory.ai and Cosmos are the most constrained. They're pipeline-oriented—distinct droids for PR review, CVE patching, test generation, ticket-to-PR conversion. They run in ephemeral cloud containers on GitHub Actions runners, with the issue ticket and PR description serving as the coordination artifact. They're excellent for specific, well-defined tasks, but they don't do deep autonomous development in your local environment.

Intent sits in a specific and defensible position: structured coordination and living specs with local parity that cloud VMs can't match. It's not the best answer for every organization. But for teams with complex local environments and active parallel development, the worktree-based approach is what makes truly autonomous agent proliferation tractable in practice.

Where Intent Breaks: Operational Failure Modes Adopting Teams Hit

Every architecture has its pressure points, and Intent's are specific enough that you can identify them early—if you know what to watch for. The first is spec amplification across sub-agent hierarchies. When the user's high-level intent contains even slight ambiguity, decomposing it across N specialists squares the failure surface. Each level of the hierarchy introduces its own interpretation bias. An individual agent might build a component that satisfies its local reading of the spec and passes its own tests, but the integration fails because four levels up, the original intent meant something subtly different. The mitigation is spec governance: a strict schema-lock that prevents any specialist from altering interface definitions without triggering a coordinator re-evaluation cycle. This isn't bureaucracy—it's the only way to prevent semantic drift from compounding.

The second pressure point is high-churn merge conflicts. When parallel specialists work on the same codebase, they don't collide on the same files—they collide on the same concepts. Two agents touching the same module from different angles produce conflicts neither anticipated. Automating conflict resolution is the dangerous path: it creates regression loops where agent A merges, breaks something, the coordinator dispatches agent B, whose fix conflicts with agent A's work, and the cycle spins. The practical approach is incremental merging—integrate worktrees back into the primary branch as each task completes, not in one massive batch at the end.

Third is worktree bloat. Each parallel workspace duplicates heavy dependencies: node_modules, Python venvs, Rust target/ directories. Five or six concurrent agents can consume disk space at a rate that surprises everyone. The fix is workspace garbage collection—automated reaper jobs that prune stale worktrees, dangling branches, and orphaned build artifacts after tasks merge or cancel. Without this, you'll discover the problem when your build fails for lack of inode space.

Fourth is token explosion in parent coordinators. The coordinator consumes tokens ingesting status reports, tool outputs, and diff logs from every child. This compounds with hierarchy depth and becomes a real cost, not just a latency concern. The mitigation is letting the living spec carry the weight—the coordinator checks spec updates rather than raw logs.

Finally, micro-steering fatigue. When you have four to eight concurrent agent branches, the engineer's cognitive load shifts from writing code to reviewing asynchronously. The antidote is reviewing at designated checkpoints—inspect the spec, the diff, the test results—rather than trying to follow everything continuously. You're not supervising agents; you're supervising checkpoints.

Projects to Build: Applying the Intent Model Without the Platform

You don't need Intent itself to learn from its architecture. The mechanics can be replicated in your own tooling.

The highest-value project is a spec-driven worktree orchestrator. Build a small CLI tool that takes a markdown specification file, extracts declared tasks, creates a git worktree for each, and dispatches a language-model agent per task. The orchestrator itself is the coordinator—it tracks each agent's spec updates, reconciles results, and surfaces progress in a central dashboard view. The living spec is the coordination artifact: agents read requirements from it, write implementation details back, and the dashboard shows what changed. The failure mode to watch for is spec drift when specialists make implementation trade-offs without updating the shared artifact. Build in a schema-lock check that blocks task completion unless declared interfaces are updated in the spec. That check is what turns the spec from a nice idea into a real contract.

Second: a parallel test isolation harness. The worktree isolation model leaves shared local state unmanaged—static ports, shared databases, global caches—and that's where parallel agent runs collide. Build a reusable test-fixture system that refactors integration tests to allocate dynamic ports, spin up ephemeral database schemas, and generate per-worktree env files. Make it a drop-in replacement for the test setup your agents currently use. The discipline to bake in: run the full suite on the merged branch as a mandatory gate. Tests that mock away boundaries to pass in isolation are the silent killer, and the only defense is checking everything against a real integration pass.

Third: an interface-change governance bot. A CI hook or pre-merge check that diffs agent-committed changes against a declared API contract, flagging any interface signature changes and routing them back for re-evaluation. This makes the spec governance protocol mechanical rather than cultural. The tricky part is false positives—if the spec format is too loose, every change will trip the check. Define a machine-readable interface declaration inside the spec file to make the detection deterministic.

All three are variations on one theme: the mechanics that make multi-agent proliferation tractable are isolation, coordination, and verification, and you can build them shelling out to whatever agent runtime you already use.

Resources

• Augment Code: Agentic software development at organizational scale
• LukeW Ideation + Design | Digital Product Strategy & Design