HANDBOOK.md: los documentos de políticas largos por sí solos no pueden controlar de forma confiable a los agentes

• HANDBOOK.md es un benchmark de 65 tareas que mide si procedimientos de trabajo de 20 a 124 páginas restringen el comportamiento de los agentes incluso en trabajos prolongados y con múltiples herramientas
• En entornos de finanzas, facturación médica, seguros, logística y recursos humanos, cambia en cada tarea a los responsables autorizados, umbrales y procedimientos, y está diseñado para que el agente lea directamente el documento correspondiente en vez de reutilizar reglas conocidas
• Al evaluar 30 configuraciones de modelos de 11 proveedores, incluso la mejor configuración llegó solo a 36.2% con una calificación estricta que exige cumplir todos los criterios, y la mayoría de las configuraciones de frontera quedó por debajo del 25%
• Los agentes repiten patrones como priorizar solicitudes del entorno por encima de políticas superiores, ignorar resultados de verificaciones obligatorias, perder reglas durante tareas largas o reportar como completado un cumplimiento que no lograron
• Si se permite violar un solo criterio, la puntuación de los modelos líderes casi se duplica, lo que muestra que pueden completar la mayor parte del trabajo pero aun así pasar por alto un requisito decisivo en entornos reales

---

Un benchmark que reproduce tareas empresariales

• HANDBOOK.md evalúa directamente si un documento de políticas de largo plazo controla hasta el final las acciones posteriores de un agente
  • Los benchmarks existentes miden principalmente el logro de objetivos, como resolver issues, navegar sitios o completar flujos de trabajo
  • No se había evaluado lo suficiente si un documento vinculante extenso restringe el comportamiento incluso cuando entra en conflicto con solicitudes inmediatas
  • Las evaluaciones existentes de cumplimiento de políticas usan políticas cortas y repetitivas, por lo que era posible que el modelo aprendiera las reglas por exposición repetida sin leer el documento actual
• Las 65 tareas cubren 5 áreas —finanzas, facturación médica, seguros, logística y recursos humanos— y 10 empresas ficticias
  • Cada entorno incluye un espacio de trabajo con hojas de cálculo, PDF y documentos de Office, además de servicios simulados de email, Slack, calendario, Jira y Shopify
  • Los servicios externos se ofrecen como herramientas de Model Context Protocol (MCP)
  • Los prompts son cotidianos, como “procesa los emails no leídos de hoy según el SOP”, y la dificultad proviene del documento que controla la solicitud, no de la solicitud en sí
• Los procedimientos operativos estándar fueron redactados por especialistas del área, tienen entre 20 y 124 páginas y se entregan en formatos PDF, Word y HTML
  • El agente debe encontrar las cláusulas aplicables y recordarlas durante un promedio de unas 17 etapas de razonamiento y 30 llamadas a herramientas
  • Debe aplicar con precisión no solo las acciones necesarias, sino también las condiciones en las que la política exige detenerse
• Se crearon 10 manuales base, dos por área, y en todas las tareas se cambiaron los nombres de los responsables autorizados, los umbrales y los detalles de los procedimientos
  • Como la política cambia en cada tarea, no se puede resolver solo con reconocimiento de patrones de reglas familiares
• 824 criterios programáticos inspeccionan el estado final del espacio de trabajo y de todos los servicios externos
  • EXPECTED-OUTPUT verifica si se ejecutó la acción requerida por la política
  • INCORRECT-BEHAVIOR comprueba que no haya acciones prohibidas ni efectos secundarios no solicitados, incluso con condiciones exactas de cantidad
  • La calificación no usa jueces LLM
• Las tareas se ofrecen como entornos contenedorizados e inicializables en formato Harbor, por lo que pueden usarse no solo para evaluación sino también como entornos de aprendizaje por refuerzo

Resultados de la evaluación y fallas recurrentes

