Research•23 min read

The Forge Whitepaper: Multi-AI Orchestration for Software Development

February 9, 2026 by Asif Waliuddin

ForgeAI OrchestrationMCPMulti-Agent SystemsDeveloper ToolsOpen SourceRust

Executive Summary

The age of the single AI coding assistant is over. In 2025, engineering teams discovered that Claude, GPT, and Gemini are each capable of writing, testing, and refactoring production code. The bottleneck shifted overnight — from can an AI write code to can multiple AIs work on the same codebase without destroying each other's work.

The answer, for most teams, is no. Concurrent AI agents produce merge conflicts, lose each other's learnings, and silently drift from the intended architecture. These are not edge cases. They are the default experience for any team running more than one AI agent against the same repository.

Forge is an open-source orchestration layer — a 3 MB Rust binary — that solves this problem. It coordinates Claude Code, Codex CLI, and Gemini CLI through the Model Context Protocol (MCP), providing file-level locking, a persistent knowledge flywheel, LLM-powered drift detection, and five-dimension governance health checks. The entire system ships as a single compiled binary with zero runtime dependencies.

This white paper describes the problem in detail, presents the Forge architecture, explains the six key innovations that distinguish it from existing tools, and makes the case for multi-AI orchestration as open infrastructure.

Section 1: The Multi-AI Coordination Problem

1.1 The Post-Copilot Landscape

Between 2023 and 2025, AI coding assistants evolved from autocomplete engines into autonomous agents. Claude Code can read an entire repository, reason about architectural constraints, and implement multi-file features. Codex CLI can execute shell commands, run tests, and iterate on failures. Gemini CLI can analyze large codebases and generate comprehensive refactoring plans.

Each tool, operating alone, is genuinely useful. The problem begins when two or more operate concurrently — a scenario that is increasingly common as engineering teams attempt to parallelize AI-assisted development across feature branches, test suites, and infrastructure layers.

1.2 Three Systemic Failures

Teams running concurrent AI agents encounter three categories of failure that no individual tool is designed to prevent:

Merge Conflicts at Scale. Two agents editing the same file simultaneously produce irreconcilable diffs. Git can detect the conflict after the fact, but it cannot arbitrate intent. The developer is left manually resolving changes that neither agent understands in the context of the other's work. In practice, this means one agent's work is often discarded entirely — negating the productivity gain that motivated parallel execution.

Knowledge Evaporation. Agent A discovers that a particular database migration must be run before the API server starts. Agent B, running in a separate context window with no awareness of Agent A's discovery, deploys the API server without the migration and spends twenty minutes debugging the resulting failure. The lesson learned in one agent's context never reaches another. In human teams, this is solved by communication — standup meetings, Slack channels, shared documentation. AI agents have no equivalent mechanism. Each operates in an isolated context, and when that context is destroyed at the end of a session, the knowledge goes with it.

Architectural Drift. Without a shared plan, each agent optimizes locally. Agent A refactors the authentication module to use a new pattern. Agent B, unaware of this refactoring, implements a new feature using the old pattern. Agent C introduces a third pattern it learned from its training data. The codebase drifts from its intended architecture, accumulating invisible technical debt that compounds with every concurrent session.

These three failures — conflict, evaporation, and drift — are not bugs in any individual AI tool. They are emergent properties of running multiple autonomous agents against a shared resource (the codebase) without a coordination layer. Forge is that coordination layer.

1.3 Why Existing Solutions Fall Short

The open-source community has produced several tools to manage concurrent AI agents: Claude Squad for session management, Claude-Flow for task routing, CCManager for process coordination. Each addresses a piece of the problem, but none provides the complete set of capabilities required for production multi-agent workflows.

Session managers can start and stop agents but cannot prevent them from editing the same file. Task routers can assign work but cannot capture the knowledge generated during execution. Process coordinators can manage lifecycles but cannot detect when an agent's output contradicts the intended architecture.

