Constructdocs
repo
orchestration layer·Apache 2.0

One AI interface.
A team behind it.

Construct sits on top of Claude Code, OpenCode, Codex, Cursor, and Copilot. You talk to one persona called construct. Behind it is a team of specialists shaped by your org profile. Hard gates. Runs locally — or deployed for teams.

5-minute quickstart See the architecture Repo
Specialists28
SurfacesClaude · Codex · OpenCode · Cursor · Copilot
SurfacesOpenCode first · MCP · ACP
Modessolo · team · enterprise
Storagefile · sql · vector
Heads up — from the maker
“I'm not a developer. Construct is a side project I'm vibe-coding to learn in public. There will be bugs, rough edges, and things that change without warning. The code is open source, the issues queue is real, and contributions are welcome. If you need production-grade tooling today, this isn't it yet.”
TL;DROne agent on the surface; an orchestration system underneath. You ask for an outcome — Construct routes specialists, keeps state aligned, and runs verification until something verifies or a real blocker surfaces.

From the user side, Construct feels like one agent you can talk to. Under the hood, it's an orchestration system that routes work across 28 specialist roles shaped by your active org profile— software R&D by default, with curated profiles for operations, creative, and research orgs, plus a schema-validated escape hatch for custom profiles.

Sessions survive boundary changes via durable state in .cx/, Beads, and a local vector index. Solo by default. Can deploy centrally for teams that want shared memory, telemetry, queues, and policy.

Request, in flight

Use it inside your editor

@construct
@construct read the README and summarize what this project is
@construct review the auth flow in src/auth/ and flag risks
@construct fix the login redirect bug
@construct ship the customer portal when it's verified
TL;DRMost days you check status, sync after registry changes, review the inbox, and run doctor when something feels off.
bash
construct status          # confirm services and editor adapters are healthy
construct sync            # refresh host adapters after registry or config changes
construct intake list     # review new signals, if your project uses the inbox
construct doctor          # diagnose install, service, MCP, and adapter drift
construct oracle status   # fleet health verdict and pending queue

In your editor, start with @construct. Ask for the outcome, not the specialist. Construct routes to the right chain, keeps durable state in .cx/and Beads, and blocks risky mutations until the configured gates pass.

TL;DROutcome-driven routing · 28 specialists that argue with each other · durable state · hybrid retrieval · hard gates · explicit deployment modes.
01
One persona, many specialists
You address @construct. It dispatches to 28 specialists (architect, engineer, reviewer, QA, security, designer, …) under typed contracts.
02
Specialists that argue
Reviewer, security, devil’s advocate, and QA are peers — not rubber stamps. Agreement at every step is treated as a smell.
03
Durable project state
Beads for work items, .cx/ for context + handoffs, git for code, Postgres + pgvector for embeddings. Nothing important lives in only one place.
04
Health you can see
A canonical construct status and construct doctor — runtime, providers, telemetry, storage modes, adapter drift.
05
Hybrid retrieval
File-state, SQL-ready records, and semantic search over a shared corpus. Falls back to a local JSON vector index when Postgres isn’t available.
06
Hard gates, not vibes
Three layers — write-time hooks, commit/push gates, CI safety-net. Quality gates fire unconditionally; notice-only signals auto-suppress in CI and non-TTY contexts. If a gate fires wrong, repair the policy — do not bypass it.
07
Owned-loop chat + Oracle
Terminal and browser chat run Construct's own loop with full transparency. Oracle reviews fleet health and queues consequential fixes — construct oracle status.
TL;DRsolo (default) runs everything locally. team promotes the queue and memory to shared Postgres with brokered MCP. enterprise adds tenant isolation, RBAC/ABAC, signed allowlists, mandatory audit.

solo runs everything locally — filesystem queue, local repo state, optional Postgres via Docker, local JSONL traces. If every cloud service goes down, you still work from plan.md, .cx/context.md, beads, git, and the local vector index.

team promotes the intake queue to Postgres with row-locked worker claims. Shared memory, Docker worker pool, centralized telemetry, MCP through a broker.

enterprise adds tenant isolation, RBAC/ABAC scaffolding, isolated worker containers, signed MCP allowlists, and mandatory audit.

bash
construct config mode [solo|team|enterprise]
Same loop, different topology
The agent loop (persona, specialists, contracts, gates) is identical across all three modes. Only the backend topology changes — read deployment model for the trade-offs.
TL;DRInstall + first task → editor wiring → concepts and recipes. Reference is for when you know what you're looking up.
  • Get started — install, init, first task. ~5 minutes if Docker is running.
  • Architecture — diagrams, the request lifecycle, where things live.
  • Deployment model — pick solo, team, or enterprise.
  • Intake and triage — how signals become triaged R&D work.
  • Connect your editor — OpenCode first, with MCP-backed support for the other public hosts.
  • Cookbook — task-oriented recipes (custom agents, providers, retrieval backend, your own LLM).
  • Reference — every CLI command, hook, MCP tool, config option.