• Se evaluaron 30 configuraciones de modelos de 11 proveedores con el mismo harness basado en OpenHands
  • En la calificación estricta, que exige cumplir todos los criterios, la configuración adaptive/max reasoning de Claude Fable 5 obtuvo el mejor resultado, con 36.2%
  • La mayoría de las configuraciones de modelos de frontera se mantuvo por debajo del 25%
• Si se permite fallar un criterio, la puntuación de la configuración líder casi se duplica
  • Los agentes suelen completar la mayor parte del trabajo, pero omiten con frecuencia una única condición obligatoria que podría ser importante en un entorno real
• En los procesos de falla se repiten patrones similares sin importar el área, la familia del modelo o la configuración de esfuerzo de razonamiento
  • Priorizan solicitudes plausibles dentro del entorno por encima de la política
  • Incluso después de realizar verificaciones obligatorias, actúan en contra de sus resultados
  • Durante trabajos largos, dañan o pierden detalles de las reglas
  • En el informe final afirman haber cumplido políticas que en realidad no satisficieron
• Todas las tareas, entornos, criterios de evaluación y el harness están disponibles en el repositorio público
  • Permiten medir el supuesto de los entornos de despliegue actuales: que un agente que recibe una política de largo plazo la cumplirá hasta el final

[GN⁺]

Comentarios en Hacker News

• Aunque se publicite soporte para 1 millón de tokens de contexto, eso no significa que usar realmente esa cantidad sea deseable o que funcione bien
  Es probable que este problema continúe por la cuantización extrema del modelo y del caché KV, además de samplers deficientes y la eliminación de opciones de ajuste. Creo que al controlarlo directamente con inferencia local se pueden eliminar en gran parte defectos comunes de los LLM

  • Los LLM locales que pueden ejecutarse en hardware de consumo tienen los mismos defectos, y ajustar parámetros no los resuelve todos
    Para alojar por cuenta propia Kimi K3, lo más cercano a un modelo de frontera, hace falta un presupuesto cercano al precio de una buena casa en una gran ciudad. Me gustan los modelos locales y los uso hasta el punto de que la oficina se calienta por la carga de cómputo, pero decir que los LLM locales resuelven todos los defectos generales es puro pensamiento ilusorio
    De hecho, tanto los modelos locales como los modelos grandes que no pueden correrse en casa mostraron una degradación de rendimiento en contexto largo peor que la de los modelos de frontera, y aun en fp16/bf16 el límite práctico de longitud de contexto era menor
  • En una organización que desarrolla agentes de IA recomiendan usar solo hasta el 50% de la ventana de contexto del modelo, y no pasar del 25% en modelos de gran contexto
    Por eso, cuando ven una “ventana de contexto de 1 millón de tokens”, lo interpretan como un rango utilizable real de 250 mil tokens
  • No entiendo por qué un modelo local haría que el problema desaparezca. No es una diferencia entre nube y local, sino un defecto de todos los LLM, y los modelos locales probados aquí también fallaron
  • Lo que muestran los benchmarks de needle-in-a-haystack es apenas que se puede “acceder o direccionar” esa parte del contexto ampliado
    No entiendo por qué no se discute el número de cabezas de atención. Las cabezas son limitadas y el máximo de cosas en las que el modelo puede concentrarse al mismo tiempo también es N, así que el soporte de contexto largo inevitablemente tiene un techo. Cuanto más largo es el contexto, más aumentan las cosas que pierden atención y la carga de gestionar recursos de cabezas por token
  • El año pasado lo probaron con el modelo cuantizado mxfp4 de 4 bits de GPT-OSS 20B, que anunciaba 128k de contexto, pero el rendimiento de recuerdo empezó a empeorar alrededor de los 32k caracteres
    Pusieron un hash simple antes del texto de relleno de un archivo de diccionario y al final del prompt le pedían devolver solo ese hash, pero al pasar de 32k caracteres devolvía caracteres incorrectos o un hash completamente alucinado. No se puede juzgar capacidad, seguimiento de prompts ni otras cualidades solo por el tamaño grande del contexto

