El foco es el nuevo cuello de botella: solo puedes ejecutar tantos agentes de IA como puedas controlar

Los agentes de IA pueden aumentar el rendimiento de implementación, especialmente cuando el trabajo se divide en tareas independientes y bien especificadas. También crean trabajo de descomposición, contexto, acceso a herramientas, revisión, integración y respuesta a incidentes. La pregunta útil no es cuántos agentes puede ejecutar una persona en teoría. Es cuánto trabajo simultáneo puede verificar e integrar el equipo dentro de su tolerancia al riesgo.

No hay un límite universal respaldado por evidencia, como dos, cinco o diez agentes por operador. La capacidad varía según el trabajo, el modelo, las herramientas, el código, las pruebas, los permisos, el operador y las consecuencias de un error. Trata la concurrencia como un parámetro operativo medido. Cuando los agentes pertenecen a personas distintas, la orquestación también se convierte en un problema de identidad, consentimiento y entrega; nuestra guía sobre comunicación entre agentes con distintos propietarios aborda ese límite de confianza.

¿Qué cambia cuando la generación se acelera?

Una generación más rápida puede desplazar la restricción sin eliminarla. Los equipos pueden dedicar menos tiempo a redactar código y más a decidir qué debe cambiar, aportar contexto, controlar herramientas, revisar el comportamiento, resolver conflictos y demostrar que el resultado cumple los requisitos. El equilibrio varía entre cambios rutinarios, arquitectura novedosa, trabajo sensible para la seguridad y decisiones de producto ambiguas.

No des por sentado que el trabajo más difícil representa un porcentaje fijo ni que un operador supera ahora a un equipo de un tamaño concreto. Mide resultados terminados y aceptados. Las líneas generadas, llamadas a herramientas o turnos de agentes son métricas de actividad y pueden aumentar mientras empeoran el tiempo de ciclo, la calidad o la mantenibilidad.

¿Cuándo ayuda el paralelismo?

Los agentes en paralelo son más prometedores cuando las subtareas son realmente independientes, las entradas y salidas son explícitas, las herramientas no compiten por un estado compartido y la integración se puede comprobar a bajo coste. Un patrón orquestador-trabajador también puede ayudar cuando las subtareas necesarias no se conocen de antemano. El relato de Anthropic sobre su propio sistema de investigación describe ventajas para consultas que exploran primero en amplitud, junto con dificultades de coordinación, evaluación, fiabilidad y coste. Los resultados de benchmark y velocidad publicados corresponden a ese sistema y esa carga de trabajo, no a un multiplicador universal. Consulta el informe técnico original del sistema de investigación multiagente.

El trabajo secuencial suele ser más seguro cuando las tareas comparten archivos, esquemas, entornos con estado, migraciones, credenciales o una decisión de arquitectura sin resolver. El paralelismo se puede introducir cuando la interfaz y las pruebas de integración sean estables.

¿Qué crea un límite de orquestación?

NIST señala que la IA generativa puede requerir distintos niveles de supervisión, configuración humano-IA, revisión, seguimiento, documentación y gestión según el contexto. Eso respalda una supervisión basada en el riesgo, no una proporción fija entre operadores y agentes. Consulta el perfil de IA generativa de NIST.

¿Cómo se mide una concurrencia segura?

Empieza con un flujo de trabajo y un conjunto representativo de tareas. Establece la referencia secuencial y aumenta la concurrencia paso a paso, manteniendo la mezcla de tareas y los criterios de aceptación tan estables como resulte práctico. Registra:

• el tiempo desde que una tarea está lista hasta que se acepta, incluida la revisión y el retrabajo;
• la antigüedad de la cola de revisión y el tiempo empleado por cada rol;
• la aceptación en el primer intento y los defectos que escapan, por gravedad;
• los conflictos de fusión, el trabajo duplicado, las reversiones y los incidentes;
• el coste de herramientas, modelos, infraestructura y personas por resultado aceptado;
• las excepciones de permisos y las afirmaciones de finalización sin respaldo;
• la carga del operador y la continuidad de los traspasos.

Deja de aumentar la concurrencia cuando el rendimiento total aceptado se estanque, las colas de revisión o integración superen el objetivo de servicio o los indicadores de riesgo crucen el umbral acordado. Repite la medición cuando cambien el modelo, las herramientas, los permisos, el código, la suite de pruebas o la mezcla de tareas.