The gap is not in any single capability but in the integration of capabilities. Multi-AI coordination requires a unified system that manages the plan, the tasks, the file locks, the knowledge store, and the governance checks — simultaneously and atomically.

Section 2: The Forge Trio Architecture

Forge is not a single tool. It is three components — the orchestrator, the interface, and the plugin — that together form a complete orchestration layer for multi-AI development.

2.1 forge-orchestrator: The Brain

The orchestrator is a compiled Rust binary (~3 MB, including TLS) that owns the state of the entire development workflow. It maintains:

• The Plan: A hierarchical decomposition of the project's goals into tasks, subtasks, and dependencies.
• The Task Graph: A directed acyclic graph of work items with status tracking, ownership, and blocking relationships.
• The File Lock Table: An active_locks registry in state.json that prevents concurrent write access to the same file.
• The Knowledge Store: A structured corpus of decisions, patterns, mistakes, and learnings in .forge/knowledge/.
• The Governance State: Five-dimension health scores across test coverage, security, documentation, architecture alignment, and git hygiene.

The orchestrator exposes these capabilities through two interfaces: a CLI (for human operators) and an MCP server (for AI tools).

2.2 forge-ui: The Interface

The interface is a React/Next.js application that provides:

• Infinity Terminal: A PTY bridge with WebSocket transport that maintains shell sessions across browser closes, network disconnects, and multi-device access. Sessions are identified by ID and support auto-reconnect — the "infinity" in the name.
• Real-Time Dashboard: Task board, progress tracking, and agent activity visualization.
• Governance HUD: A heads-up display showing the five-dimension health score, active file locks, and knowledge capture activity.

The interface is optional. The orchestrator operates entirely through the CLI and MCP server. The UI adds visibility and control for human operators who want to monitor multi-agent workflows in real time.

2.3 forge-plugin: The Distribution

The plugin packages Forge for distribution as a Claude Code extension:

• .claude/commands/ — Slash commands for common orchestration operations
• .claude/agents/ — Specialized agent definitions (planner, builder, security reviewer, compliance auditor, tester, guardian)
• CLAUDE.md — Project knowledge base automatically loaded by all agents

Users install by cloning the repository. There is no npm dependency, no build step, no package manager configuration. The plugin architecture ensures that all agents share the same project context through CLAUDE.md, eliminating the knowledge silo problem at the distribution level.

2.4 How the Components Interact

The typical workflow proceeds as follows:

1. A human operator runs forge init in their project directory. The orchestrator discovers the project context (language, framework, existing tools, git state) and scaffolds the .forge/ directory.

2. The operator creates a plan using forge plan --generate, which sends the project context to the configured brain (either the heuristic RuleBasedBrain or the LLM-powered OpenAIBrain) for task decomposition.

3. AI tools connect via MCP. When Claude Code, Codex CLI, or Gemini CLI is configured with Forge as an MCP server, they gain access to nine tools for task management, knowledge capture, and governance.

4. Agents claim tasks. An agent calls forge_claim_task, which checks dependency constraints, acquires file locks for the task's target files, and returns the task payload. If another agent holds a conflicting lock, the claim is rejected — preventing merge conflicts before they occur.

5. Agents complete tasks. When an agent calls forge_complete_task, the orchestrator releases file locks, marks the task as done, checks for newly unblocked downstream tasks, and returns the list of available work.

6. Knowledge accumulates. Throughout the workflow, agents call forge_capture_knowledge to store decisions, patterns, and learnings. Other agents call forge_get_knowledge to query the corpus before making decisions — turning organizational learning into a compounding advantage.

7. Governance monitors continuously. The forge_get_health tool returns a five-dimension governance score at any point. The forge_check_drift tool sends the current plan and codebase context to the configured brain for alignment scoring, catching silent architectural drift before it compounds.

Section 3: Key Innovations

Six architectural decisions distinguish Forge from existing multi-agent tools. Each addresses a specific failure mode observed in production multi-AI workflows.

3.1 File-Level Locking