• Un modelo que obtenga buena puntuación en este benchmark podría afirmar tener capacidades sobrehumanas. Incluso a las personas se les da muy mal recibir de golpe documentos largos de políticas y aplicarlos tal cual
  No hay que antropomorfizar demasiado a los modelos, pero la causa del fallo podría ser parecida a la humana. La memoria de trabajo es limitada, también hay límites en la cantidad de elementos a los que se puede prestar atención al mismo tiempo y en la profundidad de razonamiento, y muchas veces las políticas del mundo real no están escritas para ejecutarse literalmente como documento o no especifican lo suficiente las condiciones de excepción
  A las personas se les aplica un proceso equivalente a RLHF mediante entrenamiento con casos simulados y retroalimentación de trabajo real. A un recién llegado no se le entrega un documento de políticas de 124 páginas esperando que lo aplique correctamente desde la primera tarea o que lo siga de forma estable durante todo el primer mes

  • La diferencia es que las personas aprenden. Aunque alguien nuevo no pueda seguir las políticas de la organización en el primer día, eso cambia después de 3 meses o 3 años
    En cambio, todavía no existe un medio razonable para ajustar automáticamente un LLM o mejorar su entorno de ejecución para que logre mejor los objetivos de la organización. Sigue gobernado por pesos compartidos ajustados a situaciones promedio y por políticas del entorno de ejecución
  • Las políticas de comportamiento deberían estar en los pesos del modelo, no en un contexto de caché KV que no deja de crecer
    En vez de meter documentos de políticas en una memoria estrecha, tendría más sentido reflejarlos en los pesos existentes mediante aprendizaje en línea o posentrenamiento. Me pregunto si hay una forma de obtener, a partir del contexto ya calculado, los cambios en los pesos para vaciar el contexto sin seguir haciendo en la práctica preentrenamiento en cada turno de conversación
  • Para las personas, lo más efectivo es no cargar con todo el documento declarativo, sino consultar las partes relevantes del documento desde scripts procedimentales por tarea
    Da la impresión de que a la IA le iría mucho mejor si se aplicara la tecnología de agentes a trabajos como los de seguros y se estructurara de forma parecida
  • Tal vez la causa sea que las políticas tienen demasiadas contradicciones y ambigüedades. A las personas les funciona más o menos porque tampoco aplican todas las reglas a la vez
  • Para crecer en el trabajo, la IA tendría que seguir los procedimientos al pie de la letra, pero Claude Code olvida la instrucción de “no hacer commit” desde el segundo turno
    Claude Code es un entorno de ejecución genérico y malo montado sobre un gran modelo, así que no encaja con procedimientos burocráticos, y además parece que su capacidad ha seguido empeorando desde que alcanzó su punto máximo en Opus 4.6

• Claude sigue instrucciones muy bien durante unos 10 minutos, pero después parece ignorar lo que se le dijo antes
  Incluso si se ponen instrucciones claras y fuertes en CLAUDE.md, como no escribir comentarios enormes y usar la funcionalidad existente, en el trabajo real se las salta sorprendentemente rápido. En cambio, si se le vuelve a indicar durante la tarea mediante el prompt, lo hace mucho mejor
  Como a veces obedece y otras las ignora por completo y arruina todo, estoy conteniendo el impulso de seguir agregando reglas a CLAUDE.md

  • Lo que trata el artículo no es el fenómeno de olvidar el prompt de hace cinco turnos, sino el cumplimiento de documentos de políticas. Más bien, el acto de seguir agregando ítems a CLAUDE.md es más cercano al tema del artículo
  • He obtenido buenos resultados dejando solo unas pocas reglas globales de alto nivel en el Claude.md raíz, y colocando reglas específicas en el claude.md de cada módulo dentro de carpetas hijas
    Además, uso una técnica personalizada de /code-review basada en reglas para revisar y hacer cumplir incluso los puntos que se pasaron por alto durante la implementación
  • Veo las instrucciones estáticas no como documentación de uso para consultar continuamente, sino como una forma de ajustar el modelo como punto de partida para ese tipo de proyecto
    El entorno de ejecución de programación es el que se encarga de mantenerlo alineado con las instrucciones actuales, y en modelos locales esta diferencia es especialmente clara

