Tu agente contable no es poco capaz, es poco fiable

Un agente que postea asientos en tu libro mayor y “acierta el 76% de las veces” no es 76% bueno: en contabilidad, el 24% que falla son asientos mal puestos, IVA mal liquidado y conciliaciones que cuadran de mentira — y acaban en Hacienda. Y resulta que ese 76% —el número que te da tu benchmark, la prueba estandarizada con la que se comparan los modelos— ni siquiera es el que importa.

El paper Beyond pass@1 (marzo 2026) ejecutó diez modelos open-source 23.392 veces sobre 396 tareas y midió algo que tu benchmark no: cómo cae la fiabilidad según la tarea se alarga, de un 76,3% en tareas cortas a 52,1% en las largas. Separa dos cosas que tratamos como una: capacidad (¿lo logra en un intento?) y fiabilidad (¿lo logra de forma consistente en tareas de duración real?). En un sistema que toca dinero, solo cuenta la segunda. Aquí está desempaquetado, con la acción que sale de cada hallazgo.

Capacidad no es fiabilidad: pass@1 contra pass^k

Un benchmark te dice que tu agente resuelve el 76% de las tareas. Ese número es el pass@1: le das a cada tarea un solo intento y cuentas qué porcentaje resuelve. Es la nota que reportan casi todos los benchmarks. Pero en producción tu agente contable no concilia una factura una vez — la concilia miles de veces cada cierre, y lo que importa es que salga bien siempre.

La métrica honesta para eso es el pass^k (se lee «pass a la ka»): le das k intentos a la misma tarea —pongamos 5— y solo la cuentas como éxito si la resuelve las 5 veces. Mide consistencia, no suerte. El paper la dibuja con la Reliability Decay Curve (curva de decaimiento de la fiabilidad), que cruza la duración de la tarea con ese pass^k. Y el dato incómodo es que la caída es super-lineal —no baja en línea recta, sino cada vez más rápido— porque los fallos no son independientes: están correlacionados. Un agente que se equivoca una vez en un cierre tiende a volver a equivocarse en el mismo cierre.

La acción es directa: deja de reportar pass@1 y mide pass^k con k≥3 repeticiones por tarea. Ejecuta cada eval varias veces y revisa cuántas conciliaciones salen bien en todas las repeticiones, no en una.

La duración que estima un humano no es la complejidad del agente

La fiabilidad no decae igual en todos los dominios, y ahí está lo contraintuitivo. En ingeniería de software cae casi un 50% según la tarea se alarga: el Graceful Degradation Score —una nota de 0 a 1 que mide cuánto del trabajo completó el agente, pesando más las subtareas críticas— se desploma de 0,90 a 0,44. En procesamiento de documentos apenas se mueve: de 0,74 a 0,71.

El mecanismo: la duración que un humano estima para una tarea y la complejidad que esa tarea tiene para el agente son cosas distintas. Un cierre mensual es una tarea larga y encadenada —cada paso depende del anterior, como el software de dos horas— y por eso colapsa la fiabilidad; “categoriza 500 recibos” es repetitiva y aguanta el horizonte largo sin degradarse, como el procesamiento de documentos.

Por eso un eval sobre asientos atómicos de cinco minutos no te dice nada de tu uso real. Mide la Reliability Decay Curve en el tramo de duración que de verdad ejecutas — si tu agente lleva un cierre completo, evalúalo sobre un cierre completo, no sobre un apunte suelto.

Más varianza significa más capacidad, no más ruido

El paper Beyond pass@1 rompe una intuición fuerte sobre la varianza. Los modelos frontier —los más capaces del momento— amplifican la varianza (cuánto cambia el resultado de una ejecución a otra) más de 2x al pasar de tareas cortas a largas. Esa es la idea del Variance Amplification Factor (VAF): cuántas veces más impredecibles se vuelven los resultados en tareas largas frente a cortas. Los frontier llegan a un VAF ≥ 2,37 (DeepSeek V3 2,49, MiniMax M2.5 2,60); los de gama media se quedan en ≤ 1,26 (casi sin cambio). Los dos grupos se separan limpiamente, sin solape.

