Los errores que se cometen al montar el primer agente de IA
Seis fallos que cuestan tiempo y dinero al montar un agente con un LLM, por qué se cometen y la regla que los evita. Con casos reales.
- Autor
- Dani
- Publicado
- Lectura
- 7 min · 1440 palabras
Montar un agente que funcione en una demo es fácil. Montar uno que lleve tres meses corriendo sin que te haya costado dinero, tiempo o un disgusto es otra cosa.
Estos son los seis fallos que he visto —y cometido— con más frecuencia. No son problemas de modelo ni de framework: son decisiones de diseño que parecen razonables el primer día y se pagan después.
1. Darle al agente un objetivo en vez de una tarea
El primer impulso es escribir algo como “gestiona mi bandeja de entrada”. Suena a lo que promete la tecnología, y es la receta exacta para un agente impredecible.
El problema no es que el modelo sea incapaz. Es que un objetivo abierto no tiene criterio de terminación. El agente no sabe cuándo ha acabado, así que sigue: lee otro correo, decide que ese también merece respuesta, encadena una acción más. Y cuando algo sale mal no sabes en qué paso fue, porque nunca definiste los pasos.
Lo que funciona es lo contrario de lo que parece ambicioso: una tarea, un criterio de éxito, un final. “Clasifica los correos nuevos en tres categorías y escribe un borrador para los de la primera.” Eso se puede comprobar, se puede depurar y se puede repetir. Cuando funciona, añades el siguiente paso.
2. Dejar que el modelo ejecute lo que no se puede deshacer
Este es el error caro, y el que más veces he visto en producción.
Un agente que puede enviar correos enviará un correo raro. No es una posibilidad remota: es cuestión de volumen. Con suficientes ejecuciones, el caso extraño llega.
La regla que no tiene excepciones útiles: el modelo genera, el sistema decide si se ejecuta. Y la frontera para decidir dónde poner la puerta humana no es lo importante que sea la acción, sino si se puede deshacer:
Dónde se pone la puerta humana
Fig. 01
Se puede deshacer
Automatiza del todo
- Escribir un borrador
- Crear una tarea
- Etiquetar o clasificar
- Guardar una propuesta
- Añadir una nota interna
No se puede deshacer
Hace falta una persona
- Enviar un correo
- Publicar en abierto
- Borrar datos
- Pagar o transferir
- Escribir a un cliente
Datos propios
Fíjate en que no es una cuestión de confianza en el modelo. Es de asimetría: el coste de revisar doce propuestas es un minuto; el coste de un correo mal enviado a un cliente puede ser la relación. Cuando los costes son así de asimétricos, la puerta humana sale gratis.
3. Mandarle todo el contexto por si acaso
Es tentador volcarle la página entera, el historial completo, el documento sin recortar. Más contexto parece más información y por tanto mejor respuesta.
Son dos problemas en uno. El primero es el coste: pagas por cada token que entra, y la diferencia entre mandar el fragmento que cambió y la página completa son dos órdenes de magnitud en la factura. El segundo es más importante y menos obvio: el ruido empeora el resultado. Un modelo al que le entregas una página entera dedica atención a la navegación, al pie y a los avisos de cookies. Uno al que le entregas el párrafo relevante responde mejor.
La disciplina práctica es normalizar antes de llamar al modelo: quitar lo que no aporta, extraer solo lo que cambió, recortar el documento al apartado que importa. Lo desarrollé con un caso completo en la guía para automatizar tareas con n8n y un LLM.
4. No registrar nada hasta que algo falla
Un agente sin registro es una caja negra que gasta dinero. Cuando te das cuenta de que algo va mal —y siempre te das cuenta tarde— no tienes forma de saber qué entró, qué decidió ni cuánto costó.
El registro mínimo que hay que tener desde la primera ejecución son cuatro campos: la entrada que recibió, la salida que produjo, la acción que se ejecutó (o no) y los tokens consumidos. Con eso puedes responder a las tres preguntas que vas a tener: por qué hizo eso, cuánto me está costando, y desde cuándo está roto.
Y hay un fallo peor que no registrar: registrar y no mirarlo. Un sistema que avisa solo cuando hay algo que decidir se lee; uno que escribe cien líneas al día se ignora a la semana. Si tu registro no genera ninguna acción, no es observabilidad, es ruido con coste de almacenamiento.
5. Medir el agente por lo que hace y no por lo que resuelve
El último es el más sutil. Montas el agente, funciona, hace cosas. Y nadie se pregunta si el problema original se resolvió.
He visto flujos ejecutándose durante semanas generando propuestas que nadie leía. El sistema funcionaba perfectamente: cada ejecución terminaba sin errores, el registro estaba limpio, el coste era bajo. Simplemente no servía para nada, porque el resultado no entraba en el trabajo de ninguna persona.
La pregunta de control no es “¿funciona el agente?” sino “¿qué dejé de hacer a mano desde que existe?”. Si la respuesta es “nada”, el agente es un pasatiempo caro, por bien construido que esté. Y si la respuesta es “esto”, entonces ya sabes qué medir para saber si sigue valiendo la pena.
6. No poner techo al bucle
Un agente con herramientas decide cuántas veces llamarlas. Si la condición de salida depende de que el modelo considere la tarea terminada, has delegado el límite de gasto al propio modelo.
Lo normal es que funcione. Lo que falla es el caso raro: una herramienta devuelve un error que el modelo interpreta como “inténtalo de otra forma”, y el agente entra en un bucle de reintentos razonables que consume tokens durante horas. No es un fallo espectacular —no hay excepción ni traza— solo una factura.
Tres límites que conviene poner desde la primera versión, y ninguno cuesta nada:
- Máximo de iteraciones por ejecución. Un número absoluto. Si lo alcanza, para y avisa en vez de seguir.
- Máximo de tokens por ejecución. Si se pasa, aborta. Es un seguro contra el caso que no has previsto.
- Tiempo máximo. Un agente que lleva veinte minutos en una tarea de dos no está pensando mejor: está atascado.
Y una comprobación que cuesta un minuto: fuerza un error en una herramienta a propósito y mira qué hace el agente. Si reintenta indefinidamente, acabas de encontrar tu bucle antes de que lo encuentre tu tarjeta.
Cuánto cuesta equivocarse en cada uno
No todos pesan igual, y conviene saber por dónde empezar a mirar si ya tienes algo montado:
| Error | Qué te cuesta | Cuándo lo notas |
|---|---|---|
| Objetivo en vez de tarea | Tiempo de depuración | Pronto, y duele |
| Ejecutar lo irreversible | Un disgusto con un cliente | Tarde, de golpe |
| Contexto de más | Dinero, cada ejecución | En la factura del mes |
| Sin registro | No puedes diagnosticar nada | Cuando ya está roto |
| Medir lo que hace | Semanas de trabajo inútil | Muy tarde, o nunca |
| Bucle sin techo | Dinero, en ráfaga | En la factura, de golpe |
Los dos que se notan “de golpe” son los que justifican hacer bien el trabajo desde el principio: el irreversible y el bucle. Los otros cuatro se pueden corregir sobre la marcha sin que pase nada grave.
La regla que resume todos
Si tuviera que quedarme con una: un agente es un sistema, no un prompt.
Los seis errores salen de tratarlo como lo segundo. Un prompt se escribe y se prueba; un sistema tiene entradas acotadas, pasos depurables, acciones reversibles separadas de las que no lo son, registro de lo que pasó y una métrica de si sirve.
Empieza por la tarea más pequeña que puedas comprobar de un vistazo. Déjala una semana. Mira el registro. Y añade el siguiente paso solo cuando el anterior te haya dejado de dar sorpresas. Si quieres ver cómo se aplica esto a elegir el modelo adecuado para cada paso, lo comparo en la comparativa de Claude y ChatGPT para empresas.