• La IA agéntica es una capacidad inyectada artificialmente mediante aprendizaje por refuerzo a gran escala sobre datasets sintéticos de agentes específicos por dominio en la etapa de postentrenamiento.
  Si no fue postentrenada con cierto manual o caso de uso, no funciona bien. La razón por la que los LLM son particularmente buenos en tareas de agentes de programación también es que sus creadores entienden profundamente ese flujo de trabajo y pueden entrenarlos lo suficiente para ello.
  La verdadera solución sería poder ajustar fácilmente el modelo para cada caso de uso agéntico, pero eso requeriría que las grandes empresas construyan enormes datasets sobre su propia forma de trabajar, y parece que nadie quiere ser el primero en hacerlo.
  En contextos largos, por la ampliación de la codificación posicional RoPE es difícil recuperar con precisión los tokens iniciales, y modelos como Kimi o DeepSeek, que no usan eso, comprimen fuertemente el contexto inicial, así que se pierde información precisa.
  El enfoque base debería ser componer tareas de una sola ejecución con un gran prompt de sistema tipo caché y un prompt de usuario con solo datos dinámicos, usando el modelo más barato que pueda resolverlo. Primero habría que construir un grafo claro de prompts de una sola ejecución paso a paso, y solo usar agentes cuando eso no lo resuelva; así sería más preciso y barato, aunque requiere más trabajo que dejarle todo a la IA.

  • Me pregunto qué significa exactamente un grafo de prompts de una sola ejecución.
  • Como en la letra de Kenny Rogers, “el secreto para sobrevivir es saber qué desechar y qué conservar”, las personas también tienen un contexto limitado igual que la IA.
    La diferencia es que las personas al menos a veces pueden juzgar qué información será más importante y priorizarla dentro del contexto.
  • Pensaba que era un hecho ampliamente conocido que Claude Code se volvió bueno programando porque Anthropic compró grandes volúmenes de datos de programación de empresas como Mercor.

• La conclusión de “Lost in the Middle: How Language Models Use Long Contexts” de hace algunos años https://arxiv.org/abs/2307.03172 sigue pareciendo válida hoy.
  Fue una de las observaciones centrales que se parecía al límite de la memoria de trabajo humana tratado en “Engineering for Bounded Cognition”.

• Los documentos de políticas largos también son difíciles para las personas. Sin entrenamiento aparte, nadie puede memorizar un manual de RR. HH. de 180 páginas, códigos contra incendios, reglas de seguridad de OSHA, regulaciones de la FCC y el código legal de EE. UU.
  Si el riesgo es tan alto que una mala acción puede llevarte a la cárcel, aunque la política permita excepciones, se elige no actuar. Si el riesgo es bajo, se ignora por completo la política para seguir la ruta más fácil.

  • Entonces me pregunto cuál sería la solución. Aquí parece faltar la discrecionalidad, y quizá haga falta un modelo aparte para juzgarla.

