Un agente de 30 pasos con un 1% de fallos se cae en una de cada cuatro tareas: cómo llevarlo a producción

En la demo, el agente se comporta de maravilla: 10 pasos de 10 y todo el mundo contento. En producción ejecuta miles de tareas y todo aflora a la vez: el modelo confunde herramientas, el contexto está lleno de basura, la búsqueda no encuentra lo que debe y el proceso se cae a mitad de la tarea. La segunda parte de la serie en Habr está dedicada a qué hacer con todo esto. Repasamos lo esencial.

La aritmética por la que la demo no equivale a producción

Imagine una tarea de 30 pasos en la que cada paso falla una vez de cada cien: la red parpadea o la API responde «sobrecargada». En ese caso, la tarea llegará al final en el 74% de los casos. Una de cada cuatro fallará. Con un 3% de fallos por paso, solo llegará el 40%. El autor advierte con honestidad de que es un cálculo teórico: supone fallos temporales e independientes. Si el proveedor cae por completo, tres reintentos rápidos no ayudan; hace falta una pausa larga o un proveedor de respaldo.

Herramientas y contexto: menos, pero más precisas

El modelo conoce de una herramienta solo su nombre, su descripción, el esquema de parámetros y lo que devolvió. Por eso una herramienta para un agente se escribe de forma distinta que una API para un programador. No cree una herramienta por cada endpoint: en lugar de list_users, list_events y create_event, es mejor una sola schedule_event que encuentre el hueco y cree la reunión por sí misma.

Haga respuestas cortas y con nombres comprensibles en lugar de uuid. En un ejemplo de Anthropic, el modo breve de una herramienta de Slack devolvió 72 tokens en lugar de 206. Escriba los errores pensando en el modelo: una frase como «la fecha debe tener el formato 2026-11-09, llegó 09.

11» se corrige sola en el siguiente turno, mientras que un código 400 a secas no dice nada.

Al contexto se aplica el mismo principio: mantener el conjunto más pequeño de tokens que ayude a resolver la tarea. Cargue los datos sobre la marcha y deje en el prompt solo enlaces. Comprima el historial, pero conserve las decisiones y los bugs abiertos. Delegue las partes pesadas en subagentes, que devolverán un resumen de 1–2 mil tokens.

RAG: primero decida si lo necesita

Si la base de conocimiento tiene menos de 200 mil tokens (unas 500 páginas), se puede meter entera en el prompt y cachearla. Entonces no hace falta búsqueda. Si la base es mayor, según las mediciones de Anthropic funciona una combinación: búsqueda semántica más búsqueda por palabras (BM25), un contexto de 50–100 tokens añadido a cada fragmento antes de indexar y reranking.

La tasa de fallos, es decir, los casos en que el fragmento necesario no entró entre los 20 mejores, bajó del 5,7% al 1,9%. Evalúe la búsqueda por separado de la respuesta: prepare preguntas con la ubicación de la respuesta conocida y mida con qué frecuencia el fragmento aparece en los resultados. De lo contrario, no se sabe si falla la búsqueda o el modelo.

El bucle bajo control: turnos, dinero, reintentos

Empiece por una cadena, no por un agente: el agente paga su libertad con latencia y dinero. Si aun así lo necesita, fije tres límites: de turnos, de presupuesto en dólares y un timeout para toda la tarea. El coste crece más rápido que el número de turnos, porque cada turno vuelve a leer el historial. Según el cálculo del autor, una tarea de 30 turnos cuesta $0,51, mientras que un agente atascado en 100 turnos sale por $2,68: hay 3,3 veces más turnos y 5,3 veces más gasto. Decida de antemano adónde va la tarea cuando se agotan los intentos: a un modelo de respaldo, a una cadena simple o a una persona.

Solo conviene reintentar los fallos temporales, como 429, 500, 504 y 529, con una pausa creciente. La sutileza es que el 429 también aparece cuando se agota el límite mensual de gasto (código enforced_spend_limit_reached). En ese caso el reintento no sirve de nada, y un retry que no distinga los casos estará golpeando la API durante horas.

Lo peligroso no es la caída, sino la repetición

Imagine una herramienta send_email: el correo salió, pero la respuesta se perdió, el envoltorio repitió la llamada y el cliente recibió dos correos. Con charge_card ocurre lo mismo: el dinero se cobra dos veces. La solución es conocida desde Stripe: la clave de idempotencia.

El servidor recuerda la respuesta a la primera solicitud con esa clave y, ante la repetición, devuelve la respuesta guardada. El agente ya tiene una clave así: es el id de la llamada a la herramienta, que no cambia al reintentar. Páselo al sistema externo.

Pero si el proceso se cae entre el envío y el registro del resultado, una comprobación local no detectará el duplicado. Las acciones que el sistema externo no soporta con clave, así como el envío, el pago y el borrado, deben pasar a una persona para su confirmación.

Si se cae el propio proceso, no hay nada que reintentar: el historial y los resultados estaban en memoria. Aquí hace falta una ejecución duradera, por ejemplo Temporal. El bucle del agente vive en un workflow, las llamadas al modelo y a las herramientas se convierten en activities, los eventos se escriben en un registro y otro worker continúa desde el punto de la caída. La condición: el código del workflow debe ser determinista y las activities, idempotentes. El precio de no hacerlo: una caída en el turno 25 con reinicio desde cero cuesta $0,93 en lugar de $0,51, es decir, un +81%.

Qué hacer en la práctica

Reduzca el conjunto de herramientas y hágalas más amplias. Fije un límite de turnos, un presupuesto y un plan B. Compruebe que cada acción con consecuencias sea idempotente o pase por una confirmación. Calcule el coste de una tarea completada con éxito, no de una sola llamada, y ejecute las pruebas con cada cambio del prompt.

Limitaciones: todos los cálculos de coste son teóricos y están ligados al escenario de la primera parte de la serie, y parte de las cifras sobre límites y errores depende de la documentación en una fecha concreta. El fragmento sobre observabilidad y protección está cortado en el texto disponible, pero el consejo general es claro: no dar al agente a la vez datos privados, contenido no confiable y salida al exterior.