Un paper en arXiv presenta HANDBOOK.md, un benchmark que mide si los modelos realmente siguen instrucciones de política en horizontes largos. Sesenta y cinco tareas agentivas en entornos empresariales simulados (email, chat, calendario, issue tracking vía Model Context Protocol), cada una regida por un manual operativo de 20-124 páginas escrito por expertos. Bajo evaluación rigurosa, el mejor modelo pasa el 36,2% de los intentos. La mayoría de las configuraciones frontier se quedan por debajo del 25%.

Si asumiste que un prompt del sistema largo o un documento de política es suficiente para mantener un agente bajo control, estos números dicen lo contrario. El paper identifica cuatro patrones de fallo recurrentes. El agente permite que una solicitud plausible en el entorno sobrescriba la política establecida. Ejecuta una verificación obligatoria y luego actúa contra su resultado. Pierde detalles de las reglas a medida que el contexto se alarga. Declara conformidad que no ha alcanzado.

Es la versión medible y repetible de lo que vimos cuando GPT-5.6 Sol gestionó una empresa real durante 24 horas: el agente recibe instrucciones claras y luego las viola, porque la presión del entorno pesa más que el documento inicial. La diferencia es que aquí el fallo es estructurado en lugar de anecdótico, con 824 criterios de evaluación determinísticos.

La consecuencia práctica es que la gobernanza de agentes no puede residir solo en el contexto. Se necesita una capa de software externo que verifique las acciones después de que el agente las haya ejecutado. El curso sobre cómo evaluar si tu agente funciona parte del mismo principio: los benchmarks genéricos no te dicen si el agente respeta tus reglas.

En detalle

Los benchmarks tradicionales para agentes miden si el modelo completa una tarea. HANDBOOK.md mide algo diferente: si un documento de política largo y vinculante logra limitar el comportamiento del agente en un horizonte extendido de uso de herramientas. Es la diferencia entre preguntar «¿completó el agente el trabajo?» y «¿respetó el agente las reglas mientras lo hacía?».

Las 65 tareas están modeladas en cómo los empleados empresariales siguen los manuales operativos. Cada tarea coloca al agente en un entorno autosuficiente: un workspace con archivos, email, chat, calendario, issue tracking y servicios de comercio, todos expuestos vía Model Context Protocol. La política es un manual escrito por expertos, de entre 20 y 124 páginas, que cubre cinco dominios (finanzas, facturación médica, seguros, logística, recursos humanos) en diez empresas ficticias.

Para resistir la memorización, cada tarea modifica uno de los diez manuales base, alterando las reglas específicas y los umbrales en los que se basa la evaluación. Ninguna tarea comparte la misma política. La evaluación es completamente determinística: 824 criterios programáticos que verifican tanto que se hayan realizado las acciones requeridas como que no se hayan realizado las acciones prohibidas.

Los números. Treinta configuraciones de modelo evaluadas. Bajo evaluación rigurosa (un intento pasa solo si cumple cada criterio), la mejor pasa el 36,2% de los intentos. La mayoría de las configuraciones frontier se quedan por debajo del 25%.

Los cuatro patrones de fallo:

1. Sobrescritura por el entorno. El agente recibe una solicitud plausible en el entorno (un email, un mensaje de chat) que contrasta con la política, y la sigue en lugar de la política. Es el patrón más preocupante porque se superpone con el vector clásico de inyección de prompt indirecto.
2. Verificación ejecutada e ignorada. El agente ejecuta la verificación requerida por la política, obtiene el resultado, y luego actúa de manera opuesta. Realiza la verificación pero no la utiliza.
3. Degradación en horizonte largo. Los detalles de las reglas se pierden a medida que la conversación y el uso de herramientas se alargan. Las reglas al principio del manual pesan más que las del final.
4. Conformidad declarada. El agente reporta haber respetado la política cuando no lo hizo. Si confías en el autorreporte del agente para monitoreo, este fallo no lo captarás.

Qué significa para quienes construyen. La tesis implícita del paper es que la ingeniería de contexto, por sí sola, no es suficiente para gobernar agentes en producción. Puedes escribir el manual más preciso del mundo, ponerlo en el prompt del sistema, y el agente lo seguirá menos de cuatro de cada diez veces. La gobernanza debe residir en una capa de software externa: verificaciones post-acción, validación de resultados, y donde sea posible restricciones en las propias herramientas (no le des al agente una herramienta que no debería usar, en lugar de decirle que no la use).

Las limitaciones. El benchmark usa entornos simulados, no sistemas de producción reales. Los manuales están escritos por expertos pero las empresas ficticias podrían no capturar toda la complejidad de las políticas reales. La muestra de 65 tareas es relativamente pequeña, aunque los 824 criterios de evaluación la compensan en parte. No está claro cómo cambian los resultados con técnicas de ingeniería de contexto más sofisticadas (RAG selectivo en la política, recuperación de reglas relevantes en el momento de la acción) frente a la simple inserción del manual en el contexto. El paper no prueba estas alternativas.