por qué construí un canvas para sacar de mi cabeza a mi flota de agentes

publicado por primera vez el 10 apr 2026. reescrito el 28 jul 2026 después de entender qué había construido realmente. La antigua entrada de Canvas Agents ahora también vive aquí porque ambos proyectos surgieron de la misma idea.

---

la razón más sencilla por la que construí termcanvas es que necesitaba mantener mi mente en orden.

ya estaba usando zed y mirando aplicaciones como conductor. eran útiles, pero el centro de esas herramientas era el código. mis agentes ya no hacían solo código. tenía terminales abiertos para investigación, contenido, música, comandos largos, logs y varios proyectos a la vez.

podía iniciar todo ese trabajo. no podía sostener su forma en la cabeza.

las herramientas disponibles seguían pidiéndome que adaptara el trabajo a su interfaz. yo quería lo contrario: terminales normales que pudieran contener lo que estuviera haciendo, organizados de una manera que mi mente pudiera entender.

así que hice el mío.

esto empezó antes de termcanvas

el 2 de abril publiqué un pequeño proyecto llamado Canvas Agents. colocaba agentes de imagen y vídeo directamente sobre un canvas infinito. estaba probando una interacción sencilla: el agente debía trabajar junto al artefacto, no vivir dentro de un cuadro de chat en otro lugar.

Canvas Agents y termcanvas eran aplicaciones distintas. una trabajaba con imágenes y vídeo; la otra empezó con terminales de shell reales. pero nacían de la misma frustración. no quería que el agente estuviera escondido detrás de una conversación mientras el trabajo real vivía en otro sitio.

la aplicación Canvas Agents ya está cerrada. la idea sobrevivió.

cuando pasé de generar medios a una flota creciente de agentes de programación y de propósito general, el documento se convirtió en el terminal. ese fue el comienzo de termcanvas.

por qué un canvas

las pestañas están bien hasta que tengo tantas que sus etiquetas dejan de significar algo. una lista me dice qué existe, pero no cómo está estructurado el trabajo. un tablero kanban me dice dónde está una tarea, pero el terminal que la ejecuta sigue en otro sitio.

la palabra canvas viene de la interacción que intentaba construir. la versión pública que hoy pido a la gente que use es más contenida que aquella primera imagen. muestra un terminal enfocado cada vez. la barra izquierda mantiene un árbol de creación en vivo, y el encabezado mantiene un resumen de la flota del canvas actual.

por jerarquía no quiero decir que un comandante permanente controle a todos los demás agentes. termcanvas probó ese modelo y después lo eliminó. el runtime actual permite que un agente cree un hijo, se conecte con un par o delegue trabajo directamente.

el árbol responde a la parte que realmente necesito tener en pantalla: ¿quién creó a quién? ¿qué agentes pertenecen a esta rama del trabajo? el encabezado responde a otra pregunta: cuál es el estado actual de los agentes gestionados en este canvas, incluyendo working, idle, done, stale, failed y waiting. agentmux también puede mantener enlaces entre pares en el runtime para que los agentes se dirijan unos a otros. v0.3.10 no dibuja esos enlaces como líneas en la interfaz.

sigo pensando espacialmente sobre el trabajo. por eso conservé el nombre. pero no quiero fingir que la versión pública me da una vista mágica de todos los terminales a la vez. me da un terminal para dirigir y una barra lateral que evita que la rama desaparezca de mi cabeza.

la primera versión eran solo terminales reales

los primeros commits de termcanvas también llegaron el 2 de abril. el 7 de abril la aplicación recibió su nombre. tres días después publiqué la entrada original del blog:

If you're going to steer a fleet of agents, you need a cockpit. I built TermCanvas: terminals on an infinite canvas, each agent in its own node, connected as a graph. It's the tool I write this chronicle from.

ese era todo el post.

la aplicación era real, pero mi explicación iba por delante de la implementación. era sobre todo un tablero visual de terminales. podía crear terminales, arrastrarlos, ampliar el canvas y vincular un workspace a cada canvas. se sentía mejor que las pestañas, así que seguí usándola.