Lo natural es leer “más varianza” como “más inestable, peor”. Es al revés: “high variance amplification is a capability signature, not an instability signature” (más varianza es señal de capacidad, no de inestabilidad). Solo un modelo capaz logra resultados mixtos en cierres largos; uno flojo falla de forma uniforme, sin varianza, porque ni se acerca.

Cambia cómo lees tus paneles: cuando un modelo capaz te dé varianza alta sobre un cierre largo, no la trates como ruido a suprimir. Mide ese factor y léelo como señal — un valor alto te dice que el modelo está intentando estrategias ambiciosas, no que esté roto.

El reflejo de añadir memoria empeoró 6 de 10 modelos

El reflejo de 2026 ante un agente que se pierde a mitad de un cierre es “dale memoria”. El paper probó exactamente eso: un scaffold —el andamiaje de código y prompts alrededor del modelo— con una libreta donde el agente va anotando lo que hace, frente a un ReAct pelado (el bucle básico de razonar → actuar → observar, sin memoria extra). El resultado es tajante: la memoria nunca mejoró la fiabilidad a horizonte largo y empeoró 6 de 10 modelos. Kimi K2.5 perdió 0,14 de GDS; Mistral 24B, 0,13.

El mecanismo es de presupuesto: esa libreta consume step budget —cuántas acciones puede dar el agente antes de parar— y espacio en la ventana de contexto, la memoria de trabajo limitada del modelo. Justo los dos recursos más escasos en una tarea larga. Lo que ganas en “recordar” lo pierdes en pasos y en espacio.

No es que la memoria nunca sirva — es que no es gratis ni una opción por defecto segura. Antes de desplegar un sistema de memoria en tu agente de cierre, comprueba con una prueba A/B —la misma tarea con y sin memoria, en paralelo— sobre tus propios cierres; si no lo calibras caso por caso, lo más probable es que estés pagando contexto por empeorar.

Descomponer y detectar el meltdown: las palancas reales

Dos intervenciones suben de verdad la fiabilidad en tareas largas, y ninguna es añadir memoria. La primera: descomponer. Partir una tarea larga en sub-tareas cortas y reiniciar en los límites es, según los autores, la intervención de mayor impacto — para Qwen3 30B hay 41,5 puntos entre su pass@1 corto (75,8%) y el muy largo (34,3%), y descomponer recupera buena parte de ese hueco. La contabilidad juega a tu favor aquí: ya es descomponible por cuenta, por período, por cliente — pon un checkpoint en cada tramo conciliado en vez de tratar el cierre como un único bloque.

La segunda es la paradoja más jugosa del paper: los modelos frontier se funden más, no menos — entran en bucles incoherentes y colapsan. DeepSeek V3 se funde en el 19% de las tareas muy largas (hacia el paso 17 de mediana), MiniMax en el 13%; el resto, 0-4%. No es debilidad: persiguen estrategias de muchos pasos y, cuando se enredan, sus llamadas a herramientas (leer una factura, consultar el saldo, postear un asiento…) se vuelven caóticas. Esa medida de “caos” es la entropía, y el Meltdown Onset Point —el punto donde arranca el colapso— la vigila sobre una ventana móvil de los últimos pasos.

Instrumenta las dos cosas: parte el cierre con puntos de guardado en cada cuenta o período, y mide ese desorden en las llamadas a herramientas de tu agente. Cuando salte el aviso de colapso, resetea el contexto —guarda el estado, abre una ventana nueva, continúa— antes de que el agente empiece a postear basura al libro.

Los autores lo resumen así: “task decomposition is the highest-leverage reliability intervention”. El cambio de fondo es de mentalidad: el número que persigues no es “qué porcentaje resuelve en su mejor día”, es “con qué consistencia lo resuelve cuando lo ejecuto mil veces sobre la duración real de mi cierre”.

¿Cuántas veces ejecutas el eval de tu agente sobre un cierre completo antes de dejarle postear al libro mayor?