Qué probaría antes de escalar esta idea.
- PREGUNTA DE PRUEBA
- ¿Diagnosticar el tipo de fallo antes de recuperar mejora la resolución y evita reintentos inútiles en errores no vistos?
- ENTRADA
- 100 trayectorias con cuatro clases de fallo y un conjunto holdout, comparando reintento genérico, playbook amplio y DARC.
- MÉTRICA
- Tasa de recuperación, pasos hasta resolver, precisión del diagnóstico y coste de retrieval.
- PARADA
- Parar si DARC no mejora 10 puntos la recuperación o si las rutas mal seleccionadas superan 5%.
Un diagnóstico incorrecto puede enviar el caso a una recuperación peor que un reintento simple; la taxonomía también necesita mantenimiento.
Esta prueba es una propuesta editorial: no es un resultado reportado por los autores.
Lo esencial antes de invertir más tiempo.
El sistema clasifica el error —acción incorrecta, esquema inválido, evidencia insuficiente, ruta API errónea, entre otros— y solo después selecciona el mecanismo de recuperación adecuado.
En ALFWorld, AppWorld y XBRL Finance, DARC mejora el rendimiento medio frente a los agentes base y los playbooks amplios mientras reduce pasos de entorno o presupuesto de retrieval, según la tarea.
Resultado reportado con fuente enlazada · 4 localizadores disponibles.Un diagnóstico incorrecto puede enviar el caso a una recuperación peor que un reintento simple; la taxonomía también necesita mantenimiento.
Introduce un equivalente agentic del manejo de excepciones semántico: diagnosticar, enrutar y recuperar con una política específica.
El sistema clasifica el error —acción incorrecta, esquema inválido, evidencia insuficiente, ruta API errónea, entre otros— y solo después selecciona el mecanismo de recuperación adecuado.
Qué sostiene esta confianza — y qué sigue sin probarse.
Juicio editorial sobre la transferibilidad de esta lectura; no mide calidad académica ni efecto local.
- FUENTE PRIMARIA
- DOCUMENTADO
Lectura primaria completa registrada sobre v1; comprobación: 2026-08-20 · método, resultado y límites revisados; fuente primaria enlazada.
- RÉPLICA LOCAL
- PENDIENTE
No se ha registrado una réplica independiente en este sitio. El código o los datos enlazados, cuando existen, no cuentan como réplica.
- LÍMITES
- DOCUMENTADO
3 límites declarados en la ficha.
- APLICABILIDAD
- ACOTADO
Hay una prueba de transferencia con entrada, métrica y parada; su resultado local todavía no se ha observado.
REGLA EDITORIALLos criterios no se promedian automáticamente. Una fuente leída, un límite claro o un protocolo propuesto no equivalen a una réplica ni a un resultado local.
Qué está reportado y qué conviene comprobar.
En ALFWorld, AppWorld y XBRL Finance, DARC mejora el rendimiento medio frente a los agentes base y los playbooks amplios mientras reduce pasos de entorno o presupuesto de retrieval, según la tarea.
baseline: agentes base y playbooks de recuperación amplios · contexto: Tres familias de tareas con políticas de recuperación seleccionadas en desarrollo y congeladas para test
Qué estudiaron y qué cambia.
La síntesis está separada de los resultados reportados y de las inferencias.Diagnosis Before Recovery cuestiona una reacción habitual de los agentes: cuando algo falla, añadir más contexto y pedir otro intento. Esa estrategia puede ser contraproducente si el error no necesita más información, sino una interfaz de reparación distinta. Un fallo de acción inválida, un procedimiento ausente y un formato estricto no deberían compartir automáticamente el mismo playbook.
DARC convierte el diagnóstico en una etapa explícita del harness. A partir de fallos del conjunto de desarrollo perfila los modos de error de cada familia de tareas, elimina de una biblioteca común las intervenciones que no son admisibles y congela una política de éxito-coste seleccionada por un verificador para usarla en despliegue. La secuencia es primero decidir qué clase de reparación tiene sentido y después gastar evidencia o contexto.
El protocolo se prueba en ALFWorld, AppWorld y XBRL Finance. Según el resumen del paper, produce un harness de validez de acciones, un fallback de recuperación procedural y una política de retrieval de precisión de formato; en cada entorno mejora el rendimiento medio frente al agente base y frente a playbooks amplios, reduciendo además pasos de entorno o presupuesto de retrieval.
La lectura importante es que la autocorrección no debe medirse por cuánto texto añade, sino por si el error se vuelve accionable y la intervención adecuada llega a tiempo. El coste está en mantener la taxonomía y el verificador: un diagnóstico equivocado puede enrutar el caso a una recuperación peor. En un producto real conviene conservar el tipo de fallo, la intervención elegida y el resultado para poder revisar esa política.
- PROBLEMA
- La reflexión genérica y el ‘inténtalo otra vez’ pueden añadir contexto irrelevante o empeorar una trayectoria cuando el fallo requiere otra corrección.
- MÉTODO
- Clasifica primero el tipo de fallo del agente y selecciona después una recuperación específica. Sustituye el reintento genérico por un bucle parecido al manejo de excepciones semántico.
- TIPO DE EVIDENCIA
- Evaluación de recuperación selectiva en tareas agentic; la aportación está en el diagnóstico y el enrutamiento, no en pedir al modelo que reflexione indefinidamente.
- LÍMITE
- Un diagnóstico incorrecto puede enviar el caso a una recuperación peor que un reintento simple; la taxonomía también necesita mantenimiento.
El sistema decide cómo reparar después de clasificar el tipo de error.
Medir qué recuperación reduce repetición, tiempo y coste; no solo si la tarea termina.
La ficha no incrusta una figura primaria porque su licencia o permiso específico no consta en el registro editorial. La fuente permanece enlazada para comprobarla.
Comprobar fuente primaria ↗ (sitio externo; abre en una pestaña nueva)La lectura también deja rastro.
Guarda una observación junto a la evidencia. Tú escribes aquí; los agentes pueden añadir notas por MCP y aparecerán identificados.
LECTURA AMPLIADAMetodología, implicaciones y preguntas para volver al paper.+
Clasifica primero el tipo de fallo del agente y selecciona después una recuperación específica. Sustituye el reintento genérico por un bucle parecido al manejo de excepciones semántico.
Introduce un equivalente agentic del manejo de excepciones semántico: diagnosticar, enrutar y recuperar con una política específica.
Un diagnóstico incorrecto puede enviar el caso a una recuperación peor que un reintento simple; la taxonomía también necesita mantenimiento.
Cómo lo llevaría a un proyecto
Crear una taxonomía pequeña de fallos observables y medir qué recuperación reduce tiempo, coste y repetición de errores.
Preguntas que conviene probar
- ¿Qué señales distinguen un error de datos de un error de herramienta?
- ¿Cuándo debe el agente parar y pedir ayuda humana?
Si tuviera que convertirlo en una prueba mañana.
Mi lectura
El bucle robusto no es pensar más: es entender el tipo de error antes de intervenir.
Esta última frase es una inferencia editorial a partir del paper y de sus posibles implicaciones; no es una afirmación de los autores.
La prueba que queda en pie.
¿Diagnosticar el tipo de fallo antes de recuperar mejora la resolución y evita reintentos inútiles en errores no vistos?