En corto, para quien decide
La mayoría de los agentes desplegados trabaja con poca autonomía: en una encuesta académica reciente, el 68% de quienes respondieron ejecuta como máximo 10 pasos por subtarea antes de que intervenga una persona.
Añadir agentes puede empeorar el resultado. En tareas secuenciales, todas las variantes multiagente probadas por Google y el MIT degradaron el rendimiento entre un 39% y un 70%.
La inyección de instrucciones sigue sin defensa completa. El sistema debe diseñarse suponiendo que el modelo acabará engañado alguna vez, con los permisos fuera de su alcance.
Las tres decisiones previas al desarrollo son qué puede tocar el agente, qué puede hacer sin aprobación y con qué conjunto de pruebas propio se va a medir.
El agente real es más modesto que el de la presentación
El mejor retrato disponible de lo que hay desplegado es el estudio de Pan y coautores, de UC Berkeley, Intesa Sanpaolo, UIUC, Stanford e IBM, publicado en diciembre de 2025. Reúne 306 respuestas válidas, 86 de ellas sobre agentes en producción o en piloto, y 20 casos analizados en profundidad. El 68% de los 60 que respondieron a esa pregunta ejecuta como máximo 10 pasos por subtarea antes de una intervención humana. El 74% de los 31 que informaron de cómo evalúan recurre a la evaluación humana. En los casos estudiados a fondo, el 85% se construyó a medida con llamadas directas a la API, aunque en la encuesta el 60,7% de los agentes emplea frameworks de terceros. Los autores advierten de un sesgo hacia los despliegues exitosos, de modo que la foto completa probablemente sea aún más sobria.
Esa sobriedad tiene una explicación aritmética. Si cada paso acierta con una probabilidad fija y los errores son independientes, la probabilidad de completar la cadena cae de forma geométrica.
| Pasos | Acierto por paso 99% | Acierto por paso 95% |
|---|---|---|
| 5 | 95,1% | 77,4% |
| 10 | 90,4% | 59,9% |
| 20 | 81,8% | 35,8% |
| 50 | 60,5% | 7,7% |
La independencia es una simplificación, porque un agente puede corregirse y también puede arrastrar un error durante varios pasos. Aun así, un trabajo sobre 10.664 trayectorias de 9 modelos encontró decaimiento geométrico en 28 de 36 combinaciones de modelo y tarea, y vinculó la degradación al número de pasos más que a la longitud del contexto. Se trata de un preprint de autor único con tareas sintéticas, así que sirve como indicio. La consecuencia de diseño se sostiene con o sin él: cada paso que se elimina vale más que una mejora marginal del modelo.
Empezar por el flujo más pequeño que resuelva el problema
La distinción de Anthropic se ha convertido en vocabulario común. En un workflow, el modelo y las herramientas siguen rutas definidas en código. En un agente, el modelo decide el proceso y el uso de herramientas. La recomendación de la propia guía es empezar por lo más simple, porque la autonomía se paga en latencia, coste y errores acumulados.
La literatura sobre sistemas multiagente es menos concluyente de lo que sugiere el marketing. El estudio de Google Research, Google DeepMind y MIT comparó 180 configuraciones con presupuesto de tokens igualado. El error se amplificó 17,2 veces con agentes independientes y 4,4 veces con coordinación centralizada. La coordinación central ganó un 80,8% en razonamiento financiero paralelizable, y todas las variantes multiagente perdieron entre un 39% y un 70% en tareas secuenciales. Los autores limitan la validez a los dominios probados.
Por el lado de los fabricantes, Anthropic informa de que sus agentes consumen unas 4 veces los tokens de un chat y sus sistemas multiagente unas 15 veces, con una mejora del 90,2% en una evaluación interna cuyos detalles no se publican. Cognition, autora del conocido alegato contra los multiagente, matizó su postura en abril de 2026: funcionan los patrones en los que varios agentes aportan criterio y uno solo escribe.
| Forma del trabajo | Patrón de partida | Motivo |
|---|---|---|
| Pasos conocidos y auditables | Workflow determinista con llamadas puntuales al modelo | Máxima trazabilidad y menor coste |
| Subtareas independientes y paralelizables | Orquestador con trabajadores aislados | La coordinación central contiene mejor el error |
| Razonamiento secuencial con estado compartido | Un solo agente | Dividir degrada el resultado |
| Varias opiniones sobre un mismo cambio | Revisores múltiples, un único escritor | Evita escrituras contradictorias |
Protocolos: útiles como transporte, insuficientes como seguridad
La versión 2026-07-28 de MCP eliminó el handshake initialize y el Mcp-Session-Id para que el protocolo pase a ser sin estado, sustituyó las peticiones iniciadas por el servidor por Multi Round-Trip Requests y sacó Tasks a una extensión. Para quien opera detrás de balanceadores es una buena noticia. La cifra de casi 500 millones de descargas mensuales de los SDK de nivel 1 mide descargas, y una descarga dice poco sobre despliegues.
La hoja de ruta del propio proyecto reconoce el problema principal: la autorización está pensada para una persona que aprueba en un navegador, y eso encaja mal con agentes que trabajan con el usuario ausente o que delegan en subagentes. A2A alcanzó su versión 1.0 en marzo de 2026, con Agent Cards firmadas y soporte multi-tenant. Sus más de 150 organizaciones son una cifra declarada por la Linux Foundation, y no se ha localizado una medición independiente de uso en producción.
El ecosistema tiene margen de mejora. Una auditoría dinámica de 414 servidores MCP expuestos halló que el 91,8% carecía de autenticación OAuth, con 68 vulnerabilidades registradas. El trabajo es de autor único y no todo servidor sin OAuth expone datos sensibles. Otro estudio, de la Universidad de Fudan, midió 8 escáneres de seguridad con una precisión media del 45,53% y una tasa media de detección de servidores con CVE conocidos del 24,17%. Un análisis automático limpio aporta, por tanto, poca garantía.
Evaluar con pruebas propias, porque las públicas ya no bastan
Los benchmarks públicos atraviesan una crisis documentada. OpenAI auditó los 138 problemas de SWE-bench Verified que o3 no resolvía de forma consistente y encontró defectos materiales en el 59,4% de ellos, además de señales de contaminación, y dejó de publicar esa métrica. El grupo RDI de UC Berkeley construyó un agente que generaba exploits para cada benchmark y, sin resolver ninguna tarea, obtuvo puntuaciones cercanas al 100% en 7 de 8.
Una segunda línea de trabajo separa capacidad de fiabilidad. El equipo de Princeton de Rabanser, Kapoor y Narayanan observa que, en una escala de 0 a 1, la precisión sube unos 0,21 puntos al año y la fiabilidad solo entre 0,03 y 0,10. Al repetir cada tarea 5 veces, la consistencia del resultado osciló aproximadamente entre 0,31 y 0,77. Un proceso de negocio necesita justamente esa repetibilidad, que apenas aparece en los rankings.
Las métricas agregadas también dependen de cómo se puntúen los casos dudosos. METR estimó el horizonte temporal de GPT-5.6 Sol en 11,3 horas contando las trampas como fallo, 71 horas si se descartan y más de 270 si se cuentan como éxito. El propio METR avisa de que ninguna de esas cifras es una medición robusta.
Un programa de evaluación razonable tiene cuatro piezas:
Conjunto inicial de 20 a 50 tareas extraídas de fallos reales, la cantidad que sugiere Anthropic para arrancar, separado en pruebas de capacidad y de regresión.
Lectura periódica de transcripciones, porque es la única forma de distinguir un error del agente de un error del evaluador.
Repetición de cada caso varias veces, registrando la dispersión además de la media.
Trazas estructuradas desde el primer día. Las convenciones de spans de agente de OpenTelemetry siguen en estado Development, así que conviene versionar el esquema propio y prever su migración.
Una advertencia sobre la deriva. Circula mucho un trabajo con caídas de éxito del 87,3% al 50,6%, pero esas cifras son simuladas. No se ha encontrado un estudio primario sólido que mida la deriva de agentes en producción. Hasta que exista, cada organización dependerá de su propia telemetría.
Cómo se rompen
MAST analizó 1.642 trazas de 7 frameworks e identificó 14 modos de fallo agrupados en 3 categorías, con tasas de fallo entre el 41% y el 86,7% sobre benchmarks no comparables entre sí. En horizontes largos, un estudio de más de 3.100 trayectorias atribuyó el 72,5% de los fallos al proceso y el 27,5% al diseño, con planificación y memoria como causas dominantes a medida que crece el horizonte. Los bucles infinitos también aparecen en código real: un análisis estático de 6.549 repositorios confirmó 68 casos en 47 proyectos.
Las contramedidas son ingeniería convencional aplicada a un componente no determinista: presupuestos máximos de pasos, tokens y tiempo; llamadas a herramientas idempotentes con clave de deduplicación; puntos de control para reanudar sin repetir efectos; y una salida explícita hacia una persona cuando se agota el presupuesto.
Seguridad: el control debe vivir fuera del modelo
El NCSC británico describe el modelo de lenguaje como un delegado confundible por naturaleza y admite que la inyección de instrucciones quizá nunca se mitigue del todo. OWASP expresa la misma duda sobre la existencia de una prevención infalible. La evidencia empírica va en esa dirección: Nasr, Carlini y coautores superaron 12 defensas publicadas contra jailbreaks e inyección de instrucciones con ataques adaptativos, con más del 90% de éxito en la mayoría, cuando buena parte declaraba tasas cercanas a cero.
El número importante es el acumulado. El CAISI de NIST, junto al AISI británico, elevó el éxito del mejor ataque del 11% al 81% mediante red teaming, y repetir 25 veces cada una de 5 tareas de inyección subió su media del 57% al 80%, sobre un modelo ya antiguo. Una competición pública con 464 participantes y unos 272.000 intentos obtuvo entre un 0,5% y un 8,5% de éxito por intento, y todos los modelos resultaron vulnerables. Una tasa baja por intento se vuelve alta cuando el atacante puede insistir. EchoLeak demostró el caso real: un solo correo bastaba para exfiltrar datos de Microsoft 365 Copilot sin que el usuario hiciera clic.
Dos reglas prácticas ayudan a razonar. La lethal trifecta de Simon Willison señala la combinación peligrosa: datos privados, contenido no confiable y capacidad de comunicación externa. La Rule of Two de Meta limita cada sesión a 2 de 3 propiedades de riesgo y exige supervisión si concurren las 3, aunque tras las objeciones de Willison Meta dejó de llamar "seguras" a esas parejas y pasó a hablar de menor riesgo.
La traducción a arquitectura sigue el LLM06:2025 de OWASP: la autorización reside en el sistema de destino y nunca en el modelo. En MCP, la guía oficial prohíbe el token passthrough y obliga a los proxies a aplicar consentimiento por cliente, para evitar el confused deputy. Las aproximaciones por diseño ya tienen resultados medibles: CaMeL separa flujo de control y flujo de datos, resuelve el 77% de las tareas de AgentDojo con garantías frente al 84% sin defensa, y consume unas 2,8 veces los tokens. Sus autores reconocen que el problema sigue abierto.
La aprobación humana también se degrada
Poner una persona en cada paso parece prudente y dura poco. Anthropic informa de que los usuarios de su herramienta de programación aprueban el 93% de los avisos de permiso, un dato de fabricante que apunta a la fatiga de consentimiento. La síntesis de NIST sobre más de 600 respuestas relativos a la identidad de agentes recoge la preferencia por autorización continua y por tarea, aplicación determinista y supervisión humana reservada a las acciones de alto impacto.
Conviene clasificar cada herramienta por reversibilidad y alcance, y gastar la atención humana donde el daño no se pueda deshacer: pagos, envíos externos, borrados, cambios de permisos. Si se aprueba todo, la firma deja de aportar control.
Lista para el equipo que lo construye
Inventario de herramientas con propietario, reversibilidad, alcance de datos y credencial propia de mínimo privilegio.
Identidad del usuario propagada hasta el sistema de destino, con tokens de audiencia restringida.
Marcado de procedencia del contenido, para que un dato no confiable no pueda decidir la siguiente acción privilegiada.
Egreso de red restringido por lista de permitidos y ejecución de código en entorno aislado.
Límites de pasos, tokens y tiempo, con parada y escalado a una persona.
Herramientas idempotentes y puntos de control recuperables.
Pruebas de regresión y de inyección en integración continua, con repetición de casos.
Trazas de cada decisión, herramienta invocada, argumentos y resultado, conservadas según la política del dato.
Antes de ampliar la autonomía de un agente, conviene exigirle lo mismo que a cualquier sistema que escribe en producción. Ese examen forma parte del diagnóstico técnico con el que allrework empieza cada proyecto.
Datos consultados a 8 de noviembre de 2026. Las cifras atribuidas a fabricantes proceden de sus propias publicaciones y no cuentan con verificación independiente.
