When building locally, speed and iteration cycles are critical—especially for agentic workflows. In this post, I’ll detail a hands-on setup for running agents in parallel, orchestrated with tmux and isolated Git worktrees. I’ll also share a unique twist: forking the “brain” of my agents using Claude Opus 4, generating multiple solutions for each task and then picking the best—an approach I found both effective and (admittedly) resource-intensive.

My Local Agentic Setup #

If you’re tinkering with local agentic automation, tmux and git worktree are your best friends:

• tmux lets you run, watch, and kill multiple independent shell sessions in a single terminal.
• git worktree spins up isolated versions of your repo (on any branch), perfect for feature isolation or bug triage.

But I wanted something more: for complex programming tasks, I’d use Claude Opus to generate not one, but three alternative implementations—each in its own workspace. Then I’d run them all, compare outputs, and select the best.

The Dual Agentic Approach #

Approach One: The Claude Opus “Ensemble” Method #

For each coding or automation task, use Claude Opus to generate three variant solutions.

• Pros: Higher chance of novel or robust approaches, easy A/B/C testing of unclear solutions.
• Cons: Expensive (Claude Opus isn’t cheap!), more manual curation.

Why do it? Sometimes, the best answer is only visible when you see a few wrong ones side-by-side.

Approach Two: Standard Agent Parallelism #

Assign different tasks to agents, each in its own tmux window, running concurrently on isolated git worktrees.

• Pros: Predictable, cost-effective, great for automation pipelines.
• Cons: Doesn’t self-optimize/learn as easily as the ensemble trick

Practical Example: API Health Monitoring Dashboard #

Let’s build something concrete: a monitoring system with three agents working in parallel to create an API health dashboard. This example demonstrates both approaches—you could use the ensemble method to generate three different monitoring strategies, or assign different agents to different components.

Architecture Overview #

Our system has three clear components:

• Agent 1: REST API health checker with retry logic and timeout handling
• Agent 2: GraphQL endpoint monitor with schema validation and query testing
• Agent 3: Web dashboard that aggregates and displays results from both monitors

Each agent works independently, communicates through shared JSON files, and can be developed in parallel by different Claude Code instances.

Setting Up the Parallel Workflow #

First, create the project structure and git worktrees:

# Initialize the main project
mkdir api-health-monitor && cd api-health-monitor
git init
git add . && git commit -m "Initial commit"

# Create branches and worktrees for each agent
git checkout -b agent-1-rest-checker
git checkout -b agent-2-graphql-monitor
git checkout -b agent-3-dashboard

# Set up isolated worktrees
git worktree add ../rest-checker agent-1-rest-checker
git worktree add ../graphql-monitor agent-2-graphql-monitor
git worktree add ../dashboard agent-3-dashboard

# Create shared directory for JSON data exchange
mkdir shared

Now launch a tmux session with dedicated windows:

# Start tmux session
tmux new-session -d -s api-monitor

# Create windows for each agent
tmux new-window -t api-monitor:1 -n "rest-checker"
tmux new-window -t api-monitor:2 -n "graphql-monitor"
tmux new-window -t api-monitor:3 -n "dashboard"

# Navigate each window to its worktree
tmux send-keys -t api-monitor:1 "cd ../rest-checker"
tmux send-keys -t api-monitor:2 "cd ../graphql-monitor"
tmux send-keys -t api-monitor:3 "cd ../dashboard"

# Launch Claude Code in each window
tmux send-keys -t api-monitor:1 "claude"
tmux send-keys -t api-monitor:2 "claude"
tmux send-keys -t api-monitor:3 "claude"

# Attach to view all windows
tmux attach-session -t api-monitor

Agent 1: REST API Health Checker #

In the first tmux window, give Claude Code this prompt:

Prompt for Claude Code:

Create a Node.js REST API health checker with the following requirements:

1. Core Features:

   • Support multiple endpoints with configurable retry logic (default 3 attempts)
   • Timeout handling (default 5 seconds)
   • Response time measurement
   • Expected status code validation
   • Exponential backoff between retry attempts (1s, 2s, 3s)

2. Input Configuration:

   • Array of endpoints with URL, expected status code, and optional headers
   • Configurable output path for JSON results
   • Timeout and retry count settings

3. Output Format:

   • Write results to ../shared/rest-results.json
   • Each result should include: url, status (healthy/unhealthy), statusCode, responseTime, timestamp, attempts
   • Wrap all results in an object with timestamp, type: ‘rest-api-health’, and results array

4. Error Handling:

   • Graceful handling of network timeouts, connection errors, and invalid responses
   • Log meaningful error messages while maintaining JSON structure

5. Test Endpoints:

   • GitHub API status, httpstat.us/200, JSONPlaceholder
   • Should work with both HTTP and HTTPS endpoints

Please create a complete solution with proper class structure, async/await patterns, and a configuration example.

Agent 2: GraphQL Monitor #

In the second window, give Claude Code this prompt:

Prompt for Claude Code:

Build a comprehensive GraphQL endpoint monitoring system with these specifications:

1. Core Monitoring Features:

   • Schema introspection to validate GraphQL endpoint health
   • Support for custom test queries to verify functionality
   • Response time tracking for both introspection and test queries
   • Configurable timeout handling (default 10 seconds)

