AI Development Orchestration
Multi-agent isn't the problem. Multi-tool is.
Inside a single environment like Claude Code, agents coordinate fine. They share orchestration and context. The trouble starts when you run multiple AI tools on the same repo. Claude Code for refactors. Codex CLI for tests. Gemini CLI for research. Each tool operating with its own memory, its own assumptions, and no shared state.
I ran Claude Code and Codex CLI on the same codebase. Claude refactored src/auth/middleware.ts. Codex updated error handling in the same file. Neither tool knew the other existed. Silent data loss.
There is no shared task board between tools, no file locking, no knowledge transfer between sessions across tools. The result: conflicts, amnesia, and you as the human message bus between your own tools. NXTG-Forge solves this with a Rust binary, MCP protocol, and a shared .forge/ state directory.
File Locking at the Rust Level
File locking exists because I've watched teams lose days to conflicting edits. Same problem, different substrate.
When one tool starts editing a file, Forge acquires an exclusive lock. Other tools queue until the lock is released. This runs in the 4MB Rust binary at the core of Forge. 292 tests cover concurrent access, timeout behavior, and deadlock prevention. Not a suggestion. An enforcement mechanism.
Shared State Through MCP Protocol
The gap between AI tools isn't capability. It's awareness. Each tool is individually capable. None of them know about each other.
Forge exposes 10 MCP tools that any connected AI tool can access. Task status, file locks, knowledge entries, and governance state are all available through standard MCP calls. Claude Code communicates via MCP stdio. Codex CLI and Gemini CLI use filesystem conventions. All three read from and write to the same .forge/ directory. Each tool reads its native config format. No wrappers. No Forge-specific configuration language.
Knowledge That Compounds Across Tools
Decisions made during a Claude Code session get captured in .forge/knowledge/. When Codex CLI starts a session the next day, those decisions are available. The knowledge flywheel works across tools, not just within a single tool's session history.
The knowledge flywheel exists because I've watched decisions evaporate between sprints. After a week of use, the context follows you across tools. New sessions start with knowledge instead of from scratch.
Task Board With Dependency Awareness
Instead of manually coordinating which tool does what, Forge maintains a task board with dependency graphs. Tools check which tasks are available, claim work, and report progress. The orchestrator tracks dependencies and prevents tools from starting blocked tasks.
Drift Detection
You wrote a spec. A tool started working. Is it still following the spec? Forge compares in-progress work against the original plan and flags divergence before it becomes expensive to fix. Drift detection exists because I've watched scope creep go unnoticed until the budget review.
Architecture
The Rust orchestrator binary (4MB, zero runtime dependencies) is the coordination core. Policy is enforced here. Nowhere else. The plugin and UI are adapter surfaces that present this coordination state through different interfaces. Communication uses the .forge/ filesystem and MCP stdio. State is files. Files are portable. Files are inspectable. No daemon. No database.