UniverLab · open laboratoryEXP-001
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
curl -fsSL https://install.univerlab.org/canopy | sh
██████ ██████ ████████ ██████ ████████ █████ ████ ███░░███ ░░░░░███ ░░███░░███ ███░░███░░███░░███░░███ ░███ ░███ ░░░ ███████ ░███ ░███ ░███ ░███ ░███ ░███ ░███ ░███ ░███ ███ ███░░███ ░███ ░███ ░███ ░███ ░███ ░███ ░███ ░███ ░░██████ ░░████████ ████ █████░░██████ ░███████ ░░███████ ░░░░░░ ░░░░░░░░ ░░░░ ░░░░░ ░░░░░░ ░███░░░ ░░░░░███ ░███ ███ ░███ █████ ░░██████ ░░░░░ ░░░░░░
EXP-001 · active · · release v3.1.1 · 2 weeks ago · DOI 10.5281/zenodo.23607434 · roadmap: · · Built with Canopy · Repository set up with ghScaff · Demo recorded with DemoStage · Commits checked by GitKit
daemontuigraph enginemcp
- 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
- Muse Code
- opencode
- Qoder CLI
- Qwen Code
- UTIM
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.
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.
Your sessions and graphs from your phone #
Encrypted end to end
Sessions travel over WebRTC with end-to-end encryption: the relay only carries signalling, and your screen never passes through it.
Pairing in one command
Run the command below: it prints a one-time code with its link and a terminal QR code. Scan it and the browser becomes a revocable device of the host.
Live graphs, shared
Watch specs walk the graph in real time from your phone, and hand single-use invite codes to guests you trust.
canopy remote pair
Open remote →
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.
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 #
- 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.