Hay un tipo concreto de PR en las notas de versión que tienes que leer dos veces, porque la primera lectura no te dice lo que realmente pasó. La entrada relevante en las notas de Hermes Agent v0.8.0 es esta:
Guía auto-optimizada de uso de herramientas para GPT/Codex — El agente diagnosticó y parchó 5 modos de fallo en las llamadas a herramientas de GPT y Codex mediante benchmarking conductual automatizado, mejorando drásticamente la fiabilidad en modelos de OpenAI. (#6120)
La primera vez que lo leí, asumí que quien lo escribió estaba siendo generoso con el significado de "auto-optimizada". La segunda vez, me di cuenta de que era literal. El agente ejecutó una suite de benchmarks contra sí mismo, detectó fallos sistemáticos en cómo los modelos de OpenAI llamaban a sus herramientas, generó orientaciones dirigidas para corregir esos fallos, y midió que las correcciones funcionaban. Los humanos aprobaron el resultado. Pero todo el paso de diagnosticar y parchear fue automatizado.
Merece la pena desgranar esto, porque es el tipo de capacidad que se cuela en una versión como una sola línea y cambia lo que las futuras versiones pueden llegar a ser.
El problema concreto
La combinación de Hermes Agent con modelos de OpenAI — GPT-5, Codex — había sido visiblemente inestable durante varias versiones. Los usuarios reportaban que Anthropic Claude funcionaba bien mientras que GPT-5 a veces producía argumentos con el formato equivocado, se saltaba pasos o perdía la cuenta de lo que ya había hecho en una secuencia multi-herramienta. No son bugs sutiles; puedes verlos ocurrir. Pero también es desesperante arreglarlos a mano, porque los modos de fallo son específicos del modelo y dependen de la redacción del prompt de maneras difíciles de intuir.
Había cinco patrones recurrentes, según la descripción del PR:
- •Saltarse las comprobaciones previas recomendadas antes de llamadas destructivas a herramientas.
- •Producir argumentos como cadenas de texto cuando el esquema esperaba objetos estructurados o números.
- •Perder la cuenta de qué llamada ya había tenido éxito dentro de una secuencia encadenada, provocando llamadas duplicadas.
- •Negarse a reintentar después de errores transitorios aunque la guía dijera que lo hiciera.
- •Derivar de "ejecutar el plan" a "replanificar el plan" cuando recibía contextos largos.
Ninguno de estos es teórico. Cada uno tenía un rastro de issues en GitHub detrás.
El loop que los arregló
El enfoque del PR #6120 tiene tres piezas móviles.
Primero, una suite automatizada de benchmarks conductuales. Un harness ejecuta al agente contra un conjunto de escenarios sintéticos diseñados para provocar cada uno de los cinco modos de fallo. Para cada escenario, el benchmark registra qué hizo el modelo, qué debería haber hecho, y si la diferencia cuenta como uno de los patrones de fallo conocidos.
Segundo, un paso de generación de orientaciones. Cuando el benchmark señala un fallo, el harness produce cadenas candidatas de orientación — instrucciones cortas y específicas del modelo que se añaden al system prompt, dirigidas exactamente al patrón que falló. No "ten más cuidado"; cosas como "antes de llamar a cualquier herramienta destructiva, primero llama a la herramienta preview correspondiente con argumentos idénticos y reporta su salida." Los candidatos se generan contra los fallos observados, no contra una rúbrica genérica.
Tercero, un paso de re-benchmarking. Cada cadena candidata se prueba contra la misma suite de escenarios. Las orientaciones que mejoran las puntuaciones se conservan. Las que empeoran otros escenarios se descartan. Las cadenas que sobreviven se agregan en el system prompt para GPT/Codex que Hermes distribuye.
Por qué esto es algo diferente
Históricamente, los prompts que vienen con un framework de agentes los escriben humanos — a veces uno, a veces un equipo pequeño — que desarrollan opiniones sobre qué funciona y qué no pasando sus propios ojos por las conversaciones. Ese proceso tiene tres problemas: no escala a muchos modelos, no se puede re-ejecutar barato cuando un modelo se actualiza, y produce prompts que codifican las supersticiones de una persona junto con su evidencia real.
Reemplazar el loop de "un humano escribe, un humano evalúa" con uno de "el benchmark escribe candidatos, el benchmark los evalúa" no es lo mismo que dejar a una IA afinarse sin supervisión. Los humanos siguen aprobando la orientación final. Pero el trabajo real de encontrar patrones y proponer correcciones ahora es medible y repetible. Cuando salga GPT-6, el mismo harness se ejecuta de nuevo. Cuando se reporte un nuevo modo de fallo, se añade un escenario y el loop se ejecuta otra vez. El coste de mantener el prompt sincronizado con el comportamiento real del modelo baja un orden de magnitud.
Los cambios relacionados en la v0.8.0 apuntan en la misma dirección. Continuación de prefill solo-pensamiento (#5931) gestiona el caso específico en que un modelo produce un bloque de razonamiento sin bloque de contenido y se queda atascado. Guía de disciplina de ejecución (#5414) añade una regla general de "no replanifiques a menos que algo haya cambiado de verdad" al system prompt. Coerción de argumentos de llamadas a herramientas (#5265) convierte silenciosamente cadenas a números y booleanos cuando el esquema JSON los espera, cubriendo exactamente el fallo de tipado de argumentos que el benchmark detectó. Estos tres PRs parecen no relacionados en un changelog. Leídos junto al PR #6120, son la superficie visible de una campaña deliberada: hacer al agente más fiable en una familia de modelos concreta midiendo, corrigiendo y volviendo a medir.
La implicación silenciosa
Lo que hace que esto se sienta como un momento bisagra, y no solo una buena versión, es que deja entrever cómo se ve la ingeniería de agentes cuando dejas de escribir prompts a mano. Un repositorio como Hermes tiene que apuntar a doce proveedores distintos y treinta modelos diferentes. Rastrear el comportamiento de cada uno manualmente ya es imposible. Si en cambio tratas "cómo deberíamos promptear al modelo X" como un problema de afinación que un harness de benchmarks resuelve, tienes un proceso que escala con el tamaño del zoo de modelos en vez de ahogarse en él.
Nada de esto fue el titular de la v0.8.0. El titular era "the intelligence release" y la demo era el cambio de modelo en vivo. Pero lo que había en silencio bajo el suelo es que Hermes ahora tiene una forma de mantener al agente inteligente en todos los modelos que soporta, sin que un humano se pase un fin de semana por modelo re-afinando el system prompt. Este tipo de capacidad tampoco aparecerá como funcionalidad en la próxima versión — aparecerá como "la fiabilidad de GPT en Hermes sigue mejorando" a lo largo de las siguientes seis versiones consecutivas.
Y si eres de los que leen notas de versión por diversión como yo, esa es la forma del asunto que vale la pena vigilar.