The most common failure in concurrent AI development is two agents editing the same file. Git detects this after the fact as a merge conflict, but by then both agents have invested significant compute in divergent changes. One agent's work must be discarded.

Forge prevents this at the source. The orchestrator maintains an active_locks table in state.json. When an agent claims a task, the orchestrator locks all files in the task's scope. If another agent attempts to claim a task that would require access to a locked file, the claim is rejected with a clear explanation of which agent holds the lock and what task it is working on.

The locking is cooperative, not mandatory — agents that bypass the MCP interface can still edit files directly. But for any agent operating through the standard MCP tools, file conflicts are structurally impossible.

{
  "active_locks": {
    "src/auth/login.ts": {
      "agent": "claude-code-1",
      "task_id": "task-003",
      "acquired_at": "2026-02-08T14:30:00Z"
    },
    "src/auth/register.ts": {
      "agent": "claude-code-1",
      "task_id": "task-003",
      "acquired_at": "2026-02-08T14:30:00Z"
    }
  }
}

3.2 Knowledge Flywheel

In human teams, knowledge transfers through conversation, documentation, and institutional memory. AI agents have none of these channels. Each operates in an isolated context window, and when that window closes, everything learned during the session — constraints discovered, patterns identified, mistakes made — is lost.

Forge's knowledge flywheel addresses this by providing a persistent, queryable knowledge store at .forge/knowledge/. The forge_capture_knowledge tool accepts a knowledge entry with free-form content and automatically classifies it into one of several categories: decision, pattern, constraint, mistake, or learning.

The forge_get_knowledge tool allows any agent to search the corpus by category, keyword, or semantic similarity. Before making a significant decision, an agent can query the knowledge store to check whether a similar decision has been made before and what the outcome was.

Over time, the knowledge store becomes a compounding advantage. Early sessions populate it with project-specific constraints and patterns. Later sessions benefit from this accumulated context, making fewer mistakes and producing more architecturally consistent output. The flywheel effect — where each session makes subsequent sessions more effective — is the core value proposition.

3.3 LLM Drift Detection

Architectural drift is the most insidious failure in multi-agent development because it is invisible at the task level. Each agent's output may be locally correct — passing tests, following conventions, implementing the requested feature — while the aggregate effect is a codebase that no longer matches the intended architecture.

Forge's forge_check_drift tool addresses this by sending the current plan and a summary of recent changes to the configured brain (typically gpt-4.1) for alignment scoring. The brain evaluates whether the codebase is converging toward or diverging from the plan's stated goals, architectural constraints, and design patterns.

The output is a structured alignment report with a numeric score and specific observations about where drift has occurred. This allows human operators to catch drift early — before it compounds into a refactoring project.

3.4 Dual Engine Design

The orchestrator's decision-making is abstracted behind the ForgeBrain trait, which supports two implementations:

• RuleBasedBrain: A heuristic engine that uses pattern matching and predefined rules for task decomposition, dependency resolution, and governance scoring. It is deterministic, fast, and free — requiring no API calls or network access. This engine is ideal for teams that want orchestration without LLM costs.

• OpenAIBrain: A full LLM-powered engine (gpt-4.1 by default) that provides nuanced planning, natural language task decomposition, and sophisticated drift detection. It requires an API key and incurs per-call costs, but produces significantly higher quality plans for complex projects.

Users switch between engines with a single CLI command: forge config set brain.provider rule-based or forge config set brain.provider openai. The rest of the system is unaffected — all MCP tools, file locking, knowledge capture, and governance checks work identically regardless of which brain is active.

This dual-engine design means Forge can be adopted incrementally. Teams can start with the free heuristic brain and upgrade to the LLM brain only when the project's complexity justifies the cost.

3.5 Nine MCP Tools

Forge exposes its capabilities through the Model Context Protocol — JSON-RPC 2.0 over stdio. Any AI tool that speaks MCP can interact with Forge without custom integration, wrapper libraries, or vendor-specific SDKs.

The nine tools form a complete orchestration surface:

