Errores comunes al construir un agente de IA (y cómo evitarlos)

Montas tu primer agente de IA. Le enchufas un modelo, le das una herramienta, le preguntas algo y responde con sentido. En la demo parece magia. Lo enseñas, alguien aplaude, y te vienes arriba.

Y entonces lo sueltas un poco más. Lo dejas abierto, le añades más agentes, lo conectas a tus datos. Ahí es donde el juguete deja de ser juguete: el agente se va por las ramas, la factura de tokens sube sin que sepas muy bien por qué, y un día te das cuenta de que no tienes ni idea de qué está haciendo por dentro.

No es que construir agentes sea imposible. Es que casi todo el mundo tropieza en los mismos sitios, y casi ninguno tiene que ver con elegir el modelo de moda. Son errores de criterio. Vamos con los tres que más caro se pagan al principio.

Error 1: soltar el agente al mundo sin ponerle un solo límite ¶

Tienes el agente del tiempo funcionando: le preguntas qué ropa ponerte y te contesta mirando datos reales. Perfecto. Hasta que alguien le pregunta el precio de la sardina en la lonja del pueblo y el agente, tan contento, se pone a hablar de en qué año nació Napoleón.

Le has dado una herramienta y una misión, pero no le has puesto ningún borde. Y un modelo sin bordes hace lo que mejor sabe hacer: seguir cualquier conversación, tenga que ver o no con su trabajo. En tu portátil eso es una anécdota graciosa. En producción es otra cosa: si dejas el agente abierto al usuario final sin límite de tokens, sin autenticación y sin control de tema, le acabas regalando un ChatGPT que paga tu tarjeta. Cada divagación sobre Napoleón tira de tus tokens y de tu cartera.

Lo peligroso es que esto no se ve en la demo. La demo la haces tú, que preguntas lo que toca. El problema aparece el día que lo abres a gente que pregunta lo que le da la gana.

Cómo evitarlo: ponle bordes antes de enseñárselo a nadie. Tres cosas, en este orden: un límite de tokens por conversación para que una charla descontrolada no te arruine, autenticación para saber quién está hablando con tu agente, y un filtro que rechace educadamente lo que no tiene nada que ver con su misión. No es paranoia, es lo mínimo para que un agente deje de ser una demo y empiece a ser un producto.

Error 2: creer que con más agentes el resultado es mejor ¶

Hay un momento, justo después de que tu primer agente funcione, en el que piensas: “¿y si en vez de uno pongo varios? Uno que busque, otro que decida, otro que revise”. Suena a sistema serio. Suena a que estás construyendo algo grande.

A veces lo es. Casi siempre, todavía no. Montar varios agentes coordinados no es gratis, y el precio es muy concreto. En una tarea multiagente real, llevada hasta el final, el contador marcó esto: unos 120 minutos de ejecución, alrededor de dos millones de tokens, 218 pasos, seis modelos distintos trabajando y cerca de 1.900 ficheros tocados. Para una sola tarea. La orquestación da mejores resultados en problemas genuinamente complejos, sí, pero consume una barbaridad, y la mayoría de lo que vas a construir al principio no lo necesita.

Hay un matiz que ayuda a entenderlo: cada agente arrastra su propia ventana de contexto, y como los agentes no comparten memoria entre sí, tienes que pasarles la información a mano de uno a otro. Más agentes significa más contexto que mantener, más ficheros que escribir y más tokens que quemar en pura coordinación.

Cómo evitarlo: empieza por un agente y, como mucho, un workflow. Un único agente con una herramienta bien definida cubre más casos de los que crees. Si necesitas pasos en un orden fijo, un workflow (esto primero, luego esto) te da control sin el coste de la orquestación libre. Salta a varios agentes solo cuando un único prompt se quede corto de verdad, y cuando lo hagas, mide el coste antes de dejarlo suelto. La factura de los dos millones de tokens no avisa.

Error 3: enchufar el mismo modelo —y el más caro— para todo ¶

Como no quieres que falle, le pones a todo el modelo más potente que puedes pagar. A explorar ficheros, a clasificar una intención, a resumir, a planificar: el mismo cañón para matar moscas. Y la factura lo nota.

No todas las tareas de un agente pesan lo mismo. Leer, explorar y clasificar es trabajo barato que un modelo rápido y modesto resuelve igual de bien. Donde el modelo caro se gana el sueldo es razonando y planificando, que es justo donde un modelo flojo te deja tirado. Si usas el más potente para todo, estás pagando precio de planificación por tareas que cuestan cuatro duros.

Hay además un detalle que descoloca a mucha gente: es bueno que un agente bien definido rechace una tarea que no le toca. Cuando ves un “esto son varias tareas, no me corresponde”, no es un fallo: es un agente que sabe cuál es su trabajo. Prefieres eso, aunque gaste algún token de más en decir que no, a uno que se inventa una respuesta por complacerte.

Cómo evitarlo: asigna el modelo a la tarea, no al revés. Modelo barato y rápido para explorar, leer y clasificar; modelo potente reservado para donde hay que razonar o planificar de verdad. Especializa cada pieza y deja que rechace lo que no es suyo. Te sale más barato y, casi siempre, mejor.

Error 4: dar por hecho que tu agente hace lo que tú crees ¶

Le pides al agente que use una herramienta. La respuesta llega y parece correcta. Das por sentado que llamó a la herramienta. Pero, ¿lo hizo de verdad, o se inventó una respuesta plausible sin tocarla?

La mayoría de las veces no lo sabes. Y este es el agujero que casi nadie menciona: trabajas a ciegas. El agente puede estar saltándose la tool que tanto te costó montar, llamándola con argumentos raros o ignorando lo que devuelve, y tú viendo solo el resultado final, que parece bueno. Las herramientas serias de trazabilidad existen, pero son un mundo aparte y montarlas bien lleva su tiempo. Mientras tanto, navegas por intuición.

Cómo evitarlo: oblígate a ver qué pasa por dentro, aunque sea de forma cutre. No necesitas una plataforma de observabilidad para empezar. Mete instrucciones de depuración en lenguaje natural dentro del propio prompt del agente (“cuando uses esta herramienta, escribe antes una línea diciéndolo”) y vuelca esas trazas a un fichero que puedas leer después. Es rudimentario, pero te saca del modo fe ciega: por primera vez ves qué decidió el agente, con qué llamó a cada herramienta y qué le devolvió. A partir de ahí ya puedes mejorar; antes, solo adivinabas.

Hasta aquí los cuatro errores que cometes el primer día, cuando el agente todavía es un experimento. Pero los que de verdad separan un juguete de un agente que aguanta en producción vienen después, y son justo las piezas que casi nadie enseña montadas, en directo y con el código delante.