Running several coding agents in parallel on Windows, without WSL or tmux

Introduction

Parallel execution of LLM-driven coding agents is the primary bottleneck in modern autonomous development pipelines. Most tutorials default to WSL or terminal multiplexers like tmux to manage concurrent processes. That approach introduces unnecessary abstraction layers, skews performance metrics, and complicates debugging. We built a native Windows orchestrator that handles parallel agent execution using standard process isolation, deterministic scheduling, and bidirectional named pipes. No subsystems, no terminal multiplexers, just direct control over process trees, memory limits, and I/O routing.

Why This Matters

When you run five agents analyzing a codebase concurrently, you hit resource contention, file descriptor leaks, and context-switch overhead. WSL adds translation layers that distort latency measurements and break native Windows debugging workflows. tmux assumes a Unix terminal paradigm that doesn’t map cleanly to the Windows console subsystem or GUI-based IDE integrations. Native execution gives you direct control over process lifecycles, memory boundaries, and I/O scheduling. For engineering teams shipping Windows-first tooling or enterprise CI/CD pipelines, this is non-negotiable. You get predictable resource allocation, straightforward crash recovery, and zero cross-platform friction.

How It Works

The architecture relies on a central orchestrator process that spawns isolated worker processes. Each worker receives a dedicated workspace directory and connects to the orchestrator through a bidirectional Windows Named Pipe. A lightweight router distributes tasks based on agent capability tags and current load. A resource guardian monitors CPU and memory utilization, throttling new spawns when thresholds are breached. Results flow back through the same pipe channel, where the orchestrator aggregates outputs and triggers cleanup routines.

graph TD
    A[Orchestrator Process] --> B{Task Router}
    B -->|Assign Subtask| C[Agent Worker 1]
    B -->|Assign Subtask| D[Agent Worker 2]
    B -->|Assign Subtask| E[Agent Worker N]
    C <-->|Named Pipe IPC| F[Pipe Broker]
    D <-->|Named Pipe IPC| F
    E <-->|Named Pipe IPC| F
    F -->|Aggregate Results| A
    C -->|Read/Write| G[Isolated Workspace 1]
    D -->|Read/Write| H[Isolated Workspace 2]
    E -->|Read/Write| I[Isolated Workspace N]
    A -->|Monitor & Throttle| J[Resource Guardian]
    J -.->|CPU/Memory Limits| C
    J -.->|CPU/Memory Limits| D
    J -.->|CPU/Memory Limits| E

The workflow follows a deterministic cycle:

1. The orchestrator parses a high-level objective and splits it into idempotent subtasks.
2. The router pushes subtasks onto a priority queue, respecting agent capability tags and current queue depth.
3. Idle worker processes pull tasks through their assigned named pipes. Backpressure halts distribution when buffers fill.
4. Workers execute logic within isolated directories, writing artifacts with explicit file locks to prevent cross-agent corruption.
5. Completed results stream back through the pipe. The orchestrator validates checksums, merges outputs, and updates the execution graph.
6. The resource guardian continuously samples system metrics. If CPU usage exceeds 80% or memory crosses a defined ceiling, the router pauses new dispatches until headroom returns.

Core Concepts

Process Isolation Over Thread Sharing
Python’s GIL makes threading unsuitable for CPU-bound LLM inference or heavy static analysis. We use multiprocessing with the spawn start method, which is the default on Windows. Each agent runs in a separate memory space, eliminating shared-state race conditions and allowing independent crash recovery.

Named Pipes for Local IPC
Sockets introduce unnecessary network stack overhead for local communication. Windows Named Pipes operate at the kernel level, provide built-in authentication, and handle backpressure natively. They are faster