UniverLab · laboratorio abiertoEXP-001
Canopy
En un bosque, el dosel es donde las copas se tocan — árboles separados, una sola capa viva.
Un daemon en Rust y una interfaz de terminal con un motor de grafos en el centro. El trabajo entra como spec y recorre un grafo que tú diseñas: nodos de agente en cualquier harness, nodos de chequeo que corren tus comandos reales, ensembles que reparten un paso entre varios modelos y exigen quórum, routers que eligen la rama, y un nodo de resiliencia que convierte una cuota agotada en un despertar programado. Por debajo: memoria, scheduling y sync para todos tus agentes.
agentes de IA → un motor de grafos sobre cada harness → specs llevados hasta el commit
curl -fsSL https://install.univerlab.org/canopy | sh
EXP-001 · activo · · versión v3.1.1 · hace 2 días · DOI 10.5281/zenodo.23607434 · roadmap: · · Construido con Canopy · Repositorio configurado con ghScaff · Demo grabada con DemoStage · Commits revisados por 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
- opencode
- Qoder CLI
- Qwen Code
- UTIM
El que empezó todo.
Empezó como una carpeta de skills para el trabajo. Entonces noté lo que nadie mencionaba: los harness de agentes traían un modo headless, ahí, sin que nadie lo usara. Conecté tareas con cron para dispararlas por ese modo — demasiado para un skill, y los modelos de entonces se atragantaban con las instrucciones. Así que se volvió un MCP: task-trigger. Funcionaba, pero corría a ciegas en segundo plano; solo el agente veía lo que pasaba. No bastaba. Lo maté y construí una TUI — luego scheduling, memoria, sync, identidades, y un nombre nuevo. Canopy. Para entonces el giro estaba completo: Canopy construía a Canopy, y a todo lo demás en este laboratorio.
Grafos, no prompts
Nodos de agente, chequeo, gate y router unidos por aristas de pass, fail y always. Un spec recorre el grafo de la entrada al commit; el enrutamiento depende de códigos de salida y veredictos reales, no de lo que un modelo dice haber hecho.
Ensembles entre harness
Reparte un paso entre varios modelos — en paralelo con quórum, en cascada al siguiente si falla, o en round-robin por un equipo — cada miembro en el harness y modelo que elijas.
El fallo es una ruta
Un gate en rojo devuelve el trabajo con la salida adjunta. Un nodo de resiliencia lee los errores de cuota y programa el grafo para despertar justo al reinicio. Solo un veredicto real llega a ti.
0 veces que se detuvo
Falló. No se detuvo.
- 01
Un spec, tres borradores
El trabajo entra como spec — rol, qué, cómo. Se reparte entre tres modelos en tres harnesses y un quorum se queda con el consenso.
- 02
Implementar desde el consenso
Un nodo implementador toma el plan acordado en tu harness y empieza a escribir.
- 03
Falló: cargo test, 2 rojos
El nodo de chequeo corre tus comandos reales. El rojo devuelve el token directo al implementador — nunca llega a ti.
- 04
Verde — y una segunda opinión
El reintento pasa las puertas. Un harness distinto revisa el diff contra el spec antes de que algo avance.
- 05
Commiteado. Pusheado. Otra vez.
La rama se pushea y la corrida queda en memoria — el próximo spec ya está recorriendo el mismo grafo.
Cada nodo corre en el harness que elijas, y el loop que acabas de ver es el motor real haciendo su trabajo real.
Memoria que persiste
Cada ejecución escribe hechos, patrones y decisiones en un grafo de conocimiento por proyecto. La siguiente sesión — en cualquier harness — los lee en vez de redescubrir el código.
Colas y scheduling
Los specs viven en colas ordenadas que un grafo recorre en segundo plano; grafos y agentes también se disparan por cron o por cambios de archivo, y los hooks encadenan un grafo con el siguiente.
Sincronización multiagente
Los agentes declaran su misión, reportan su estado y se mandan mensajes, para que varias sesiones compartan un espacio de trabajo sin pisarse.
Cómo citar
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}
}Preguntas frecuentes
- ¿Qué hace Canopy exactamente?
- Canopy corre el trabajo de programación con IA como grafos. Entra un spec, los nodos de agente hacen el trabajo en los harness que elijas — Claude, Codex, Gemini, OpenCode o cualquier agente de terminal —, los nodos de chequeo corren tus tests reales, los ensembles ponen de acuerdo a varios modelos, y los fallos vuelven solos hasta que el spec queda commiteado. Un daemon, todos tus agentes, todos tus free tiers.
- ¿Cómo comparto trabajo entre Claude y Codex?
- Canopy le da a cada agente un grafo de conocimiento compartido y un protocolo de sincronización. Cuando Claude termina una tarea, los hechos y patrones que descubrió están disponibles para Codex en la siguiente sesión. Sin copia manual de contexto.
- ¿Puedo ejecutar agentes de IA en un horario?
- Sí. Canopy dispara agentes por cron o por eventos de cambio de archivo a través de un daemon en segundo plano. Configuras el horario una vez; el daemon vigila el workspace y ejecuta tareas automáticamente.
- ¿En qué se diferencia Canopy de usar Claude Code o Codex directamente?
- Esos son harnesses individuales. Canopy es la capa que los conecta — memoria compartida, programación en segundo plano y coordinación multi-agente. Tú conservas tus agentes; Canopy añade la infraestructura.