AI Agents

Un AI agent es el loop, no el modelo. El modelo (Claude, GPT, Gemini, un LLM open-weights) es el que decide. El agent es el runtime: le da al modelo un objetivo, le deja invocar herramientas (una base de datos, una API, un intérprete de código, otro agent) a menudo vía MCP, observa el resultado y vuelve a alimentar el loop hasta terminar.

La distinción importa porque los sistemas agénticos fallan distinto que las aplicaciones LLM puras. Un chatbot se puede equivocar y el usuario sigue adelante. Un agent que se equivoca manda un email, hace una transacción o borra un archivo. Los agents en producción necesitan gates de autorización, observabilidad y circuit breakers que la mayoría de prototipos se saltan.

Ejemplo del fallo de producción más común: a un agent de soporte se le da un objetivo «resolver ticket» y un conjunto de herramientas. Un ticket mal formado lo manda a un loop donde llama a la misma herramienta de lookup decenas de veces, quema el presupuesto del modelo en una tarde y nunca llega a una resolución. El arreglo no es un prompt más listo, es ingeniería: un límite duro de pasos, un techo de coste y un circuit breaker que detiene el loop y escala a un humano. Cualquier cosa que escribe (manda un mensaje, hace un pago, borra un registro) lleva un gate con humano en el loop; los loops de solo lectura suelen poder correr desatendidos.

El trade-off honesto y el error de founder a evitar: los agents añaden no-determinismo, latencia y un radio de impacto mucho mayor que un pipeline fijo, a cambio de manejar tareas cuyos pasos no se pueden enumerar de antemano. La mayoría de flujos vendidos como «agénticos» son bien conocidos y se sirven mejor con un pipeline determinista y una o dos llamadas al LLM en medio, a menudo respaldados por RAG para fundamentación. La postura de Wavect: primero preguntar si IA es la herramienta adecuada aquí, después si un agent es la forma adecuada de IA para ello. Si puedes escribir los pasos, no dejes que el modelo los improvise.