La orquestación de agentes de IA está lista para producción cuando se cumplen ocho condiciones: los agentes se ejecutan en espacios de trabajo aislados, cada cambio supera una verificación automatizada, un humano aprueba en puntos de control definidos, el coste se atribuye por unidad de trabajo fusionada, las instrucciones del agente son archivos versionados, el orquestador no depende de un único proveedor de modelos, se conoce con precisión la residencia de los datos y cualquier ejecución fallida cuenta con una vía de recuperación definida. Una prueba piloto no necesita nada de esto y aun así puede resultar impresionante. La producción requiere los ocho puntos, porque cada uno de ellos representa un modo de fallo que solo aparece a gran escala. Este artículo presenta la lista de comprobación, qué aspecto tiene una respuesta deficiente y cómo poner a prueba cada criterio en sus sistemas actuales.
La lista de verificación
| # | Requisito | La pregunta clave | Una respuesta deficiente |
|---|---|---|---|
| 1 | Aislamiento del entorno de trabajo | ¿Dónde escribe cada agente? | "En el directorio de trabajo del repositorio" |
| 2 | Verificación automatizada | ¿Qué debe pasar antes de que un humano lo revise? | "El revisor ejecuta las pruebas" |
| 3 | Puntos de control humanos | ¿Dónde decide exactamente una persona? | "Los revisores miran los PRs" |
| 4 | Atribución de costes | ¿Cuánto costó el último cambio fusionado? | "Vemos la factura mensual de la API" |
| 5 | Instrucciones versionadas | ¿Dónde residen las instrucciones del agente? | "En un prompt pegado en el chat" |
| 6 | Portabilidad de proveedores | ¿Qué se rompe si el modelo queda obsoleto? | "Reescribiríamos los prompts" |
| 7 | Residencia de datos | ¿Qué entidades tienen una copia del código? | "El proveedor se encarga de eso" |
| 8 | Recuperación | ¿Qué pasa si una ejecución falla a la mitad? | "Alguien se da cuenta y limpia" |
El orden importa. Los puntos 1 al 3 garantizan la corrección técnica: sin ellos, el volumen produce defectos más rápido de lo que las revisiones humanas pueden detectarlos. Los puntos 4 al 6 garantizan la sostenibilidad operativa: sin ellos, el sistema funciona pero no se puede auditar, optimizar ni migrar. Los puntos 7 y 8 son los que inevitablemente plantearán el equipo de seguridad y el ingeniero de guardia, casi siempre después del despliegue inicial.
1. Aislamiento del entorno de trabajo
Si dos agentes editan el mismo checkout de trabajo, intercalarán sus escrituras y el diff resultante no pertenecerá al plan de ninguno de los dos. La unidad de aislamiento idónea debe ser un git worktree: un directorio de trabajo independiente con su propia rama e índice, que comparte el almacén de objetos con el repositorio principal. Crear un worktree es un checkout, no una clonación, por lo que toma una fracción de segundo en lugar del tiempo necesario para volver a descargar todo el historial.
# Un directorio y una rama por cada plan.
git worktree add ../work/plan-4812 -b plan/4812
git -C ../work/plan-4812 status --short
git worktree remove ../work/plan-4812
Los contenedores proporcionan una barrera más estricta cuando el agente ejecuta código no confiable, y el modelo de seguridad de Docker describe lo que dicha barrera realmente garantiza. Para un agente de confianza que opera sobre su propio repositorio, un worktree suele ser el equilibrio óptimo: aislamiento por plan sin la sobrecarga del arranque de un contenedor en la ruta crítica. Git worktrees para agentes de IA en paralelo aborda los modos de fallo más habituales, incluidos los hooks compartidos y los submódulos que suelen descolocar a los equipos.
Pruébelo: Lance dos planes que modifiquen el mismo archivo y compruebe que ambos generen diffs limpios e independientes.
2. Verificación automatizada antes de la revisión humana
Un revisor que lee un diff que ni siquiera compila es un revisor cuyo tiempo se ha desperdiciado. Pruebas unitarias, linters, análisis de tipos, compilación y una validación de alcance contra el plan deben ejecutarse en el worktree del agente y adjuntar su salida al cambio. Esto no es otra cosa que integración continua aplicada por plan en lugar de por rama.
Dos filtros son esenciales para el código generado por agentes. Una comprobación de alcance (scope check) compara los archivos modificados con los que especificaba el plan, ya que a menudo un agente al que se le pide corregir una comprobación nula termina reformateando el archivo o renombrando variables innecesariamente. Un escaneo de seguridad busca las vulnerabilidades del Top 10 de OWASP para aplicaciones LLM: manejo inseguro de salidas, dependencias sospechosas en la cadena de suministro o credenciales expuestas. Filtros de verificación para código generado por IA detalla qué filtros deben bloquear la entrega y cuáles deben ser solo informativos.
Pruébelo: Pregunte qué porcentaje de cambios generados por agentes llegan a revisión humana con pruebas fallidas. Si nadie lo sabe, el filtro de verificación no existe.
3. Puntos de control humanos en exactamente dos momentos
Cero puntos de control significa que un agente fusiona directamente a main y los errores son descubiertos por el resto del equipo o los usuarios. Diez puntos de control significa aprobar manualmente cada llamada a una herramienta, lo que convierte al humano en el componente más lento del sistema e induce a los revisores a aprobar por simple reflejo.
Dos puntos de control colocan el criterio humano donde realmente marca la diferencia. El punto del plan es donde un malentendido es más barato de corregir, porque todavía no se ha escrito código y un plan es solo una página de texto. El punto del diff es donde se confirma la corrección contrastándola con la salida de las pruebas de verificación. Qué es una fábrica de software describe la secuencia completa.
Pruébelo: Defina los dos momentos exactos en que una persona toma una decisión. Si la respuesta es una serie difusa de actividades en lugar de dos hitos claros, no tiene puntos de control, solo supervisión manual.
4. Atribución de costes por cambio fusionado
La factura mensual de la API no ofrece información accionable. La métrica que se debe medir es el coste por pull request fusionada: el gasto total del periodo, incluyendo los planes rechazados o descartados, dividido entre los pull requests fusionados con éxito. El trabajo descartado forma parte intrínseca del coste del trabajo aceptado.
Analice este dato junto con la tasa de rechazo (denial rate), es decir, el porcentaje de pull requests cerrados sin fusionar. Cualquiera de estas dos métricas puede manipularse a costa de empeorar la otra, razón por la cual las métricas DORA siempre se evalúan en conjunto. Medición del rendimiento de los agentes de código define cada indicador y qué significa una cifra anómala.
Pruébelo: Solicite el coste por PR fusionada del mes pasado. Si solo se puede calcular a mano a partir de una factura general, significa que no se está gestionando activamente.
5. Instrucciones como archivos versionados
El comportamiento de un agente que reside en un prompt copiado y pegado en una ventana de chat no se puede auditar, comparar mediante diffs ni revertir. Las instrucciones deben residir en el repositorio, por el mismo motivo que la configuración en The Twelve-Factor App: cualquier modificación se convierte en un diff en un pull request que un ingeniero senior puede revisar y rechazar.
// Las instrucciones y la memoria son archivos leídos por el orquestador,
// no cadenas de texto compiladas en el binario. Una convención aprendida
// el lunes la aplican todos los agentes y desarrolladores el martes.
interface Promptware {
program: string; // Program.md - instrucciones de la fase
memory: string[]; // Memory/ - aprendizajes sobre este repositorio
tools: string[]; // Tools/ - permisos acotados
logs: string[]; // Logs/ - historial de ejecución inmutable
}
El principal riesgo es la degradación no controlada (prompt drift): un agente con permiso para editar sus propias instrucciones puede empeorarlas, por ejemplo añadiendo "reintentar las pruebas fallidas hasta tres veces" tras una prueba inestable. El control de versiones es el cortafuegos, ya que cualquier cambio genera un diff visible en la revisión. Promptware: agentes que mejoran sus propias instrucciones analiza tanto este riesgo como el crecimiento excesivo de la memoria de contexto.
Pruébelo: Ejecute git log sobre el directorio que contiene las instrucciones de sus agentes. Un historial vacío significa que sus instrucciones operan al margen de la ingeniería formal.
6. Portabilidad entre modelos y agentes
Los modelos de lenguaje se descatalogan según el calendario del proveedor, no el suyo. Un orquestador que se acopla rígidamente a un único proveedor convierte cada aviso de obsolescencia en un traumático proyecto de migración. La capa que una organización debe poseer es el flujo de trabajo: etapas, filtros, puntos de control y memoria persistente. El motor de ejecución subyacente debe poder intercambiarse por plan, y el acceso a herramientas debe gestionarse a través de protocolos abiertos como el Model Context Protocol, en lugar de integraciones ad-hoc por cada agente.
La portabilidad también permite un enrutamiento basado en costes. Una tarea de triaje inicial no requiere un modelo de frontera costoso; un plan de refactorización arquitectónica probablemente sí. Esta optimización solo es factible si cambiar de modelo es una simple opción de configuración y no una reescritura de código.
Pruébelo: Cambie el modelo asignado a un plan y ejecútelo. Si requiere modificar código fuente en lugar de una configuración, tiene una dependencia acoplada, no una arquitectura flexible.
7. Residencia de datos claramente delimitada
Cada copia de su código fuente fuera de su perímetro de control requiere ser inventariada, regulada mediante acuerdos contractuales y oportunamente eliminada. Un agente alojado en la nube clona el repositorio en la infraestructura del proveedor, lo que introduce al menos a dos encargados de tratamiento sobre su código: el proveedor del agente y el proveedor del modelo de lenguaje. Un orquestador local (local-first) solo introduce uno, y únicamente para los fragmentos de código que se incluyen expresamente en los prompts.
No se trata solo de un debate sobre seguridad, sino sobre alcance legal: determina cuántos acuerdos de procesamiento de datos debe contemplar una auditoría de RGPD y si la residencia de datos en la UE es un simple parámetro de configuración o una compleja negociación contractual. Desarrollo de IA local-first aborda las preguntas clave que planteará el departamento de seguridad.
Pruébelo: Enumere todas las entidades que conservan una copia de su código durante la ejecución de un solo agente. Si la lista es más extensa de lo que esperaba, su equipo de auditoría llegará a la misma conclusión.
8. Una vía de recuperación definida ante fallos
A gran escala, las ejecuciones fallan inevitablemente: caídas de red a mitad del proceso, agentes atrapados en bucles infinitos o pasos de verificación que no responden. El orquestador debe contar con una respuesta para cada contingencia, y esa respuesta nunca puede ser "esperar a que alguien se dé cuenta".
- Fallo en la verificación: El trabajo vuelve al agente con el registro de errores real adjunto —no un resumen vago— y se reintenta en el mismo worktree hasta un límite prefijado.
- Ejecución abandonada: El worktree y su rama asociada se eliminan por completo, evitando que un plan bloqueado deje directorios residuales que interfieran en tareas posteriores.
- Desbordamiento de costes o bucles: Un límite estricto de tokens y tiempo por plan que detiene la ejecución en tiempo real en lugar de emitir un informe a posteriori.
- Estado parcial corrupto: Dado que cada plan posee su propio worktree y rama, un intento fallido se descarta eliminando un único directorio. Nada compartido se ve alterado.
Pruébelo: Interrumpa forzosamente el proceso de un agente a mitad de un plan. ¿Qué queda en el disco y cómo afecta al siguiente plan en la cola?
Cómo responde Ivy Tendril a estos ocho puntos
Ivy Tendril es una aplicación de escritorio local-first para macOS, Windows y Linux que gestiona agentes de código desde la redacción del plan hasta la entrega de un pull request revisado. Ofrece worktrees dedicados por plan (1), ejecución de pruebas, linters y revisión de diffs adjuntos a cada cambio con importación de CI en el plan Pro (2), los dos puntos de control humanos indispensables (3), contabilidad de costes por plan y por tarea (4), unidades de promptware como archivos versionados en Git (5), soporte agnóstico para cualquier CLI de agente y cualquier modelo configurable por plan (6), código y registros que nunca salen de su máquina (7), y mecanismos de reintento con salida de errores completa y limpieza automática del entorno (8).
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
En Windows, utilice irm https://cdn.ivy.app/install-tendril.ps1 | iex. Tendril es gratuito y con código disponible bajo la Functional Source License; las funciones para equipos, despliegue on-premise, SSO y sincronización de verificaciones de CI están disponibles en los planes Pro y Enterprise.
Preguntas frecuentes
¿Cuál de los ocho requisitos debe abordar primero un equipo?
Primero el aislamiento, luego la verificación y después los puntos de control. Los sobrecostes o los problemas de memoria son molestos; sin embargo, dos agentes escribiendo en el mismo checkout producen defectos imposibles de atribuir, lo que resulta mucho más destructivo y difícil de depurar.
¿Esta lista de verificación es exclusiva para agentes de desarrollo?
Los modos de fallo específicos sí lo son. El aislamiento del entorno, los filtros de alcance y la revisión de diffs son necesarios porque el resultado final es un cambio en una base de código compartida. Un agente que solo consulta datos o escribe en una base de datos propia opera bajo premisas distintas.
¿Cuántos agentes pueden ejecutarse en paralelo antes de que esto sea crítico?
Exactamente dos. Un solo agente en un único directorio de trabajo no necesita nada de esto. En el instante en que un segundo agente trabaja de forma concurrente, el aislamiento y la atribución de costes dejan de ser opcionales, y la capacidad de revisión humana pasa a ser el cuello de botella del rendimiento global, por encima de la velocidad de ejecución.
¿Añadir más paralelismo incrementa el rendimiento indefinidamente?
No. La revisión humana es inherentemente secuencial. Siguiendo la Ley de Amdahl, la fracción secuencial impone un límite superior insalvable: incorporar agentes más allá del punto en el que los revisores están saturados solo incrementa los costes y la tasa de rechazo, sin aumentar el número de cambios fusionados con éxito.
Primeros pasos con Ivy Tendril
¿Listo para la orquestación paralela de agentes a nivel de desarrollador?
- Explora el código: Conoce Ivy Tendril en GitHub (Código abierto).
- Consulta la documentación: Encuentra guías de integración en tendril.ivy.app.
- Agenda una sesión técnica: Contacta a renco@ivy.app para una consulta de arquitectura de 30 minutos.