ADE
Agent Development Environment: entorno pensado para ejecutar, organizar y supervisar agentes de desarrollo.
Toda la biblioteca
Elegí una puerta de entrada
01Concepto
Modelos guiados — el entorno es la política
Trabajar con un agente de forma segura depende menos de que el modelo recuerde pedir permiso y más de que el harness, el sistema operativo y las credenciales hagan imposible actuar fuera del alcance previsto.
⚿ Gobierno de agentes02Concepto
CLI vs. web — el agente dentro del proyecto
La terminal no vuelve más inteligente al modelo: lo ubica dentro del sistema que debe comprender, modificar y verificar. La web conserva ventaja para pensar, investigar y comunicar.
⌨ Gobierno de agentes03Guía
Elegir modelo y nivel de razonamiento
Una guía práctica para asignar coordinadores y workers, subir razonamiento antes de pagar un modelo mayor y escalar cuando aparece una brecha real de capacidad.
△ Gobierno de agentes04Guía
Antes de publicar, probá el arranque real
Un build exitoso no garantiza que el backend pueda iniciar. Un preflight con el comando de producción y un healthcheck bloqueante cierran esa brecha.
◉ Gobierno de agentes05Editorial
Amp y la fábrica de agentes en la nube
Amp empaqueta agente, máquina, contexto y Git en una sola superficie. No inventa el desarrollo multiagente, pero vuelve producto una práctica que todavía solemos construir a mano.
◌ Gobierno de agentes06Guía
Cómo leer los rankings de OpenRouter
Una guía para interpretar uso, gasto, velocidad y benchmarks de OpenRouter, seguir sus trece secciones de texto y convertir las señales en pruebas comparables.
△ Gobierno de agentes07Concepto
Jev: decisiones pequeñas dentro de sistemas grandes
Qué hace un modelo de decisiones estructuradas y dónde conviene ponerlo: routing, clasificación, scoring y gates antes de cambiar el estado.
◈ Gobierno de agentes08Editorial
Gentle AI y Engram: memoria y proceso para agentes de código
Qué aporta un configurador de entorno y qué resuelve una memoria persistente cuando el trabajo de agentes cruza sesiones, herramientas y proyectos.
◈ Gobierno de agentes09Concepto
Tailscale: una red privada que empieza por la identidad
Tailnets, WireGuard, conexiones directas y relays: un mapa para entender qué resuelve Tailscale y qué responsabilidades siguen siendo tuyas.
◈ Gobierno de agentes10Guía
Tailscale: permisos que se pueden explicar
Diseñar grants por identidad, destino y puerto; comprobar accesos permitidos y denegados; distinguir red, SSH y permisos de aplicación.
⚿ Gobierno de agentes11Editorial
Comparar harness CLI: Codex, Claude Code, OpenCode V2, Cline y OMP
Ventajas, diferencias y desventajas de cinco harness de programación: cómo elegirlos, repartir responsabilidades y evaluar el costo real de trabajar con agentes.
⚿ Gobierno de agentes12Editorial
Enrutamiento avanzado de agentes: modelo, esfuerzo, rol y harness
Por qué elegir un agente exige evaluar no solo el modelo y su razonamiento, sino la función y el harness: Codex frente a OMP como caso de contraste.
⌘ Gobierno de agentes13Editorial
RCT y Overdrive: protocolos humanos para gestionar la cuota de proveedores
Dos respuestas preparadas para la escasez y el vencimiento de cuota: proteger pasos LIVE, aprovechar trabajo BUILD y mantener la decisión en manos del operador.
◈ Gobierno de agentes14Concepto
Orca como ADE y plano de control
Orca organiza agentes, repositorios y entornos de ejecución; no sustituye al modelo ni decide por sí solo cómo debe trabajar el equipo.
◉ Orca15Concepto
Workspaces, proyectos y worktrees
El proyecto organiza el repositorio, el workspace representa un frente de trabajo y el worktree aporta aislamiento real de archivos y rama.
⑂ Orca16Concepto
Orquestación en Orca
Orquestar no es abrir agentes en paralelo: es repartir autoridad, dependencias, contexto, decisiones y evidencia de finalización.
✣ Orca17Concepto
Hosts SSH y topología de ejecución
Orca puede operar como interfaz local mientras agentes, repositorios y runtimes viven en WSL o en una máquina remota.
⌁ Orca18Concepto
Agent terminals y ciclo de sesión
Una agent terminal vincula un CLI, una sesión, un worktree y un estado observable; no es solamente una consola con otro nombre.
▤ Orca19Concepto
Continuidad, recuperación y observabilidad
Orca preserva layout y scrollback, y puede mantener agentes vivos mientras sobreviva el daemon; el estado crítico debe seguir existiendo fuera de la interfaz.
◌ Orca20Guía
Orca Desktop con Windows y WSL
Patrón de referencia para separar la interfaz de escritorio del entorno Linux donde viven repositorios, runtimes y agentes.
⊞ Orca21Guía
Acceso portátil a Orca mediante red privada
Usar otro dispositivo como cliente del mismo entorno de desarrollo, sin duplicar repositorios ni publicar SSH en Internet.
↗ Orca22Caso real
Caso real — Orca como cockpit multiagente
La evolución de un coordinador único a dirección, integración y paquetes separados, con auditoría cruzada y aceptación verificable.
◈ Orca23Guía
Planificar una workstation AM5 escalable
Cómo auditar una PC existente y migrar a AM5 en tres escalones — económico, medio y high-end — sin recomprar media máquina en cada etapa.
◈ Orca24Editorial
OpenDesign y la dirección visual de los agentes
Los modelos ya pueden construir interfaces. El problema es lograr que dejen de improvisar la identidad visual en cada ejecución. OpenDesign propone convertir esa dirección en archivos portables.
✦ Diseño agéntico25Editorial
OpenDesign entre Windows, WSL, planes y proxies
Local-first no siempre significa un único entorno. Cuando la interfaz vive en Windows y los agentes en WSL, elegir entre CLI, BYOK y proxy define consumo, sesiones y superficie de riesgo.
⌁ Diseño agéntico26Concepto
Hermes como agente operativo
Un agente autoalojado que lleva consultas y alertas a los canales donde trabaja el equipo, sin convertir cada interacción en una sesión técnica.
✦ Hermes27Guía
Preset de instalación de Hermes
Cinco decisiones previas para montar Hermes sin copiar una infraestructura ajena: hosting, modelo, canales, concurrencia e integraciones.
◇ Hermes28Caso real
Caso real — Hermes como interfaz operativa
Un agente autoalojado acercó consultas y alertas a canales cotidianos, con permisos acotados y pruebas de negocio observables.
◈ Hermes29Concepto
Del backup a una plataforma de funciones CRM
El backup read-only se convirtió en la base de una plataforma interna para analizar, revisar y desplegar funciones CRM con autoridades separadas.
▣ CRM versionado30Guía
Read-only como decisión arquitectónica
Mantener el backup y el análisis sin autoridad productiva mientras una vía separada permite desplegar cambios revisados y verificables.
⌁ CRM versionado31Caso real
Del backup al mapa de procesos
El mapa de procesos permite analizar sin acceso productivo; la nueva vía de cambios conecta los hallazgos verificables con revisión y despliegue controlado.
⌘ CRM versionado32Caso real
Caso real — De contador a tablero de continuidad operativa
Una herramienta personal creció hasta unir incidentes, salud de servicios y señales progresivas sin llevar credenciales al navegador.
◌ Casos de producto33Caso real
Caso real — Widgets que convierten reglas del CRM en flujos guiados
Dos widgets embebidos llevaron contexto, validaciones y automatización al punto exacto donde el equipo tomaba decisiones.
◆ Casos de producto34Caso real
Caso: un Director que separa narración y memoria
Una arquitectura orquestada donde un modelo redacta la escena, Jev decide sus consecuencias y un registro de eventos reconstruye lo que cada personaje puede recordar.
◉ Casos de producto35Guía
Tailscale en un entorno de agentes: portátil, VPS y WSL
Un diseño de referencia anonimizado para acceder al host de trabajo, operar una VPS y compartir previews internas sin publicar puertos de administración.
◆ Casos de producto