The protocol choice is deliberate. MCP is the emerging standard for AI tool integration — Claude Code, Codex CLI, and Gemini CLI all support or are converging toward MCP. By building on this standard, Forge avoids the trap of creating yet another proprietary integration format that each tool must separately support.

3.6 Five-Dimension Governance

Production codebases require more than functional correctness. They need adequate test coverage, security hygiene, documentation, architectural consistency, and disciplined git practices. Forge's governance engine evaluates all five dimensions and produces a single composite health score.

The forge_get_health MCP tool returns both the composite score and per-dimension breakdowns, allowing agents and human operators to identify which dimension is dragging the overall score down. Teams can configure threshold alerts — for example, blocking task completion if the security score drops below 70.

Section 4: How It Works — End-to-End Flow

To make the architecture concrete, consider a realistic scenario: a three-person engineering team using Claude Code, Codex CLI, and Gemini CLI to implement a new user authentication system.

Step 1: Initialization

The lead engineer runs forge init in the project directory. The orchestrator discovers that the project is a TypeScript/Next.js application with Vitest for testing, identifies existing authentication stubs, and scaffolds the .forge/ directory with the initial state.

Step 2: Plan Generation

The engineer runs forge plan --generate with the goal "Implement JWT-based authentication with login, registration, password reset, and role-based access control." The OpenAIBrain decomposes this into twelve tasks with dependency relationships:

Task 1: Define User model and database schema
Task 2: Implement password hashing utility (blocked by: 1)
Task 3: Create JWT token service (blocked by: 1)
Task 4: Build registration endpoint (blocked by: 1, 2)
Task 5: Build login endpoint (blocked by: 2, 3)
Task 6: Build password reset flow (blocked by: 2, 3)
Task 7: Implement role-based middleware (blocked by: 3)
Task 8: Write unit tests for auth utilities (blocked by: 2, 3)
Task 9: Write integration tests for endpoints (blocked by: 4, 5, 6)
Task 10: Add API documentation (blocked by: 4, 5, 6, 7)
Task 11: Security review (blocked by: 4, 5, 6, 7)
Task 12: Final integration test (blocked by: 8, 9, 10, 11)

Step 3: Concurrent Execution

Three AI agents connect via MCP. Claude Code claims Task 1 (User model), receiving locks on src/models/user.ts and prisma/schema.prisma. Simultaneously, Gemini CLI reads the plan via forge_get_plan to understand the overall architecture.

When Claude Code completes Task 1, it calls forge_complete_task. The orchestrator releases the file locks and reports that Tasks 2, 3, and 4 are now unblocked. Codex CLI claims Task 2 (password hashing), Claude Code claims Task 3 (JWT service), and Gemini CLI claims Task 4 (registration endpoint) — all executing concurrently without file conflicts because each task targets different files.

Step 4: Knowledge Capture

During Task 5 (login endpoint), Claude Code discovers that the JWT library requires a specific key format. It calls forge_capture_knowledge with this constraint. When Codex CLI later works on Task 6 (password reset), it calls forge_get_knowledge and finds the JWT key format constraint — avoiding a twenty-minute debugging detour.

Step 5: Drift Check

After Tasks 4, 5, and 6 are complete, the lead engineer runs forge_check_drift. The OpenAIBrain analyzes the three endpoint implementations and flags that Task 6 (password reset) uses a different error handling pattern than Tasks 4 and 5. The drift report includes the specific files and line ranges, allowing the engineer to request a targeted refactoring before the pattern inconsistency spreads.

Step 6: Governance Gate

Before marking the feature complete, the engineer checks forge_get_health. The governance engine reports: test coverage 92%, security score 85%, documentation 60%, architecture 88%, git hygiene 95%. The low documentation score triggers a review — Task 10 (API documentation) was completed but missed the password reset endpoint. The engineer assigns a follow-up task.

Section 5: Competitive Landscape

Several tools have emerged to manage concurrent AI coding agents. The following comparison evaluates them across the seven capabilities that matter for production multi-agent workflows.

