Run a swarm of AI coding agents on one codebase. Without merge chaos.
Agent Workspace Fabric is the control plane that lets your team run 10, 50, 500 AI coding agents on the same codebase, in parallel, with the operational discipline of a high-performing engineering team. Isolated workspaces, deterministic locks, a governed merge queue. main stays green.
Apache 2.0 · Source on GitHub
Runs Claude Code, Codex, Cursor, Gemini, Grok, and any Ollama model inside isolated workspaces. Drive it from any MCP client (Claude Code, Codex) or the REST/CLI (OpenClaw, Hermes).
Not projections — counters from the Postgres control plane of the AWF instance that develops AWF. Claude Code, Codex, OpenCode, and Gemini agents working the same repo, main kept green.
You shipped AI agents. Now your senior engineers are babysitting Git.
You’re paying for Claude Code, Devin, Codex. Your team generates code faster than ever. But the infrastructure underneath was never built for parallelism at this scale.
The problem isn’t the agents. It’s that there’s no control plane underneath them.
AWF isn’t another agent. It’s the fabric your agents run on.
Open, agent-agnostic infrastructure that orchestrates whichever agents you already use. The MVP delivers parallel execution today; the full lock matrix and governed merge queue land in v0.2.
Every agent gets its own world
A workspace is more than a checkout — it’s a Docker Compose project. Fresh Git worktree, scoped agent container, persistent service sidecars (Postgres, Redis, app-under-test, Playwright) sized to your repo profile. No shared mutable state. When the task is done, the workspace is destroyed.
# workspace.yamlworkspace:git: worktree (isolated branch)runtime: agent containerdatabase: persistent postgres sidecarlifecycle: ephemeral
Coordination before the conflict exists
Workspaces declare the paths they own. Overlaps surface instantly as coordination and stale-detection signals — before compute is wasted on a doomed change. Truly serialized resources (schema migrations, generated artifacts) take exclusive locks and queue through the merge pipeline one at a time.
OWNED: src/cart/** → ws-042OVERLAP: src/cart/** → ws-044 flaggedEXCLUSIVE: migrations/** → serialized
No more “it worked on my branch”
When the target branch moves, AWF detects drift instantly. Stale workspaces are flagged, rebased deterministically, and required to pass fresh validation before they enter the merge queue. No task is mergeable against an outdated base.
STALE: ws-043 base behind main by 3 commitsACTION: auto-rebase triggeredNEXT: tier 2 re-validation required
A merge queue that knows about agents
Three validation tiers gate the merge: tier 1 (lint, types, fast tests), tier 2 (full suite against current main), tier 3 (cross-workspace integration). Only tier-2-fresh results enter the queue. Migration tasks serialize automatically.
MERGE CANDIDATE: ws-042 ✓ tier 1 lint + types · 12s ✓ tier 2 tests vs main@a1b2c3d · 4m22s ✓ tier 3 integration with ws-038 · 2m11s STATUS: ready · queue 2/7
One install command to a fleet of agents shipping PRs.
Same architecture from your laptop to a multi-node fleet. Drive AWF from any MCP client, the REST API, or the typed CLI.
Set up Agent Workspace Fabric (AWF) on this machine and onboard my repo.
1. Clone https://github.com/dimileeh/agent-workspace-fabric and READ
skills/awf-scheduler/SKILL.md and docs/QUICKSTART.md before doing anything.
2. Check prerequisites (Docker running, uv, git). For PR automation, configure only<PATH> with your project’s path.Install AWF
Clone the repo and install the CLI as an isolated tool via uv. The Quickstart in the repo docs walks every lane — source checkout, existing virtualenv, or Docker Compose. PyPI package and one-line installer ship with the first tagged release.
$ git clone https://github.com/dimileeh/agent-workspace-fabric$ cd agent-workspace-fabric && uv tool install .Start the local control plane
awf start brings up the REST API, worker, Postgres state store, and the operator console at http://127.0.0.1:3000. Headless flag for CI.
$ awf setup && awf startOnboard a repo
awf init writes a .awf/workspace.yml profile for your project. Owned paths, validation phases, runtime, services, secrets, coverage targets — all declared once, replayed forever.
$ awf init ~/code/your-repoSpawn workspaces from anywhere
Use the typed CLI, the REST API (OpenClaw, Hermes, your own scripts), or the MCP toolset from Claude Code, Codex, or any MCP client. Each task gets a fresh worktree, a scoped agent container, persistent service sidecars.
$ awf workspace create --repo git@github.com:acme/shop.git --title "Payment flow" --prompt "Implement the Stripe checkout flow from issue #142: payment intent endpoint, webhook handler, and tests" --agent claude_codeAWF ships the PR for you
Agents run in parallel. AWF detects stale bases, rebases deterministically, runs validation, opens the PR, monitors review comments, addresses them by re-running the agent, waits out the review grace window, then auto-merges when every gate is clean.
✓ ws-042 merged → main@e7f8g9h · ✓ main is green · 0 conflicts
“I was building Aira with a fleet of coding agents working in parallel — and watched them fight each other. Worktrees weren’t enough: agents drifted from stale bases, trampled shared modules, and one bad migration would invalidate a night’s work.
I open-sourced my first attempt, clawdbot, before realizing the real answer was Docker-isolated workspaces with a control plane that owns merge safety the way a great integration engineer would.
That’s AWF. It now builds itself — every number on this page comes from its own merge queue. And it’s yours, Apache 2.0.”
Worktrees are the easy part.
Every AI IDE shipped worktree isolation in early 2026. None of them shipped the substrate above it: validation provenance, owned-path locks, stale detection, PR monitor with review grace, post-merge reconciliation, cross-vendor merge queue. AWF is that substrate. Open source. Apache 2.0.
isolation only
(locks · queue · monitor)
cross-vendor
single vendor
| Capability | AWF | IDE worktree features | Per-session orchestrators | PR-stage merge queues |
|---|---|---|---|---|
| Isolated ephemeral workspaces | yes | yes | yes | — |
| Cross-vendor (Claude + Codex + Gemini + Grok + Cursor + Ollama in one queue) | yes | single vendor | partial | N/A |
| Owned-path lock semantics | yes | — | — | — |
| Real-time stale detection + auto-rebase | yes | — | partial | partial |
| Validation provenance + durable reason codes | yes | — | — | — |
| PR monitor with review-grace + auto-merge | yes | — | — | merge only |
| Profile-driven project config (.awf/workspace.yml) | yes | — | shallow | — |
| MCP toolset + REST + typed CLI | yes | — | varies | — |
| Open source | Apache 2.0 | closed | mixed | mostly closed |
Want the receipts? Every capability above maps to code you can read — the source is open →
Open source for your laptop. Cloud for your team.
The core is Apache 2.0 today. Run it on your laptop, on a dev box, on your own servers. When the hosted cloud lands, it’s the same architecture managed for you. Cloud tiers are launching in waves — get in early.
Free
Solo founders shipping like a team of ten. Engineering teams piloting multi-agent workflows.
- Isolated workspaces with Docker sidecars
- Owned-path locks + stale detection
- PR monitor · auto-merge · validation provenance
- CLI · REST API · MCP toolset
- Runs Claude Code, Codex, Cursor, Gemini, Grok, Ollama agents
Waitlist
Teams with existing LLM contracts who want a managed control plane and observability.
- Hosted control plane
- Admin console + dashboards
- Bring your own LLM keys
- Concurrent-workspace billing — no per-seat
- Email + Slack support
Talk to us
Engineering orgs running 50+ concurrent workspaces with compliance requirements.
- Everything in BYOK Cloud
- Single-tenant deployment (VPC)
- SSO/SAML · RBAC · audit logs
- Dedicated onboarding + SLA
- Optional Full-Stack LLM allowance
When the hosted cloud lands, beta cohort teams get a 30-day guarantee: if a single unhandled merge conflict gets through that’s caused by AWF’s orchestration layer — not bad code from an agent — we refund the first month and personally help you migrate wherever you need to go.
Open source is shipping today. Hosted cloud tiers are launching in waves through 2026.
Limited to 30 teams.
We’re onboarding one team at a time. The open-source core is available today; the managed cloud tier is by invitation.
We review every application personally. Expect a reply within 48 hours.
Questions, answered straight.
No. AWF is the deterministic substrate that wraps whichever coding agent you already use. AWF does not generate code. It gives each task an isolated workspace, runs the agent inside, enforces owned-path locks, validates the result, opens the PR, monitors review comments, addresses them, and auto-merges when every gate is clean.
An orchestrator. AWF exposes a typed CLI, a REST API, and an MCP server with a full workspace-lifecycle toolset. Anything that can call those interfaces can drive AWF: Claude Code or Codex via MCP, OpenClaw or Hermes via the REST API and CLI, or your own scripts. The orchestrator decides what to build; AWF decides where and how to build it safely.
AWF ships adapters for Claude Code, OpenAI Codex, Cursor, Gemini, Grok, and OpenCode (which lets you run any local model via Ollama — GLM, Kimi, Gemma, Deepseek, Minimax, and others). Source of truth: src/awf/adapters/registry.py on the development branch.
Fastest: paste the install prompt from the How-it-works section into Claude Code, Codex, or any agent with shell access — it clones the repo, installs AWF, brings up the local control plane, and onboards your project, ending with a green smoke test. Prefer manual? git clone github.com/dimileeh/agent-workspace-fabric, then uv tool install . from the checkout, then awf setup && awf start to bring up the control plane and operator console at http://127.0.0.1:3000. The full Quickstart in the repo docs covers every lane, including Docker Compose. A PyPI package (uv tool install agent-workspace-fabric) and a one-line curl installer ship with the first tagged release.
A workspace is a per-task Docker Compose project. It includes a fresh Git worktree on an isolated branch, the agent runtime container, and any persistent sidecars the repo profile declares (Postgres for migration-capable repos, optionally Redis, app-under-test, Playwright). The Postgres sidecar lives for the full workspace lifecycle so Alembic migrations execute against a database the workspace owns.
Migration tasks claim owned paths on the migration surface and serialize through the merge queue. Each workspace applies its own migrations to its own Postgres sidecar. After one migration merges, AWF performs post-merge target-branch reconciliation (including multi-head repair for Python/Alembic repos) so dependent workspaces can rebase, re-validate, and rejoin the queue.
Every validation run AWF performs against a workspace is recorded with a durable reason code, the exact target-branch commit it ran against, the phase that produced it, and the artifacts it generated. When the PR monitor decides whether to merge, it consults that provenance — not just "tests passed sometime." If the target moved, the workspace is marked stale, rebased, and re-validated. No PR merges with stale provenance.
No. AWF complements it. AWF handles pre-merge orchestration — workspace lifecycle, locks, stale detection, validation, PR creation, comment handling, and auto-merge gating. Your CI/CD pipeline still owns post-merge deployment, release management, and production monitoring. AWF can invoke CI-like validation commands but is not a CI replacement.
Different shape. Per-session orchestrators (Conductor, Vibe Kanban, Claude Squad, Pane, Crystal, Superset, Emdash) optimize for a human reviewing each PR. AWF optimizes for autonomous overnight runs with merge safety: validation provenance, owned-path semantics, stale detection, a PR monitor with review-grace windows, and post-merge reconciliation. Composio AO is the closest neighbour by feature set — it is milestone-gated with CI auto-retry, while AWF treats merge safety and provenance as first-class concerns. The comparison table above maps each capability to the tier it belongs to.
In waves through 2026. The open-source core is shipping today (Apache 2.0, run it on your laptop or your own servers). BYOK Cloud, Full-Stack Cloud, and Enterprise (VPC / SSO / RBAC / SLA) are launching in waves — join the beta to get an invitation when your tier opens.
Apache 2.0. Use it commercially, fork it, embed it in proprietary products. No ELv2 trap, no source-available carve-outs, no rug-pull. The hosted cloud tier will add managed infrastructure, an admin console, observability dashboards, SSO/SAML, RBAC, and an SLA — features organizations need, not feature-gates on individuals.