Qué es realmente un agente de IA (y qué se está vendiendo como tal)

En los últimos dos años, "agente" pasó de ser un término técnico a ser una etiqueta comercial. Hoy se aplica indistintamente a un formulario con autocompletado inteligente y a un sistema que abre pull requests en tu repositorio. Vale la pena recuperar la distinción, porque determina cuánta autonomía estás delegando y cuánto puede salir mal.

La definición mínima

Un sistema merece llamarse agente cuando el modelo decide qué pasos dar, no solo qué texto producir. Concretamente: tiene acceso a herramientas (funciones que puede invocar), observa el resultado de cada una y usa esa observación para decidir la siguiente acción, en un ciclo, hasta considerar la tarea terminada.

Si la secuencia de pasos está fijada por el programador y el modelo solo rellena los huecos, eso es un flujo de trabajo con IA. Funciona muy bien, es más predecible y más barato de operar. Simplemente no es un agente, y llamarlo así confunde a quien tiene que evaluar el riesgo.

El espectro real

Prompt simple. Entra texto, sale texto. Sin herramientas, sin estado.

Flujo encadenado. Varios pasos definidos por el desarrollador: extraer, clasificar, resumir. El modelo ejecuta cada eslabón; el orden lo decide el código. La mayoría de los productos "con IA" que funcionan bien hoy están acá.

Enrutamiento. El modelo elige entre un conjunto cerrado de caminos predefinidos. Hay decisión, pero acotada y auditable.

Agente con herramientas. El modelo elige libremente qué herramientas usar y en qué orden, dentro de un presupuesto de pasos. Acá empieza la autonomía real, y con ella la necesidad de límites explícitos.

Agente con permisos de escritura. El agente no solo lee: modifica archivos, envía correos, ejecuta comandos, mueve dinero. Es la categoría con más potencial y la única donde un error puede ser irreversible.

La pregunta que hay que hacer a cualquier proveedor

No "¿es un agente?", sino: ¿qué acciones irreversibles puede ejecutar sin que un humano apruebe?

De esa respuesta se derivan todas las demás. Si la respuesta es "ninguna", tienes un asistente y el riesgo es esencialmente de calidad. Si la respuesta incluye enviar comunicaciones a clientes, borrar registros o autorizar pagos, tienes un sistema que necesita bitácora de auditoría, límites de gasto, permisos acotados y una forma de revertir lo hecho.

Los tres fallos que aparecen siempre

El bucle. El agente repite la misma acción fallida indefinidamente porque no reconoce que la herramienta le está devolviendo un error. Se controla con un tope duro de pasos y de costo, no con instrucciones en el prompt.

El paso silenciosamente omitido. El agente reporta la tarea como completada habiendo salteado una parte. Es el fallo más peligroso porque no se ve: se detecta con verificación programática del resultado, no preguntándole al modelo si lo hizo bien.

La herramienta mal usada. Parámetros inventados, formatos incorrectos, llamadas a funciones que no existen. Se mitiga con validación estricta de esquemas en el borde y mensajes de error que le expliquen al modelo qué corregir.

Dónde rinde hoy

La evidencia práctica apunta a tareas con tres propiedades: el resultado es verificable de forma automática (compila, pasa los tests, cuadra la suma), el costo de un error es recuperable, y la tarea es tediosa pero bien definida. Migraciones de código, clasificación masiva de documentos, conciliación de registros entre sistemas.

Donde todavía decepciona es en tareas de criterio abierto sin señal de verificación —redactar la estrategia, decidir la prioridad— porque ahí el agente no tiene forma de saber si lo hizo bien, y tú tampoco sin revisarlo entero. En ese caso el humano no ahorró trabajo: lo cambió de lugar.

Un criterio para decidir

Antes de contratar cualquier cosa que se anuncie como agente, escribe la tarea que quieres delegar y responde: ¿cómo sabré, sin revisarlo todo a mano, que quedó bien? Si no tienes respuesta, el problema no es el agente. Es que la tarea todavía no está lista para delegarse.