Errores que viajan bien entre agentes

En el sistema de investigación, un subagente de búsqueda consulta seis fuentes y una le responde con un 403. Lo que devuelva al coordinador decide si el informe final es útil, si es engañoso o si directamente no existe.

Lo que necesita el coordinador

El coordinador decide cómo recuperarse: reintentar más tarde, probar otra fuente, seguir sin esa parte o escalar. Para eso necesita un contexto de error estructurado (structured error context):

• tipo de falla: transitoria (timeout, 503, límite de pedidos) o permanente (401, 403, 404, consulta mal armada);
• si se puede reintentar;
• qué se intentó: la fuente y la consulta exacta;
• resultados parciales: lo que sí se obtuvo de las otras cinco fuentes;
• alternativas posibles: otra fuente, otra consulta.

Un estado genérico como “search unavailable” o “Error: search failed” esconde todo eso. El coordinador no sabe si esperar, cambiar de camino o rendirse.

Vacío no es lo mismo que fallido

Caso	Qué pasó	Qué hace el coordinador
Resultado vacío válido (valid empty result)	La búsqueda corrió y no encontró nada	Lo toma como dato: no hay evidencia ahí
Fallo de acceso (access failure)	La búsqueda no pudo correr (timeout, permisos)	Decide si reintentar o buscar otra fuente

Si el subagente informa los dos igual, el coordinador va a concluir “no hay nada” cuando en realidad no se pudo mirar.

Los dos antipatrones

• Supresión silenciosa (silent suppression): la base falla y el subagente devuelve cero resultados como éxito. Una variante: procesó 320 de 500 facturas y reporta “todas procesadas”. El coordinador no tiene motivo para buscar alternativas y el informe afirma algo falso. Lo correcto es devolver el error con cuántas se procesaron y cuántas había.
• Cortar todo por una falla: uno de cinco subagentes en paralelo falla y el coordinador aborta el flujo. Las otras cuatro ramas tenían valor. Se conservan, la rama fallida se marca como faltante y la salida declara el hueco.

Recuperación local primero

No todo error tiene que subir. El subagente reintenta localmente, con espera creciente (backoff), los errores transitorios: un 503 o un límite de pedidos suelen resolverse solos. Solo propaga lo que no puede resolver, junto con lo que intentó y los resultados parciales.

Los errores permanentes no se reintentan: repetir lo mismo no arregla una clave inválida. Si el subagente de precios recibe un 401, la dimensión de precios queda marcada como no disponible, no se estiman cifras y el problema de configuración se escala a una persona.

La síntesis declara lo que falta

El informe final no puede sonar igual de seguro en todo si una parte de la evidencia nunca llegó. Se arma con notas de cobertura (coverage annotations): qué hallazgos están bien respaldados y qué temas tienen huecos porque una fuente no estuvo disponible, nombrando la fuente y el tipo de evidencia que se esperaba de ella.

Las trampas típicas

• Un mensaje de error genérico, sin tipo ni consulta.
• Devolver vacío como éxito cuando hubo una falla.
• Abortar todo el flujo por un subagente caído.
• Reintentar errores permanentes, o subir al coordinador cada error transitorio.
• Un informe que no menciona la fuente que faltó.

En el examen

Si la pregunta es qué devuelve el subagente, buscá la opción con tipo de falla, lo intentado y los resultados parciales. Si es cómo sigue el sistema, la que conserva lo que funcionó y declara el hueco. Si el error es transitorio, la que reintenta localmente antes de propagar.