2. Schema Validation:

   • Execute introspection query to fetch schema metadata
   • Count total schema types and validate schema structure
   • Detect GraphQL errors vs HTTP errors
   • Report schema availability and complexity metrics

3. Test Query Execution:

   • Run optional array of test queries for each endpoint
   • Track individual query performance and success rates
   • Handle authentication headers for protected endpoints
   • Capture and report GraphQL-specific errors

4. Output Requirements:

   • Save results to ../shared/graphql-results.json
   • Status classification: healthy (no errors), degraded (schema issues), unhealthy (connection failed)
   • Include introspection metadata, test query results, and timing data
   • Wrap in object with timestamp, type: ‘graphql-health’, and results array

5. Configuration Support:

   • Multiple endpoints with custom headers (for auth)
   • Configurable test queries per endpoint
   • Automatic monitoring intervals (every 30 seconds)

Create a complete Node.js solution with proper error handling, async patterns, and example configuration for GitHub’s GraphQL API.

Agent 3: Web Dashboard #

In the third window, Claude Code builds a real-time dashboard:

Prompt for Claude Code:

Create a real-time web dashboard for API health monitoring with these requirements:

1. Dashboard Structure:

   • Modern, responsive HTML layout with three main sections:
     • REST API Status panel
     • GraphQL Status panel
     • Overall Health Summary with aggregate metrics
   • Clean header with title and last-updated timestamp

2. Data Integration:

   • Fetch JSON data from ../shared/rest-results.json and ../shared/graphql-results.json
   • Auto-refresh every 5 seconds using fetch API
   • Graceful handling when data files are missing or malformed
   • Parse and display results from both monitoring agents

3. Visual Design:

   • Use modern CSS with clean typography (system fonts)
   • Card-based layout with subtle shadows and proper spacing
   • Color-coded status indicators:
     • Green for healthy services
     • Orange for degraded services
     • Red for unhealthy/failed services
   • Responsive grid that adapts to different screen sizes

4. Status Display:

   • Show hostname, response time, and status badge for each service
   • For GraphQL: also display schema type count
   • Health summary with counters for healthy/degraded/failed services
   • Real-time timestamp updates

5. Technical Requirements:

   • Pure vanilla JavaScript (no frameworks)
   • CSS Grid and Flexbox for layout
   • Class-based architecture for the dashboard logic
   • Error handling for network requests and JSON parsing

Create three files: index.html, style.css, and dashboard.js with a complete working solution that can be served with python -m http.server.

Running the Complete System #

Now you have three agents working in parallel:

1. Switch between tmux windows with Ctrl-b 1, Ctrl-b 2, Ctrl-b 3
2. Monitor all agents simultaneously by splitting panes: Ctrl-b % and Ctrl-b "
3. View the dashboard by serving the HTML file: python -m http.server 8000 in the dashboard directory

Committing and Merging Agent Work #

Once each agent has completed their implementation, you need to commit their work before merging:

Step 1: Commit work in each worktree #

# Commit the REST API checker
cd ../rest-checker
git add .
git commit -m "Add REST API health monitoring with retry logic and timeout handling"

# Commit the GraphQL monitor
cd ../graphql-monitor
git add .
git commit -m "Add GraphQL endpoint monitoring with schema introspection"

# Commit the web dashboard
cd ../dashboard
git add .
git commit -m "Add real-time web dashboard for API health visualization"

Step 2: Return to main and merge branches #

# Return to the main project directory
cd ../api-health-monitor

# Verify you're on the main branch
git branch

# Merge each agent's work
git merge agent-1-rest-checker
git merge agent-2-graphql-monitor
git merge agent-3-dashboard

Handling Merge Conflicts #

When merging parallel development work, conflicts are common—especially in shared files like package.json, configuration files, or README updates. If you encounter merge conflicts:

# If merge fails with conflicts
git status  # Shows conflicted files

# Let Claude Code resolve the conflicts
claude-code

Then prompt Claude Code:

I have merge conflicts in the following files: [list files from git status]. Please resolve these conflicts by:

1. Examining both versions of the conflicted code
2. Combining the changes intelligently (keeping both features when possible)
3. Ensuring the merged result maintains functionality from both branches
4. Removing conflict markers and finalizing the merge

After resolving, stage the files and complete the merge commit.

Troubleshooting “Already up to date” #

If git merge says “Already up to date”, it means no commits exist on the branch you’re trying to merge. This happens when:

• Code was created but never committed in the worktrees
• You’re in the wrong directory (check with pwd and git branch)

Debug with:

# Check if branches have diverged from main
git log --oneline main..agent-1-rest-checker
git log --oneline main..agent-2-graphql-monitor
git log --oneline main..agent-3-dashboard

# List all worktrees and their status
git worktree list

If the logs are empty, return to each worktree, verify the files exist, and commit them as shown in Step 1.

This setup demonstrates the power of parallel development: while one agent builds REST monitoring logic, another tackles GraphQL complexities, and the third focuses on presentation. Each can iterate independently, test different approaches, and contribute to a cohesive final product.

The shared JSON files act as a simple contract between agents—a pattern that scales to more complex microservice architectures and distributed development workflows.