Building a Parallel Coding Agent Fleet with Git Worktrees and Autonomous Feedback Loops

Hook

What if your AI coding assistant could spawn copies of itself, each working on different issues simultaneously in isolated git branches, while automatically fixing their own CI failures and responding to code reviews—all without blocking each other?

Context

AI coding assistants have evolved from autocomplete suggestions to agents that can implement entire features. But they've hit a parallelism wall. Tools like Aider, GitHub Copilot, and Claude Code excel at sequential tasks—you give them an issue, they write code, you review it. If you want to tackle five issues simultaneously, you're stuck manually managing five terminal sessions, five branches, and five context windows. Worse, these agents operate in your working directory, creating a coordination nightmare if multiple agents try to modify the same codebase.

The root problem isn't the AI models—it's the infrastructure around them. Traditional git workflows assume a single developer working in a single directory. When you try to parallelize AI agents using conventional approaches, you either serialize them (defeating the purpose) or create a mess of conflicting file changes. ComposioHQ's Agent Orchestrator solves this by treating AI coding agents as a distributed workforce, using git worktrees to give each agent its own isolated filesystem space while maintaining a shared git history. It adds an orchestration layer that plans work, delegates to specialized agents, and—critically—handles the feedback loops that make agents autonomous: automatically routing CI failures and code review comments back to the agents that created them.

Technical Insight

The architectural breakthrough is combining git worktrees with a central orchestration agent and automatic reaction system. Git worktrees allow multiple working directories to share a single .git repository—each agent gets its own filesystem space and branch without the overhead of full repository clones. When the orchestrator spawns an agent for an issue, it creates a dedicated worktree, launches the agent runtime (tmux session, ConPTY process, or Docker container), and monitors progress through a skills-based abstraction layer.

Here's how you'd configure a multi-agent setup in the declarative YAML format:

agents:
  - id: frontend-specialist
    runtime: tmux
    tool: claude-code
    config:
      skills:
        - react-development
        - css-styling
      filters:
        labels: ["frontend", "ui"]
        exclude_labels: ["backend"]
  
  - id: backend-specialist
    runtime: docker
    tool: aider
    config:
      skills:
        - api-development
        - database-migrations
      filters:
        labels: ["backend", "api"]

orchestrator:
  max_parallel_agents: 5
  auto_assign: true
  reaction_handlers:
    ci_failure:
      max_retries: 3
      escalate_after: 2
    review_comments:
      auto_respond: true
      require_approval_after: 2

The orchestrator reads your issue tracker (GitHub Issues, Linear, Jira), generates a work plan, and spawns agents based on label matching and skill definitions. Each agent operates in isolation—the frontend specialist modifies React components in /worktrees/issue-123 while the backend specialist writes API endpoints in /worktrees/issue-124. No file conflicts, no coordination overhead.

The autonomous feedback loop is where this gets powerful. When a PR triggers CI failures, the orchestrator's reaction system automatically:

1. Detects the failure via webhook or polling
2. Routes the error logs to the originating agent's worktree
3. Resumes the agent's runtime session with context about what broke
4. Lets the agent investigate, fix, and push updates
5. Tracks retry attempts and escalates to human review after thresholds

The same pattern applies to code review comments. When a human reviewer requests changes, the orchestrator parses the comment, identifies the relevant agent, and injects the feedback into that agent's session. The agent reads the comment, makes adjustments, and responds—all without developer intervention unless the agent hits its retry limit.

The runtime abstraction layer deserves special attention. On Unix-like systems, the orchestrator uses tmux to create persistent, resumable sessions for each agent. This means you can detach from a session, let agents run in the background, and reattach later to observe progress. On Windows, it uses ConPTY (Console Pseudo Terminal) to achieve similar isolation without tmux dependencies. For maximum isolation or cloud deployments, the Docker runtime spawns each agent in a container with mounted worktrees.

Here's a simplified example of how the orchestrator spawns an agent programmatically:

import { Orchestrator, AgentRuntime } from '@composio/agent-orchestrator';

const orchestrator = new Orchestrator({
  tracker: { type: 'github', repo: 'myorg/myrepo' },
  maxParallelAgents: 3,
});

// Fetch open issues and create work plan
const workPlan = await orchestrator.plan();

// Spawn agents for each planned task
for (const task of workPlan.tasks) {
  const worktree = await orchestrator.createWorktree({
    issueId: task.issueId,
    baseBranch: 'main',
  });
  
  const agent = await orchestrator.spawnAgent({
    worktreePath: worktree.path,
    runtime: AgentRuntime.TMUX,
    tool: 'claude-code',
    context: task.description,
    onComplete: async (result) => {
      if (result.success) {
        await orchestrator.createPR({
          worktree,
          title: task.title,
          autoMerge: false, // Disabled by default
        });
      }
    },
  });
  
  // Register reaction handlers for this agent
  orchestrator.onCIFailure(agent.id, async (failure) => {
    await agent.resume({
      message: `CI failed: ${failure.logs}`,
      maxRetries: 3,
    });
  });
}

The system even handles infrastructure concerns that kill long-running agent sessions. On macOS, it uses caffeinate to prevent system sleep during agent execution. For remote access scenarios, you can configure tmux to persist across SSH disconnections, letting agents continue working even if your connection drops. The repository's documentation reveals they've dogfooded this extensively—61 merged PRs and 3,288 test cases were generated by agents orchestrating their own development, which is both impressive and slightly unsettling.

Gotcha

The setup friction is real. You need Node.js 20+, Git 2.25+ with worktree support, the GitHub CLI (gh) authenticated, and platform-specific dependencies like tmux on Unix or Windows Terminal with ConPTY support. If your team uses a mix of platforms, you'll need to document different installation paths. The Docker runtime option helps here, but adds container overhead.

Auto-merge is disabled by default for good reason—you need to explicitly trust that agents won't merge broken code. Even with CI gates, there's risk. The reaction system will retry failed CI up to your configured limit, but if an agent persistently creates subtle bugs that pass tests, you won't know until production. You'll want strong integration test coverage before relying on autonomous merges. The escalation thresholds help, but require tuning based on your agent reliability and risk tolerance. Hardware limitations also bite: macOS cannot prevent sleep when the lid closes, even with caffeinate, and Linux/Windows lack equivalent power management assertions. If you're running this on a laptop as the demo suggests, you need to disable automatic sleep manually or risk agents being suspended mid-task.

Verdict

Use if: You manage a high-volume repository where multiple issues can be tackled in parallel, your team is comfortable with AI agents making code changes with delayed human review, and you have the infrastructure budget to run multiple agent sessions concurrently. This shines for maintaining large open-source projects, handling routine bug fixes across microservices, or automating repetitive refactoring tasks. The autonomous CI fixing alone can save hours of developer time on flaky tests. Skip if: Your team is small and works sequentially, you require immediate human review of every line of code before it touches a branch, or your development environment is locked down with strict toolchain restrictions. The setup complexity and trust requirements make this overkill for simple projects. Also skip if you can't afford the LLM API costs—running five parallel Claude or GPT-4 sessions gets expensive fast.