la primera decisión técnica todavía define la aplicación: cada nodo es un terminal interactivo real.

termcanvas usa electron para la carcasa de escritorio, xterm.js para renderizar el terminal y node-pty para el proceso de shell. el renderer nunca es dueño del shell. los procesos de terminal y el acceso al sistema de archivos permanecen en el proceso principal de electron, detrás de un puente ipc estrecho.

esto importa porque no quería un panel falso de agentes que resumiera un trabajo que ocurría en otro lugar. quería hacer clic en un nodo y estar dentro de la sesión real.

hacer que los terminales sobrevivan al canvas

el siguiente problema era la continuidad.

si cerrar la aplicación mataba todos los terminales, termcanvas sería una forma más bonita de perder el trabajo. puse tmux debajo de las sesiones de terminal para que la aplicación pudiera separarse sin detenerlas. termcanvas guarda la distribución del canvas y una identidad estable para cada terminal. cuando vuelve a abrirse, reconecta el nodo a la sesión de tmux existente.

hay una diferencia importante entre cerrar la aplicación y cerrar un nodo. cerrar la aplicación conserva una sesión respaldada por tmux. hacer clic en x en un terminal lo destruye. si tmux muere fuera de la aplicación, o la máquina se reinicia sin restaurar tmux, el proceso vivo desaparece aunque la distribución visual permanezca.

esa distinción provocó algunos de los bugs menos glamurosos del proyecto. los ids de conexión del terminal cambian; la identidad del terminal no debe hacerlo. un canvas puede restaurarse perfectamente mientras el shell que tiene debajo está equivocado, falta o aparece duplicado. Resolver bien ese ciclo de vida importaba más que otra animación del canvas.

agentmux fue la parte difícil

la parte más difícil fue sincronizar agentmux con la aplicación.

un canvas de terminales puede tratar cada nodo como un shell aislado. una cabina de agentes no. cuando un agente crea otro agente, la nueva sesión tiene que aparecer en la barra lateral del canvas actual con el nombre, padre y estado correctos. tmux, la base de datos de agentmux y el renderer de electron no se actualizan al mismo reloj.

las primeras versiones podían saber que existía un worker sin mostrarlo correctamente. un agente podía estar vivo en tmux pero ausente del árbol. la barra lateral podía conservar un estado antiguo después de que el runtime hubiera avanzado. volver a abrir la aplicación añadía otra oportunidad para que las dos vistas dejaran de coincidir.

agentmux se convirtió en la capa de direccionamiento bajo la interfaz. cada terminal gestionado recibe su identidad de proyecto y agente mediante variables de entorno. un agente puede preguntar quiénes son sus vecinos, crear un hijo, conectarse con un par, delegar con ask y leer el resultado de otro agente. termcanvas usa ese runtime para actualizar el árbol de la barra lateral y el resumen de la flota del canvas actual.

los enlaces entre pares importan porque permiten que los agentes se dirijan unos a otros. en la versión pública son relaciones del runtime, no líneas que pueda señalar en el canvas. el terminal sigue siendo la superficie de control. la barra lateral es la vista honesta de la rama que estoy dirigiendo.

eliminé al comandante

el primer diseño de agentes gestionados tenía un comandante y workers debajo. me dio rápidamente la jerarquía que quería, pero hizo que autoridad y estructura visual fueran la misma cosa.

el trabajo real era más desordenado. un agente de pruebas podía necesitar preguntarle algo directamente a un agente de investigación. un hijo podía crear a su propio hijo. a veces quería varias raíces en el mismo canvas sin fingir que una era la jefa.

el 2 de julio cambié agentmux de un árbol fijo de comandante y workers a un grafo de pares. cualquier terminal puede ser ahora un centro de mando. crear sigue generando linaje, así que la jerarquía continúa visible, pero el linaje ya no decide quién puede hablar con quién.

