Orchestrating Multiple AI Coding Agents Across Git Worktrees

The modern engineering landscape is defined by an accelerating shift toward autonomous coding assistants. Developers no longer write every line of syntax manually. Instead, they orchestrate specialized command-line interfaces that generate, refactor, and debug code across complex repositories. This transition has exposed a fundamental friction point in developer tooling. Early applications attempted to solve this problem by hardwiring a single artificial intelligence provider into their core architecture. That approach quickly proved unsustainable as teams standardized on different models for cost, compliance, and performance reasons.

I built Klaussy, a desktop app that runs AI coding-agent CLIs in parallel across git worktrees and pairs them with a GitHub PR review surface. The v0.3.0 release (out June 5) replaced its hard dependency on Claude Code with a provider registry, so it now drives Claude Code, OpenAI Codex, Google Gemini, or GitHub Copilot — your pick per task. This post covers how the registry works, the side-by-side terminal model, and where the deeper AI features are still uneven across agents. It's closed-source and in beta. Site: klaussy.com.

Why did early developer tools struggle with multi-agent workflows?

The initial release of Klaussy operated under a strict constraint. The application only functioned correctly when developers utilized Claude Code. Early documentation explicitly stated that users relying on alternative tools would find no utility within the interface. This limitation effectively excluded a substantial portion of the engineering community. Many professionals have already established daily workflows around OpenAI Codex, Google Gemini, or GitHub Copilot. These preferences usually stem from organizational procurement policies, data handling requirements, or established cost structures rather than technical superiority.

The core friction Klaussy addresses remains entirely independent of the underlying artificial intelligence model. Engineers routinely initiate secondary tasks while primary processes continue executing. They frequently navigate between terminal environments where agents operate and browser interfaces where pull request reviews occur. Triage operations often span GitHub notifications, terminal outputs, and local editor states. None of these operational demands depend on a specific vendor. Hardwiring a single agent into the foundational layer created an unnecessary boundary that limited adoption across diverse technical stacks.

The original architecture relied on a straightforward assumption. Developers would interact with exactly one command-line interface, so the application could call that tool directly. The system spawned the process, parsed its output stream, and wired session resumption into the terminal manager. Every artificial intelligence surface within the application, including the interactive terminal, pull request review actions, and continuous integration failure debugger, referenced Claude by name. This design functioned adequately until teams required secondary or tertiary agent instances.

Introducing a second agent immediately exposed architectural fragility. Each command-line interface differs in obvious package structures and subtle operational mechanics. Model selection flags vary across providers. Session resumption mechanisms operate differently. Output streams require distinct parsing logic. Authentication workflows introduce unique quirks. Attempting to manage these variations through scattered conditional branches creates maintenance debt. Adding a fifth agent later would require locating every hardcoded reference across numerous files. The application required a clean seam between agent selection and task execution.

How does the provider registry architecture function?

Traditional terminal multiplexers like tmux or zellij cannot resolve this specific complexity. These tools successfully manage multiple shells within a single window. They do not understand git worktrees, agent session states, or pull request review contexts. Klaussy ties each terminal directly to a specific agent instance, a target branch, and a designated worktree. The necessary abstraction required a centralized registry that declares package dependencies, launch commands, and model lists. This structure isolates agent-specific logic from the broader orchestration layer.

The provider registry module now owns all agent-specific operations. External components query the registry for the current agent rather than referencing vendor names directly. Each provider entry declares its npm package, launch command, available models, and output parsing rules. Adding a fifth agent requires updating a single configuration entry rather than modifying dozens of call sites. This architectural pattern mirrors broader industry efforts to separate core business logic from external dependencies, similar to approaches discussed when Modernizing Legacy Codebases With AI Assistance.

The user interface layer sits above the registry and manages agent selection. Engineers configure a global default agent that persists across application restarts. A per-action picker allows temporary overrides for individual tasks. Setting Google Gemini as the default ensures every agent action follows that configuration. Developers can switch to OpenAI Codex for a specific worktree without altering the global setting. The orchestration layer handling parallel worktrees, terminal allocation, and the review surface remains completely decoupled from the underlying model choice.

Model selection verification varies across the supported providers. Claude accepts model aliases for opus, sonnet, and haiku tiers. OpenAI Codex exposes gpt-5.5 and gpt-5.4-mini variants. Google Gemini offers 2.5 and 3 flash and pro tiers. GitHub Copilot remains default-model-only in the current release. The application picker deliberately avoids presenting unverified model slugs. This transparency prevents false expectations and aligns with engineering best practices for frontend business logic architecture, where components must accurately reflect available domain helpers and hooks.