¿Qué debe contener cada tarea delegada?

1. Objetivo: el resultado concreto y por qué importa.
2. Límites: archivos, sistemas, personas, datos y acciones dentro o fuera del alcance.
3. Entradas: fuentes autorizadas, estado actual, supuestos y dependencias.
4. Permisos: lecturas y escrituras permitidas, puntos de aprobación y acciones prohibidas.
5. Contrato de salida: artefacto, formato, responsable y cómo se comunica un fallo parcial.
6. Aceptación: pruebas, criterios de revisión, evidencia y ruta de reversión o recuperación.
7. Traspaso: estado modificado, decisiones, riesgos sin resolver y siguiente acción segura.

Una delegación clara reduce la exploración duplicada y las lagunas de cobertura. No garantiza la corrección, por lo que la evidencia de finalización debe comprobarse en el sistema real en vez de aceptar el relato del agente.

¿Cómo deben funcionar el contexto y los traspasos?

El contexto debe ser suficiente y acotado, no solo breve ni reiniciado según un temporizador. Un agente nuevo sin las restricciones actuales puede repetir errores antiguos; un contexto demasiado largo puede ocultar el requisito rector. Conserva el estado duradero en artefactos versionados cuando sea posible: planes, decisiones, interfaces, resultados de pruebas y notas de recuperación. Los resúmenes deben distinguir hechos verificados, supuestos, preguntas abiertas y trabajo aplicado realmente.

Usa transiciones de estado explícitas, como pendiente, en curso, necesita atención, completado y verificado. Un mensaje de un agente no demuestra que un cambio exista o supere las pruebas. Inspecciona el artefacto y ejecuta las comprobaciones relevantes antes de que dependa de él el trabajo posterior.

¿Pueden los agentes revisores sustituir la revisión humana?

Los agentes revisores pueden añadir una revisión independiente, poner a prueba hipótesis o examinar otra clase de riesgo. Pueden compartir puntos ciegos con el modelo productor, omitir el comportamiento del entorno u optimizar para una rúbrica incompleta. Úsalos como un control, no como prueba de que el resultado sea correcto o seguro.

La revisión humana debe ser proporcional a las consecuencias y centrarse en la intención, arquitectura, seguridad, privacidad, impacto en usuarios y excepciones que las comprobaciones automatizadas no cubren. La arquitectura de referencia multiagente de Google Cloud también destaca la supervisión humana, la autonomía definida, la observabilidad y la evaluación continua. Consulta su guía de arquitectura multiagente.

"La cantidad útil de agentes es la concurrencia que tu equipo puede verificar e integrar dentro de su tolerancia al riesgo. Mídela con resultados aceptados, no con actividad."

¿Cómo aplicamos esto en los proyectos?

Wavect no utiliza como promesa pública de entrega un valor universal de dos agentes, un máximo de cinco, un límite de revisión de cuatro horas ni un umbral fijo de experiencia. Definimos los límites de trabajo en curso según el grafo de tareas, la responsabilidad de revisión, el acceso a herramientas y datos, las pruebas, la superficie de integración y las consecuencias de un fallo. Estos límites pueden cambiar durante un proyecto cuando cambie la evidencia.

Antes de añadir trabajadores en paralelo, queremos tareas acotadas, responsabilidad aislada cuando sea práctico, una cola de revisión visible, traspasos explícitos y comprobaciones que cubran los contratos importantes. Para cambios de mayor riesgo añadimos controles de aprobación y una revisión humana más profunda. Es un enfoque operativo, no evidencia de que ningún defecto pueda escapar.

¿Qué cambia esto en la contratación?

El trabajo con agentes aumenta el valor de la descomposición, el criterio de dominio, la verificación, la seguridad, la depuración, la comunicación y las habilidades de recuperación. No vuelve irrelevante la escritura de código ni demuestra que el profesional de ingeniería más valioso sea quien pueda supervisar cinco agentes. Los roles deben evaluarse según el trabajo y los riesgos que realmente asumen.

Para el liderazgo técnico fraccional, esto puede incluir elegir dónde son apropiados los agentes, definir permisos y evidencia, establecer ciclos de evaluación y revisión, y medir si la automatización mejora la entrega aceptada. Consulta nuestro servicio de liderazgo fraccional.