ese cambio es la razón por la que agentmux mantiene separados el linaje de creación y el direccionamiento entre pares. la versión pública de termcanvas muestra el árbol de creación en la barra lateral. los enlaces entre pares siguen importando por debajo, pero no voy a llamarlo un grafo visible hasta que la interfaz dibuje realmente esas conexiones.

entonces me convertí en el bucle de polling

cuando crear agentes funcionó, iniciar otro se volvió barato.

podía ejecutar claude code en un terminal, codex en otro y opencode en algún sitio más. otros canvas contenían trabajo que ni siquiera era código.

entonces empecé a comprobarlos.

abrir un terminal para ver si todavía trabaja. cambiar a otro porque quizá terminó. comprobar uno silencioso por si falló. volver al primero y descubrir una pregunta esperando allí.

no hubo un accidente dramático que hiciera evidente la respuesta. fue el coste mental repetido de hacerme la misma pregunta todo el día:

which one needs me right now?

se suponía que los agentes reducirían la cantidad de trabajo que llevaba en la cabeza. en cambio, su estado se había convertido en otra cosa que recordar.

la pequeña función que cambió el producto

termcanvas lee el canvas actual y clasifica los agentes gestionados cuando reconoce un patrón de salida. el encabezado comprime estados como working, idle, done, stale, failed y waiting en un solo resumen.

también hay un indicador ámbar de atención. es heurístico. v0.3.10 reconoce el patrón actual del selector de opciones de OpenCode, pero puede pasar por alto prompts de otros harnesses o de interfaces futuras.

por eso no es lo que pido a la gente que confíe en el lanzamiento. la parte que puedo mostrar es más sencilla: un resumen de la flota del canvas actual, un árbol en la barra lateral de quién creó a quién y un terminal real que puedo dirigir sin perder la rama que lo rodea.

no necesito que los agentes tomen todas las decisiones por mí. necesito que sigan trabajando y que luego me resulte más fácil volver a la pieza correcta cuando haga falta mi criterio. ese sigue siendo el objetivo de la herramienta...

por qué sigo construyéndola

sigo construyéndola porque la flota es mi forma de trabajar ahora. el código es una parte. el canvas actual puede contener sesiones de investigación, contenido, un proceso largo y el terminal donde decido qué ocurre después. veo un terminal enfocado cada vez, mientras la barra izquierda mantiene cerca la rama y el encabezado mantiene cerca su estado actual. las herramientas centradas solo en programar no me dan esa relación con el trabajo.

la razón profunda sigue siendo la misma y es sencilla: quiero mantener mi mente en orden.

los agentes son útiles cuando aumentan lo que puedo hacer sin quitarme el juicio. termcanvas es mi intento de construir la interfaz para esa relación. que los agentes carguen con la ejecución. muéstrame la jerarquía. déjame la elección.

dónde está ahora

v0.3.10 está disponible como dmg y zip. funciona en Macs apple-silicon y requiere tmux para los agentes gestionados y python 3 para el wrapper de agentmux incluido. la build no está firmada, así que macos pide aprobación la primera vez que se abre. soy el único mantenedor.

la interfaz pública muestra un terminal enfocado cada vez. la barra lateral muestra el árbol de creación del canvas actual y el encabezado muestra el resumen de su flota. los enlaces entre pares y la comunicación de agentes son comportamiento real del runtime, pero en esta versión no se dibujan como líneas. la detección de estado puede equivocarse y el indicador de atención sigue siendo heurístico. cerrar la aplicación puede conservar una sesión de tmux que siga viva; no prometo recuperación después de reiniciar la máquina.

no es multiplataforma. un canvas grande puede convertirse en su propio tipo de ruido. todavía estoy descubriendo si esto funciona para personas cuyas mentes y flotas de agentes se parecen a las mías.

si ya ejecutas varios agentes, pruébalo con trabajo real y dime en qué momento la barra lateral deja de ayudar. eso es más útil que decirme que la captura se ve bonita.