Imagine a team of AI agents, not just writing code, but architecting, researching, and reviewing the entire lifecycle of a software project. This is the vision behind OpenPlan, a sophisticated multi-agent framework designed to bring structure and scalability to AI-driven software engineering. By analyzing its core architecture, we can see a blueprint for the future of automated development.

At its heart, OpenPlan tackles the chaos of multi-agent collaboration with a clear, enforceable structure. It’s built on a foundation of Git, using its core features not just for version control, but as a fundamental part of the runtime infrastructure.

Core Principle: Dual-Repository Isolation

The most striking feature of OpenPlan is its strict separation of concerns, enforced by a dual-repository model:

• Documentation Repository: This is the single source of truth (SSOT) for the project’s design. It contains the “why” and the “what”—high-level architecture, engineering decisions (ADRs), and guiding principles. It is a pure design space, intentionally isolated from the noise of implementation details.
• Code Repository: This holds the current state of the implementation, the “how.” It’s where the code lives, but it also includes a special openspec/ directory that contains specifications derived from the documentation repo.

This separation ensures that the design remains the unchallenged authority. Agents working on the implementation are guided by the spec, which is in turn governed by the design docs.

The Unidirectional Flow of Authority

To enforce this, OpenPlan uses a three-layer model where authority flows in only one direction:

Documentation Layer → Specification Layer (openspec/) → Code Layer

An agent writing code can reference the specification, and the specification can reference the design documents. However, the reverse is forbidden. This prevents “implementation drift,” where the code slowly diverges from the original plan. The design is the constitution, the specification is the law, and the code is the execution.

Git as a Runtime Infrastructure

OpenPlan’s most ingenious move is using Git as a core component of its operational infrastructure.

One key example is Agent Isolation. When a new task is dispatched to an agent, OpenPlan doesn’t just give it a directory. It creates a completely separate, isolated environment using git worktree. It then uses git sparse-checkout to ensure the agent can only see the specific files relevant to its task.

For example, a coding agent might only have access to src/, tests/, and the relevant openspec/ files. It is physically incapable of seeing other parts of the codebase, eliminating any chance of it acting on outdated or irrelevant information. This is physical isolation, not just a guideline, enforced at the file system level.

Conclusion

OpenPlan presents a compelling architectural pattern for managing the complexity of multi-agent software development. By enforcing a strict separation of concerns, a clear flow of authority, and leveraging Git as a robust runtime for agent isolation, it creates a system that is transparent, auditable, and scalable. It’s a glimpse into a future where AI teams don’t just write code—they build projects with discipline and architectural integrity.