5.1 Comparison Matrix

5.2 Analysis

Claude Squad is a Go-based session manager that excels at starting, stopping, and multiplexing AI agent sessions. It provides a terminal UI for monitoring multiple concurrent agents. However, it has no mechanism for preventing file conflicts, capturing knowledge, or detecting drift. It solves the "how do I run multiple agents" problem but not the "how do I prevent them from interfering with each other" problem.

Claude-Flow is a TypeScript orchestration framework with task routing and basic coordination capabilities. It includes a partial MCP implementation and rudimentary file conflict detection. However, it lacks a persistent knowledge store, drift detection, and governance checks. Its TypeScript implementation also means it competes for Node.js resources with AI tools that run their own Node.js processes.

Codex CLI is OpenAI's command-line interface for the Codex model. It is a powerful single-agent tool but provides no multi-agent capabilities — no task coordination, no file locking, no knowledge sharing, and no MCP server.

CCManager is a process manager for Claude Code instances that provides basic session lifecycle management and partial multi-agent support. It does not include file locking, knowledge capture, drift detection, governance, or MCP integration.

The distinguishing factor is scope. Existing tools solve one piece of the puzzle — typically session management or basic task routing. Forge addresses the full lifecycle: plan decomposition, task assignment, file locking, knowledge capture, drift detection, and governance health checks. It is the difference between a tool and an operating system for multi-AI development.

Section 6: Technical Profile

6.1 Language and Compilation

Forge is written in Rust 2024 edition and compiles to a single statically-linked binary. The release binary is approximately 3 MB including TLS support (via rustls). There are no runtime dependencies — no JVM, no Node.js, no Python interpreter, no shared libraries to version-match.

This matters because the orchestrator runs alongside AI agents that consume significant memory and CPU. An orchestrator written in Python or TypeScript would compete for the same resources. A 3 MB Rust binary with sub-millisecond startup and negligible steady-state memory usage is effectively invisible to the rest of the system.

6.2 Codebase Metrics

6.3 The Adapter Architecture

The ToolAdapter trait abstracts the differences between AI coding tools:

pub trait ToolAdapter {
    fn name(&self) -> &str;
    fn invoke(&self, task: &Task, context: &ProjectContext) -> Result<String>;
    fn is_available(&self) -> bool;
}

Each adapter (ClaudeAdapter, CodexAdapter, GeminiAdapter) translates Forge commands into the tool's native invocation format. Adding support for a new AI tool means implementing this single trait — typically under 100 lines of code.

The adapter architecture ensures that Forge is not coupled to any specific AI vendor. As new tools emerge (and existing tools evolve), new adapters can be added without modifying the orchestrator's core logic.

6.4 The Brain Architecture

The ForgeBrain trait defines how the orchestrator makes planning and evaluation decisions:

pub trait ForgeBrain {
    fn decompose(&self, goal: &str, context: &ProjectContext) -> Result<Plan>;
    fn evaluate_drift(&self, plan: &Plan, changes: &[Change]) -> Result<DriftReport>;
    fn score_health(&self, project: &ProjectContext) -> Result<HealthScore>;
}

Two implementations exist:

• RuleBasedBrain: Pattern matching against a library of heuristic rules. Deterministic, zero-cost, works offline.
• OpenAIBrain: Sends structured prompts to the configured LLM (gpt-4.1 by default) via the OpenAI-compatible API. Configurable with forge config set brain.model <model-id>.

The trait boundary means new brain implementations can be added — a local LLM brain, a Claude brain, a Gemini brain — without touching the rest of the system.

6.5 State Management

All orchestration state is stored in .forge/state.json — a single JSON file that is human-readable, git-trackable, and trivially debuggable. The state includes:

• Task list with status, ownership, and dependency graph
• Active file locks with agent identity and timestamps
• Brain configuration (provider, model, API endpoint)
• Session history and activity log

