Tu agente de IA no sabe cuándo parar y eso te va a costar caro
La promesa de los agentes de IA es real. El presupuesto que nadie te dijo que necesitabas, también.
Hay una conversación que casi nadie está teniendo en los equipos que están implementando agentes de IA hoy.
No es sobre modelos. No es sobre arquitecturas RAG. No es sobre si usar LangChain o construir desde cero.
Es sobre esto: ¿quién le dijo a tu agente cuándo terminar?
Porque si nadie lo hizo, estás tirando dinero a la basura en este momento y probablemente no lo sabes.
El problema que los demos no muestran
Cuando ves una demo de un agente RAG funcionando, ves el camino feliz: el agente recibe la pregunta, busca información relevante, razona, responde. Cuatro pasos. Limpio. Elegante.
Lo que no ves es lo que pasa cuando el agente no encuentra exactamente lo que busca.
O cuando los datos recuperados se contradicen entre sí.
O cuando la API que consulta devuelve un error.
En esos casos, el agente razonablemente decide intentarlo de nuevo. Y otra vez. Y otra vez. Porque nadie le dijo que parar también es una opción válida.
Tres comportamientos que drenan tu cuenta
Después de trabajar con implementaciones reales de agentes, hay tres patrones que aparecen una y otra vez:
El perfeccionista. El agente genera una respuesta, la evalúa internamente, decide que “podría ser más completa”, vuelve a recuperar información, regenera, reevalúa. El ciclo puede repetirse diez, veinte veces. No porque la respuesta sea mala sino porque el criterio de “suficientemente bueno” nunca fue definido.
El indeciso. Cuando los chunks recuperados tienen información contradictoria o ambigua, el agente lanza más queries para “confirmar”. Cada query nueva abre más ambigüedad. Es un loop que se alimenta a sí mismo.
El optimista con herramientas. El agente llama una API externa, recibe un error 503, lo intenta de nuevo. Y de nuevo. Sin límite de reintentos, sin backoff, sin criterio de abandono. Si la API está caída durante una hora, el agente puede haber hecho miles de intentos antes de que alguien lo note.
Los números que importan
Trabajando con modelos como Claude Sonnet, cada conversación tiene un costo aproximado en tokens. Con un agente bien controlado que resuelve en 4 pasos, estamos hablando de alrededor de $0.024 por conversación.
Un agente con loops moderados, unos 15 pasos, llega a $0.09.
Un agente en loop severo, 50 pasos o más, puede superar $0.30 por conversación. Y eso asumiendo que termina solo.
Parece poco. Haz la multiplicación con mil conversaciones al día.
| Escenario | Pasos | Costo/conversación | Costo Mensual (1K conv/día) |
|---|---|---|---|
| Agente controlado | 4 | $0.024 | ~$720 |
| Loop moderado | 15 | $0.09 | ~$2,700 |
| Loop severo | 50+ | $0.30+ | $9,000+ |
La diferencia entre un agente bien diseñado y uno mal diseñado no es técnica. Es de $8,000 al mes.
La raíz del problema: confundimos capacidad con diseño
Los LLMs modernos son impresionantemente capaces de razonar, buscar y sintetizar. Esa capacidad nos lleva a una trampa: asumimos que el agente “sabrá” cuándo parar porque es inteligente.
No funciona así.
El agente optimiza para completar la tarea según las instrucciones que le diste. Si no le dijiste explícitamente qué hacer cuando no encuentra la información perfecta, va a seguir buscando. Si no le pusiste un límite de intentos, va a seguir intentando. No porque sea defectuoso — sino porque está haciendo exactamente lo que le pediste que hiciera: resolver el problema.
El problema es que nunca le diste permiso para decir “no sé” o “no encontré suficiente información”.
Lo que sí funciona
Esto no es un problema irresoluble. Es un problema de diseño que tiene soluciones concretas:
En el system prompt: Define explícitamente el comportamiento de fallback. “Si después de 3 búsquedas no tienes información suficiente para responder con confianza, responde con lo que tienes e indica qué información no encontraste.” Esa instrucción sola elimina el loop del perfeccionista.
En el orquestador: max_iterations debe ser un parámetro de primera clase, no un comentario en el código que dice “TODO: agregar límite”. Define un timeout duro. Define un presupuesto de tokens por conversación.
En el monitoreo: Si no estás logueando cuántos pasos toma cada conversación en producción, no estás operando un agente estás operando una caja negra con tarjeta de crédito. Una alerta cuando una conversación supera X pasos vale más que cualquier optimización de prompts.
En la arquitectura: No todos los casos de uso necesitan el mismo agente. Un FAQ sencillo que resolverías en 2 pasos no debería usar la misma arquitectura que un análisis complejo de 20 pasos. Segmenta por complejidad esperada desde el diseño, no como optimización posterior.
La pregunta que deberías hacerte antes de ir a producción
Cuando termines de construir tu agente y antes de exponerlo a usuarios reales, hazte esta pregunta:
¿Qué hace mi agente cuando no puede resolver la tarea?
Si la respuesta es “sigue intentando”, tienes un problema de diseño.
Si la respuesta es “después de N intentos, responde con lo que tiene y registra el fallo”, tienes un agente listo para producción.
La diferencia entre ambas respuestas puede ser tu factura del próximo mes.
Para llevar
Los agentes de IA son una herramienta poderosa y el caso de uso con RAG es uno de los más sólidos que existen hoy para aplicaciones empresariales reales. Pero el poder sin límites no es arquitectura es un riesgo operativo.
Define los criterios de parada. Ponle límites. Monitorea los pasos. Crea alertas.
El agente más barato que resuelve el problema siempre es la mejor arquitectura.
¿Estás implementando agentes en tus proyectos Oracle APEX o en otros entornos? Cuéntame en los comentarios qué patrones has visto o cuáles te han costado dinero.
Social List