--- title: "Multi-agent graph engine for AI coding agents — Canopy" source: "https://univerlab.org/canopy/" --- [UniverLab · open laboratory](/)EXP-001 # Canopy In a forest, the canopy is where the crowns touch — separate trees, one living layer. A Rust daemon and terminal UI with a **graph engine** at its core. Work enters as a spec and walks a graph you design: **agent** nodes on any harness, **check** nodes that run your real commands, **ensembles** that fan out to several models and keep a quorum, **routers** that pick the branch, and a **resilience** node that turns a quota death into a scheduled wake-up. Underneath: memory, scheduling and sync for every agent. AI agents → a graph engine above every harness → specs carried all the way to a commit ✕ quota Gated implementchecks run your real commands — red routes the work back, never to you [Star on GitHub ↗](https://github.com/UniverLab/harness-canopy)[Documentation →](/canopy/docs/) Install `curl -fsSL https://install.univerlab.org/canopy | sh`⧉✓ ![](/bench/machines/canopy-night-450.webp) EXP-001 · active · Sol 79 (2026-03-20) · [release v3.1.1 · 2 days ago](https://github.com/UniverLab/harness-canopy/releases/tag/v3.1.1) · [DOI 10.5281/zenodo.23607434](https://doi.org/10.5281/zenodo.23607434) · roadmap: · · Built with [Canopy](/canopy/) · Repository set up with [ghScaff](/ghscaff/) · Demo recorded with [DemoStage](/demostage/) · Commits checked by [GitKit](/gitkit/) Latest release: v3.1.1 (2026-10-24) daemontuigraph enginemcp Supported platforms * Antigravity CLI * BLACKBOX AI CLI * Claude Code * Cline CLI * CodeBuddy Code * Codex CLI * Command Code * Continue CLI * Copilot CLI * Cursor CLI * Devin CLI * Freebuff * Gemini CLI * Kilo Code CLI * Kiro CLI * MiMo Code CLI * Vibe * opencode * Qoder CLI * Qwen Code * UTIM Genesis · 2026 · Sol 79 (2026-03-20) ## The one that started it all. It started as a folder of **skills** for work. Then I noticed what nobody was talking about: agent harnesses shipped a **headless** mode, just sitting there unused. I wired cron jobs to fire tasks through it — too much for a skill, and the models of the day choked on the instructions. So it became an **MCP**: _task-trigger_. It worked, but it ran blind in the background; only the agent ever saw what happened. Not enough. I killed it and built a **TUI** — then scheduling, memory, sync, identities, and a new name. **Canopy**. By then the twist was complete: Canopy was building Canopy, and everything else in this lab. Fig. 1Canopy — recorded with DemoStage The graph engine ### Graphs, not prompts Agent, check, gate and router nodes wired with pass, fail and always edges. A spec walks the graph from entry to commit; routing keys on real exit codes and verdicts, not on what a model claims. ### Ensembles across harnesses Fan one step out to several models — parallel with a quorum, cascade to the next on failure, or round-robin across a crew — each member on whatever harness and model you pick. ### Failure is a route Red gates send the work back with the output attached. A resilience node reads quota errors and schedules the graph to wake at the exact reset. Only a real verdict ever reaches you. Autonomous graphPattern: Ensemble · quorum + Gated implement 0 times it stopped ## It failed. It didn’t stop. 1. 01 ### One spec, three drafts Work enters as a spec — role, what, how. It fans out to three models on three harnesses, and a quorum keeps the consensus. 2. 02 ### Implement from the consensus An implementer node picks up the agreed plan on your harness and starts writing. 3. 03 ### It failed: cargo test, 2 red The check node runs your real commands. Red routes the token straight back to the implementer — it never comes to you. 4. 04 ### Green — and a second opinion The retry passes the gates. A different harness reviews the diff against the spec before anything moves. 5. 05 ### Committed. Pushed. Again. The branch is pushed and the run is remembered — the next spec is already walking the same graph. Every node runs on the harness you pick, and the loop you just watched is the real engine doing its real job. The runtime underneath ### Memory that persists Every run writes facts, patterns and decisions to a project-scoped knowledge graph. The next session — on any harness — reads them instead of rediscovering the codebase. ### Queues and scheduling Specs live in ordered queues a graph works through in the background; graphs and agents also fire on cron schedules or file-change triggers, and hooks chain one graph into the next. ### Multi-agent sync Agents declare their mission, report status and message each other, so several sessions can share one workspace without stepping on each other. Cite ## How to cite Martinez Bolivar, J., & Solorzano, L. (2026). canopy (harness-canopy) (Version v3.1.1) \[Computer software\]. Zenodo. https://doi.org/10.5281/zenodo.23607434 @software{canopy, author = {Martinez Bolivar, Jheison and Solorzano, Lina}, title = {canopy (harness-canopy)}, year = {2026}, version = {v3.1.1}, publisher = {Zenodo}, doi = {10.5281/zenodo.23607434}, url = {https://doi.org/10.5281/zenodo.23607434} } ⧉✓ FAQ ## FAQ What does Canopy actually do? Canopy runs AI coding work as graphs. A spec enters, agent nodes do the work on the harnesses you choose — Claude, Codex, Gemini, OpenCode or any terminal agent — check nodes run your real tests, ensembles get several models to agree, and failures route back automatically until the spec is committed. One daemon, all your agents, all your free tiers. How do I share work between Claude and Codex? Canopy gives each agent a shared knowledge graph and sync protocol. When Claude finishes a task, the facts and patterns it discovered are available to Codex in the next session. No manual context copying. Can I run AI agents on a schedule? Yes. Canopy fires agents on cron schedules or file-change triggers via a background daemon. Set the schedule once; the daemon watches the workspace and runs tasks automatically. How is Canopy different from just using Claude Code or Codex directly? Those are individual harnesses. Canopy is the layer that connects them — shared memory, background scheduling, and multi-agent coordination. You keep your agents; Canopy adds the infrastructure. Field notes