What challenges emerge when orchestrating parallel coding sessions?

Each development task executes within its own git worktree. The application allocates a dedicated pseudo-terminal through node-pty and surfaces it in a unified window. Engineers can arrange these terminals in columns, grids, or single panes. This structure replaces the manual git worktree setup, tmux configuration, and GitHub command aliases that developers previously scripted. The agent assigned to each terminal derives directly from the registry. A column running Claude and a column running Gemini coexist without cross-contamination or state leakage.

The worktree actions dropdown enables sibling task execution on different agents. Engineers can assign identical code changes to two parallel agents for direct comparison. This capability proves valuable when evaluating which model handles specific refactoring or debugging tasks more effectively. The registry decouples agent selection from task definition, making this comparison seamless. Developers gain immediate visibility into how different architectures approach identical problems without switching contexts or reconfiguring environments.

Concurrent execution introduces specific operational constraints that require careful management. Running two OpenAI Codex sessions simultaneously can invalidate rotating OAuth tokens. The application warns engineers before initiating a second concurrent session rather than allowing silent failure. This limitation stems from Codex authentication mechanics rather than application design. The orchestration layer must understand these constraints precisely. The registry exists to centralize this knowledge and prevent downstream failures across parallel terminal instances.

How does the integrated review surface change code triage?

The integrated review surface renders GitHub pull requests without requiring a local checkout. Engineers access Files, Conversation, Checks, and AI Review tabs directly within the desktop interface. The inline review composer batches comments and submits them in a single network request. Per-finding state management tracks ignore, add to pull request, implement, investigate, and ask actions across sessions. One click materializes the pull request into a worktree and spawns a corresponding task when local inspection becomes necessary.

A built-in Monaco editor provides language server protocol diagnostics for direct diff editing. Engineers can modify files and commit changes without leaving the application. This feature significantly reduces context switching during code review cycles. The maturity gap across providers becomes most apparent here. Review actions, continuous integration debugging, implement workflows, and ask commands remain most battle-tested on Claude. Non-Claude output parsers for these headless surfaces are documented but still undergoing verification in the shipped code.

The interactive terminal, agent switching, session resumption, and side-by-side execution function reliably across all four supported agents today. The deeper artificial intelligence surfaces on OpenAI Codex, Google Gemini, and GitHub Copilot represent the path requiring the most caution. Engineers should recognize this distinction before deploying the tool in production review pipelines. Transparency regarding verification status allows teams to allocate resources appropriately and plan incremental adoption strategies.

What are the current limitations and future directions?

An optional on-device autocomplete feature runs entirely on local hardware through Ollama. The system utilizes qwen2.5-coder:1.5b at approximately one hundred milliseconds latency. No data leaves the laptop during keystroke processing. The feature requires an opt-in installation and consumes roughly two gigabytes of storage for the runtime and model weights. Without this component, users receive a standard word-based completer. This local inference path operates independently from the primary agent command-line interface.

Initial setup requires Node.js eighteen or higher and an authenticated GitHub command-line interface. Engineers must install at least one supported agent command-line interface and complete its authentication flow. The application detects missing components but cannot bootstrap external authentication systems. Once a worktree opens, agent selection and sibling task spawning occur through the worktree actions dropdown. The chosen agent becomes the global default and persists until manually changed. No configuration files or per-project setup steps remain necessary.

Multi-agent maturity remains uneven across the supported providers. Running, switching, resuming, and side-by-side execution function on all four agents. The deeper artificial intelligence surfaces, including pull request review, implement workflows, and continuous integration debugging, are most proven on Claude. The built-in flow prompts retain Claude-flavored syntax and require per-agent tuning. The application does not bundle agent access. Engineers utilize their existing accounts with supported providers. Klaussy operates strictly as a developer productivity layer.

The architecture contains no server infrastructure. Data flows directly from the local agent command-line interface to the provider, from the local GitHub client to the repository, and optionally to local Ollama instances. Pricing follows a one-time founder license model with tiered seat options for larger teams. This distribution method aligns with modern engineering preferences for transparent data handling and predictable cost structures. The application prioritizes local execution and explicit provider routing over centralized processing.

The evolution of developer tooling increasingly demands flexible orchestration layers. Hardwiring specific artificial intelligence providers into foundational architectures creates unnecessary friction as teams adopt diverse models for different workloads. Provider registries successfully decouple agent selection from task execution. This approach enables parallel worktree management, unified pull request review, and transparent verification status tracking. Engineering workflows will continue shifting toward universal interfaces that adapt to available models rather than forcing teams to conform to single-vendor ecosystems.