Un proyecto de transformación digital combinaba integraciones, datos, APIs, seguridad y operación productiva. Una sola conversación podía conservar el contexto, pero se convertía en cuello de botella al abrir varios frentes en paralelo.
La alternativa de lanzar agentes sin estructura tampoco servía: aumentaba el riesgo de cambios superpuestos, decisiones contradictorias y pérdida de contexto al cambiar de sesión.
Modelo inicial adoptado
Agente coordinador
Un agente de mayor capacidad opera sobre el workspace principal. Su función es:
revisar el estado general;
mantener decisiones y restricciones vigentes;
preparar el plan;
dividir el trabajo en unidades verificables;
revisar implementaciones y auditorías;
decidir el siguiente frente.
El coordinador no existe para implementar todo. Existe para que cada tarea nazca con contexto suficiente y vuelva con evidencia comparable.
Implementadores y revisores
Las tareas acotadas se asignan según costo, disponibilidad y fortaleza del agente. Pueden convivir modelos y CLIs distintos sin cambiar la metodología.
Cada worker recibe:
su propio worktree y rama;
un alcance explícito;
restricciones operativas;
condiciones de finalización;
una forma esperada de entregar evidencia.
Los agentes de revisión se separan, cuando corresponde, de quienes realizaron la implementación.
Flujo operativo inicial
El coordinador inspecciona el proyecto y prepara una tarea.
Se crea un worktree desde una base conocida.
El implementador trabaja dentro de su alcance.
Entrega cambios, pruebas, riesgos y pendientes.
Otro agente o el coordinador revisa el resultado.
La integración y cualquier acción productiva permanecen detrás de un gate humano.
Evolución del caso: V4, octubre de 2026
La documentación V4, revisada el 12 de octubre de 2026, separa responsabilidades que antes se concentraban en un solo coordinador. El diseño anterior queda como historia del caso; la distribución vigente distingue tres niveles:
Nivel
Asignación del entorno
Responsabilidad
Dirección general
Opus
Conversación con la persona, prioridades y decisiones transversales
Integración
Sol con esfuerzo low
Reconstruir estado, ordenar dependencias e integrar evidencia de los paquetes
Coordinación de paquete
Sol con esfuerzo medium
Conducir una capacidad acotada hasta su aceptación
Son asignaciones de este proyecto, no una recomendación universal ni una equivalencia entre modelos. Para implementación LIVE se usa Luna con esfuerzo high o Sonnet; la auditoría cambia a la familia opuesta al implementador. Separar familias agrega diversidad de revisión, pero no garantiza detectar errores ni reemplaza las pruebas.
La unidad sigue siendo una capacidad, una tarea, una rama y un worktree. BUILD/LIVE y el gate de tres partes ya existían en V3: paridad con el comportamiento del CRM, recuperación preparada y auditoría. V4 modifica el reparto de autoridad y permite operaciones LIVE pequeñas dentro de un alcance previamente autorizado, con verificación y reversión automática acotada. Borrados y tombstones, las marcas de eliminación, requieren permiso humano explícito. Tener una regla en el repositorio no concede permisos en otra sesión o herramienta.
La dirección general recibe una bandeja de decisiones agrupadas por urgencia: incidentes, destrabes y asuntos sin apuro. El integrador reúne evidencia; no interrumpe a la persona por cada avance ni convierte una decisión pendiente en permiso implícito.
Del merge al resultado aceptado
El circuito vigente distingue listo local, aplicado y aceptado. Un PR integrado demuestra integración; un postflight inmediato demuestra el comportamiento que efectivamente midió. La aceptación natural requiere observar el ciclo real acordado. Si queda trabajo, el handoff conserva el remanente, su responsable y la evidencia que falta: entregar el problema a otra persona no equivale a resolverlo.
Al retomar, primero se reconstruyen PRs, ramas, workers y despliegues reales. Sólo después se abre trabajo nuevo. Esa comprobación evita duplicar una implementación que siguió avanzando mientras la conversación estaba cerrada.
Esta actualización resume documentación y registros del proyecto revisados el 12 de octubre, anonimizados. No constituye una nueva ejecución de sus pruebas ni una validación universal de sus controles. Los contratos de rol deben contrastarse con los permisos efectivos del runtime, como explica el entorno es la política.
Qué aportó Orca
Paralelismo comprensible
Los frentes dejaron de ser terminales anónimas. Cada uno quedó ligado a un proyecto, worktree, agente y estado visible.
Libertad de proveedor
Distintos CLIs convivieron en una misma superficie. El modelo pudo elegirse por tarea sin perder el mapa general del proyecto.
Aislamiento real
Las implementaciones no compitieron por el mismo checkout. Cada rama podía revisarse, compararse o descartarse sin contaminar el trabajo principal.
Continuidad
Separar interfaz, proceso, sesión, worktree y estado persistente permitió recuperar trabajo después de interrupciones sin asumir que todo seguía vivo ni tomar acciones destructivas por reflejo.
Operación remota
La interfaz funcionó como cockpit mientras repositorios y agentes permanecían en un entorno de ejecución central. Otros dispositivos podían actuar como ventanas hacia el mismo estado, sin crear copias divergentes.
Beneficios obtenidos
más frentes simultáneos sin compartir archivos de trabajo;
continuidad del contexto aunque cambiara el implementador;
selección de modelo por costo y tipo de tarea;
handoffs más claros y revisables;
menor dependencia de una sesión o interfaz concreta;
separación explícita entre planificación, implementación, auditoría y producción.
La lección transferible
La mejora no vino de “usar muchos modelos”. Vino de diseñar un sistema donde los modelos pueden reemplazarse, las tareas quedan aisladas y el contexto importante no depende de ninguno de ellos.
Orca volvió visible y operable esa arquitectura. La calidad del resultado siguió dependiendo de los contratos de trabajo, Git, las validaciones y la supervisión humana.
Caso basado en un entorno real. Se removieron nombres de empresa, repositorios, infraestructura, incidentes identificables y datos operativos.
Agent Development Environment: entorno pensado para ejecutar, organizar y supervisar agentes de desarrollo.
Agent-to-agent
Delegación entre agentes completos que trabajan en conversaciones y entornos separados, intercambian instrucciones o archivos y devuelven resultados.
Agente
Sistema que combina un modelo, instrucciones y herramientas para realizar tareas dentro de un alcance. Su capacidad de actuar depende del harness, el entorno y los permisos.
Amp
Entorno de desarrollo agéntico que reúne modelos, threads, máquinas remotas, Git y coordinación bajo una misma plataforma.
Árbol de procesos
Organización de circuitos de negocio y las funciones que integran cada rama. Permite acotar el análisis y definir evidencia verificable para una unidad de trabajo.
Benchmark
Evaluación con tareas, condiciones y una regla de puntuación definidas. Sirve para comparar resultados dentro de ese protocolo; un puntaje no demuestra el mismo desempeño en tu proyecto.
BYOK
Bring Your Own Key: modalidad donde aportás tu propia clave API de un proveedor. El consumo sigue la cuenta y las condiciones de esa integración; no equivale a usar una suscripción de chat.
Choice
Primitiva de decisión de Jev que elige entre opciones definidas por la aplicación y devuelve una opción con una distribución de probabilidades.
Claude Code
Agente de programación de Anthropic que combina contexto del proyecto y herramientas. Puede especializar su trabajo mediante instrucciones, skills, hooks y subagentes, según la configuración.
CLI
Interfaz de línea de comandos. Permite trabajar con herramientas y agentes desde una terminal, con acceso directo al proyecto y su entorno.
Cline
Agente de programación que puede trabajar de forma interactiva o mediante su CLI sin interfaz interactiva. Automatizarlo exige acotar el objetivo, los cambios autorizados y la validación de la salida.
Codex CLI
Interfaz de terminal de Codex para trabajar sobre un repositorio con un agente. El sandbox limita la ejecución y la política de aprobación determina qué acciones necesitan autorización.
Costo por sesión
Gasto observado en una sesión de agente. Para compararlo hay que fijar harness, tramo de turnos y agregación; una sesión barata puede haber fallado y no equivale a una tarea resuelta.
Costo por tarea resuelta
Costo del trabajo que alcanza el criterio de aceptación, incluyendo intentos fallidos, herramientas y revisión. Permite evaluar productividad más allá del precio por token o por sesión.
CRM
Sistema que centraliza relaciones, datos y procesos comerciales. En estos casos también actúa como fuente de verdad operativa.
Cuota de gasto
Porcentaje del gasto observado que corresponde a un modelo o tarea en una vista. Combina precio y consumo; no equivale a cuota de tokens, cantidad de usuarios o calidad.
Cuota de uso
Porción del total que corresponde a un modelo o autor dentro de una población y período. Puede medirse en tokens o solicitudes; hay que conservar el denominador para interpretar el porcentaje.
Daemon
Proceso que permanece ejecutándose en segundo plano y sostiene servicios, sesiones o tareas aunque una interfaz se cierre.
Decision gate
Punto de control que detiene el avance hasta resolver una decisión o cumplir una condición. Tener confianza en una respuesta no reemplaza la autorización necesaria.
DESIGN.md
Archivo portable que codifica colores, tipografía, composición y reglas visuales para que distintos agentes produzcan artefactos coherentes.
Engram
Memoria local y persistente para agentes que permite guardar y buscar observaciones por proyecto mediante CLI, MCP y otras interfaces.
Frontera de Pareto
Opciones para las que no hay otra igual o mejor en todas las dimensiones elegidas y mejor en al menos una, como costo y puntaje. La frontera cambia si cambian las dimensiones o los candidatos.
Gentle AI
Configurador de agentes de código que prepara integraciones, memoria, skills y componentes de trabajo o revisión para ajustar el gobierno del entorno.
Grant
Regla de Tailscale que concede capacidades de red o aplicación entre orígenes y destinos definidos. Los permisos se suman; una regla no resta accesos concedidos por otra.
Handoff
Entrega de contexto y responsabilidad a otro agente o persona: objetivo, cambios, pruebas, límites, pendientes y ubicación del resultado. Permite retomar el trabajo sin reconstruirlo desde cero.
Harness
Sistema que administra el ciclo del agente: prepara contexto, expone herramientas, ejecuta llamadas, recoge resultados y aplica controles. La CLI es una interfaz para usarlo, no un sinónimo.
Healthcheck
Comprobación de salud de un servicio. Debe validar una señal que represente la capacidad esperada, no sólo que exista una respuesta HTTP.
Hermes
Agente operativo que puede vivir en un servidor, conectarse a canales e integraciones y ejecutar tareas con continuidad.
Jev
Modelo de TypeSafe orientado a decisiones estructuradas: recibe texto o estado y devuelve respuestas tipadas según opciones y criterios definidos por la aplicación.
Latencia
Tiempo de espera entre una solicitud y un hito de respuesta. Hay que aclarar si se mide hasta el primer token o hasta la respuesta completa y con qué condiciones y percentil.
Liveness
Señal que comprueba si un proceso está vivo. No demuestra por sí sola que el servicio pueda atender tráfico correctamente.
MagicDNS
Función de Tailscale que permite encontrar dispositivos de la tailnet por nombre. Facilita localizar un destino, pero no concede acceso.
MCP
Model Context Protocol: protocolo abierto para conectar aplicaciones de IA con herramientas y fuentes de datos. La conexión no reemplaza los permisos ni la aprobación de acciones.
Mediana
Medida que divide un conjunto ordenado en dos mitades. Describe el centro, pero no muestra la dispersión ni el costo de las sesiones extremas. No es lo mismo que el promedio.
Memoria curada
Selección de decisiones, convenciones y descubrimientos útiles para otras sesiones. Cada recuerdo conserva contexto y debe contrastarse con el estado actual antes de aplicarlo.
Mínimo privilegio
Principio de dar sólo los permisos, credenciales y acceso de red necesarios para una tarea. Reduce el impacto de errores y evita que una consigna amplia se convierta en autoridad ilimitada.
Modelo
Componente entrenado que procesa entradas y genera salidas, incluidas propuestas de llamadas a herramientas. El agente agrega instrucciones, contexto, ejecución y controles alrededor de ese modelo.
n8n
Plataforma de automatización visual usada para coordinar integraciones, webhooks y pasos entre distintos sistemas.
Nivel de razonamiento
Control del esfuerzo de deliberación de un modelo, según las opciones del proveedor y el harness. Puede aumentar tiempo y consumo; no reemplaza contexto, herramientas ni verificación.
Noul
Primitiva de Jev que estima, entre 0 y 1, la probabilidad de que se cumpla una condición definida.
Observabilidad
Evidencia para entender qué está haciendo un sistema: estado, salida, eventos y señales de salud. Permite distinguir trabajo activo, espera, bloqueo y fallo, en vez de confiar sólo en que la interfaz siga abierta.
ODD
Organic Driven Development: recorrido de Gentle AI que propone explorar, implementar cambios autorizados, verificar y dejar referencias recuperables en proporción al tamaño del trabajo.
OpenCode
Herramienta abierta de programación con agentes que permite configurar modelos y proveedores. La flexibilidad del catálogo requiere verificar compatibilidad, permisos y resultados para cada tarea.
OpenDesign
Workspace local-first que combina agentes de código, skills, templates y sistemas DESIGN.md para producir artefactos visuales como archivos reales.
OpenRouter
Plataforma que da acceso a modelos de distintos proveedores mediante una API común. Sus rankings describen los datos incluidos en sus vistas, no todo el mercado ni la calidad de cada tarea.
Oracle
Rol de segunda opinión dentro de Amp, usado por el agente principal para consultar razonamiento, planificación o decisiones difíciles.
Orb
Máquina remota, fresca y aislada donde un agente de Amp puede trabajar con código, herramientas y servicios aunque la computadora del usuario esté apagada.
Orca
ADE y plano de control para organizar agentes, repositorios, workspaces, terminales y hosts sin reemplazar al modelo.
Orquestación
Coordinación de agentes con un objetivo común, tareas, dependencias, responsables y evidencia de cierre. Abrir varias sesiones en paralelo no define por sí solo quién decide o integra.
Plano de control
Capa desde la que se organizan y supervisan agentes, sesiones y entornos de ejecución. Coordina el trabajo sin ser el modelo ni la máquina que lo ejecuta.
Preflight
Verificación previa al despliegue que ejecuta el comando real de producción en un entorno de prueba y comprueba que el servicio arranca y responde.
Proveedor
Servicio que recibe solicitudes y ejecuta un modelo. Puede ser distinto de su autor; el endpoint, los límites y el rendimiento forman parte de la configuración que hay que comparar.
Prueba negativa
Comprobación de que una acción prohibida realmente falla. En red, debe probarse contra un servicio disponible para no confundir una caída con una restricción efectiva.
Read-only
Acceso de sólo lectura que permite consultar sin modificar el sistema fuente. Una barrera real se aplica en credenciales, herramientas y arquitectura, no sólo en una instrucción al agente.
Readiness
Señal que comprueba si un servicio está listo para atender tráfico. Puede fallar aunque el proceso siga vivo.
Routing
Selección del modelo o proveedor que atenderá una solicitud, mediante reglas o un router. Cambia costo, disponibilidad y comportamiento, por lo que debe registrarse al comparar resultados.
Runner
Máquina propia o administrada que Amp puede usar como entorno de ejecución en lugar de un Orb de su infraestructura.
Sandbox
Entorno con límites técnicos sobre recursos como archivos, procesos o red. Reduce lo que una ejecución puede afectar; su protección depende de los límites realmente configurados.
Score
Primitiva de Jev que puntúa un caso sobre una escala configurada. Su valor crudo no debe interpretarse automáticamente como un número entre 0 y 1.
Skill
Paquete reutilizable de instrucciones y recursos para una tarea especializada. Ayuda a repetir un método de trabajo; no concede permisos ni garantiza que el resultado sea correcto.
SSH
Protocolo seguro para acceder y ejecutar trabajo en otra máquina o entorno, como WSL o un servidor remoto.
Subagente
Agente al que otro delega una parte del trabajo con contexto propio. Su separación de conversación no implica necesariamente una máquina, archivos o permisos independientes.
Tailnet
Red privada de Tailscale que agrupa identidades y dispositivos autenticados. Pertenecer a ella no sustituye los permisos de cada servicio.
Tailscale
Herramienta que conecta usuarios y dispositivos en una red privada basada en identidades, con tráfico cifrado y reglas explícitas de acceso.
Tailscale Funnel
Función que expone un servicio local a Internet. Conviene usarla con una audiencia pública deliberada, controles de aplicación y un tiempo de exposición definido.
Tailscale Serve
Función que comparte un servicio local dentro de la tailnet, sujeto a sus reglas de acceso. Sirve para previews y paneles internos.
Tailscale SSH
Función que gestiona autenticación y autorización SSH en nodos compatibles mediante reglas propias. Habilitar TCP 22 en la tailnet no basta para configurarla.
The Dial
Selector de Amp que expresa cuánto esfuerzo requiere una tarea mediante los modos low, medium, high y ultra, independientemente del modelo asignado detrás.
Thread
Hilo de conversación que conserva el contexto de una tarea y sus resultados. En Amp puede coordinar trabajo en un entorno propio; la persistencia del hilo no garantiza que la máquina siga ejecutándose.
Throughput
Velocidad de generación, habitualmente medida en tokens por segundo. Debe compararse bajo condiciones equivalentes; no incluye por sí sola el tiempo de herramientas, turnos y reintentos de un agente.
Token
Unidad en la que un modelo representa y procesa contenido. No equivale siempre a una palabra: la segmentación depende del tokenizador. Más tokens de uso no significan más usuarios ni más tareas resueltas.
Tool calling
Mecanismo por el que un modelo solicita ejecutar una herramienta con argumentos. La ejecución la realiza el sistema que lo rodea y puede exigir permisos; contar llamadas no demuestra que fueron correctas.
TTFT
Time to First Token: tiempo desde el envío de la solicitud hasta recibir el primer token. Describe la espera inicial, no cuánto tarda en completarse toda la respuesta o tarea.
Ventana de contexto
Capacidad de tokens que un modelo puede manejar en una interacción, según su configuración. El máximo anunciado, el contexto realmente usado y la calidad al recuperar información son cosas distintas.
WireGuard
Protocolo que Tailscale utiliza para cifrar el tráfico entre dispositivos. El cifrado se mantiene tanto en conexiones directas como mediante relays.
Worker
Agente ejecutor al que se delega una tarea acotada. Recibe alcance, permisos y criterio de finalización, y devuelve resultados verificables al coordinador.
Workspace
Frente de trabajo visible que agrupa tabs, terminales, editores y una tarea; no equivale por sí mismo al aislamiento de Git.
Worktree
Directorio de trabajo adicional de un repositorio Git, normalmente en otra rama. Separa archivos para tareas paralelas, pero comparte datos del repositorio y no es un sandbox de seguridad.
WSL
Windows Subsystem for Linux: entorno Linux integrado en Windows donde pueden vivir repositorios, runtimes y agentes CLI.