The decision to use a flat JSON file (rather than SQLite, a key-value store, or an in-memory database) is deliberate. The orchestrator's state is small (typically under 100 KB even for large projects), changes infrequently (task state transitions, not per-keystroke updates), and must be inspectable by humans debugging orchestration issues. A JSON file meets all three requirements with zero operational overhead.

Section 7: The Open Source Vision

7.1 Why MIT

Forge is released under the MIT license — the most permissive widely-used open source license. The entire orchestration layer — Rust binary, MCP server, knowledge flywheel, governance engine, all adapters — is open infrastructure. No premium tiers, no telemetry, no usage-gated features, no contributor license agreement that reserves special rights for the maintainers.

The reasoning is both philosophical and practical.

Philosophically: AI orchestration is infrastructure. Like compilers, version control systems, and container runtimes before it, the coordination layer between AI tools and codebases should be a commons — not a vendor moat. The history of developer tools is clear: the tools that become infrastructure are the tools that are open. GCC, Git, Docker, and Kubernetes did not win because they were proprietary. They won because they were open, and openness attracted the contributors and adopters that made them the standard.

Practically: Open source is the only distribution model that works for a tool that sits between AI agents and a developer's codebase. The orchestrator has read and write access to the entire project. It manages file locks, stores knowledge, and evaluates architectural drift. Engineers will not — and should not — route their code through a black box. Trust requires transparency. Transparency requires source access.

7.2 Contribution Model

The project accepts contributions across all three components. Several contribution types are especially welcome:

• Adapter implementations for new AI tools. Each adapter is a self-contained module with a clear trait contract and three existing reference implementations (Claude, Codex, Gemini).
• Brain implementations for new LLM providers. The ForgeBrain trait is simple and well-documented.
• Governance rules for specific technology stacks or compliance frameworks. The governance engine is designed to be extended with domain-specific health checks.
• Knowledge classifiers that improve the auto-classification accuracy of the knowledge flywheel.

7.3 The Ecosystem Thesis

The long-term vision is an ecosystem of interoperable components built on the Forge orchestration layer. The MCP server provides the standard interface. The trait system (ToolAdapter, ForgeBrain) provides the extension points. The MIT license provides the legal foundation.

In this model, Forge does not need to be the best at everything. It needs to be good enough at orchestration that the community builds specialized adapters, brains, governance rules, and knowledge classifiers on top of it. The value accrues to the ecosystem, not to a single vendor.

This is the same model that made Linux, Kubernetes, and the Language Server Protocol successful. A small, well-designed core with clear extension points attracts a community of contributors who collectively build something no single organization could.

Conclusion

The multi-AI coordination problem is not a theoretical concern. It is the primary obstacle preventing engineering teams from realizing the productivity gains promised by AI coding assistants. Running multiple agents concurrently — the obvious way to parallelize AI-assisted development — produces merge conflicts, loses knowledge, and causes architectural drift. These failures are structural, not incidental. They will not be solved by making individual AI tools smarter.

Forge addresses the problem at the right level of abstraction: a lightweight orchestration layer that sits between AI tools and the codebase, providing the coordination primitives that concurrent agents require. File locking prevents conflicts. The knowledge flywheel prevents knowledge loss. Drift detection prevents architectural divergence. Governance health checks prevent quality degradation.

The system is small (3 MB), fast (Rust, zero runtime deps), and open (MIT license). It speaks the emerging standard protocol (MCP) and supports the major AI coding tools (Claude Code, Codex CLI, Gemini CLI) through a clean adapter architecture. It can be adopted incrementally — starting with the free heuristic brain and upgrading to LLM-powered planning when complexity justifies the cost.

Multi-AI orchestration is infrastructure. Forge is the open-source implementation of that infrastructure. The code is available, the protocol is standard, and the license is permissive. The rest is up to the community.

Forge is developed by NXTG.AI and released under the MIT license. The orchestrator source code, MCP server specification, and adapter implementations are available on GitHub at github.com/nxtg-ai/forge-orchestrator.