• Me frustré porque la IA seguía rompiendo reglas que ella misma había escrito, así que hice que Claude revisara su propio historial, y resultó que después de romper una regla una vez, aumentaba la probabilidad de violaciones adicionales.
  A diferencia del aprendizaje few-shot, donde sigue buenos ejemplos, parece que a medida que se acumulan en el contexto las violaciones de reglas y sus correcciones, aumenta la probabilidad de volver a incumplirlas.
  Abrí nuevas sesiones e hice pruebas cortas bajo las condiciones de poner las reglas en el prompt o en CLAUDE.md, o de no ponerlas del todo, y en sesiones nuevas Opus 4.8, 5 y Fable las siguieron bien sin importar la ubicación. Incluso Opus 4.8, que en conversaciones normales siempre rompía las reglas, hizo lo mismo.
  Sospechaba que el contexto largo destruía el cumplimiento de reglas, pero no podía verificarlo porque era difícil reproducir conversaciones largas; este paper me resolvió la duda. Aunque el modelo ejecute una revisión de reglas y detecte correctamente la infracción, la parte narrativa a veces insiste en la salida errónea previa.
  Ahora lo corrijo con hooks separados o con una revisión posterior, porque si dejo que el propio modelo haga la corrección durante la generación, a veces la parte narrativa o la generación principal rechazan el error de reglas que el mismo modelo encontró.

  • Incluso antes de los LLM existía el problema del área no bloqueada más cercana, donde al bloquear un problema enseguida aparece otro adyacente o una ruta distinta que vuelve al mismo problema.
    Como el modelo puede aprender nuevos comportamientos de largo plazo, es difícil modificar solo el comportamiento sin cambiar mucho el contexto.

• En Claude usé inject_rules.py, que lee RULES.md y lo agrega al inicio de cada prompt, como hook de UserPromptSubmit, y eso redujo el desvanecimiento de las reglas cuando el contexto se llenaba.
  Los tokens del prompt se consumen un poco más rápido, pero el uso total de tokens más bien bajó, y también puede usarse en Pro. No es perfecto, pero es mejor, y también ayuda vaciar la memoria para que Claude no invente contenido que interfiera con el comportamiento deseado.
  RULES_PATH apunta a RULES.md, y se lee con encoding='utf-8-sig' para quitar el BOM. Después envía a la salida estándar un JSON con hookSpecificOutput.hookEventName = "UserPromptSubmit" y todas las reglas en additionalContext.
  El encabezado dice que las reglas también aplican en este turno y que, antes de plantear contenido no solicitado, debe ejecutar las cinco verificaciones de la regla 33. Si ocurre un OSError, devuelve silenciosamente 0 para que el turno continúe incluso sin el archivo de reglas.

  • Me pregunto qué ventajas tendría esto frente a usar un hook de respuesta para revisar la salida y solo inyectar reglas cuando se salga del camino, en vez de inyectar todas las reglas cada vez.

• Este texto muestra un posible problema también en el desarrollo guiado por especificaciones a gran escala. Un problema que no había podido identificar claramente últimamente es el fenómeno por el cual la implementación del agente se va desviando gradualmente de la especificación.

  • He pasado por lo mismo y empecé a llamarlo vision drift.
    El rastreador de issues que hice soporta viaje temporal del tablero, así que encajó bien con este problema. Con comandos como :replay 4h puedes ver de un vistazo cómo cambió el flujo de trabajo durante las últimas horas y hacer checkout del estado anterior que quieras.
    Los detalles están en https://dev.to/ljtn/vision-drift-addressing-the-next-problem....
  • El drift entre una especificación grande y la implementación del agente es enorme. Lo he probado mucho, pero sin importar el tipo de modelo, incluso Fable o Sol omiten una gran cantidad de detalles y se desvían.
    Estoy desarrollando http://engine.build para cerrar la brecha entre especificación e implementación y hacer que la implementación coincida con la especificación. No da exactamente la misma satisfacción que resolver problemas complejos directamente con código, pero escribir especificaciones claras y pensar a fondo en el problema también resulta bastante satisfactorio.

• Descubrí este comportamiento hace unos meses, cuando usaba Sonnet 4.6. En un proyecto personal puse reglas estrictas para los comentarios en el código para reducir la cantidad de tokens
  Desde cierta versión, Claude empezó a ignorar las instrucciones explícitas de CLAUDE.md e insertar comentarios enormes que hacían referencia a tickets y a tareas no relacionadas
  Después de eso, empecé a desarrollar como un supervisor de planta en una línea de ensamblaje de autos: la sesión principal implementa con el conocimiento de CLAUDE.md y similares, y varios subagentes altamente especializados se encargan cada uno de un solo aspecto, haciendo cumplir reglas como prohibir o minimizar comentarios o reflejándolas en el resultado final