Un agente de inteligencia artificial es un sistema que recibe un objetivo, utiliza un modelo para decidir pasos y puede consultar herramientas o mantener estado entre ellos. No es simplemente una respuesta larga: hay una coordinación entre percepción de la petición, selección de acciones, resultados y una condición de parada.
La palabra agente cubre diseños muy distintos. Algunos solo realizan una búsqueda y redactan un resumen; otros encadenan consultas y operaciones. La frontera útil es identificar qué decide el modelo y qué permanece bajo reglas deterministas de la aplicación.
El objetivo y el alcance de la tarea
El flujo comienza con un objetivo concreto, como clasificar una solicitud, reunir información de varias fuentes o preparar una propuesta. El objetivo debe incluir límites: qué sistemas puede consultar, qué acciones están fuera de alcance y cuándo debe pedir ayuda.
Un objetivo ambiguo favorece pasos innecesarios. “Gestiona esta incidencia” puede significar leer un historial, cambiar una prioridad o cerrar el caso. Separar esas posibilidades permite asignar permisos diferentes y medir si el agente terminó correctamente.
Modelo, controlador y estado
El modelo interpreta el objetivo y propone el siguiente paso. El controlador mantiene el bucle, selecciona las herramientas permitidas, aplica políticas y entrega los resultados al modelo. El estado puede incluir conversación, identificadores, resultados anteriores y un presupuesto de pasos.
Ese estado no tiene por qué ser memoria ilimitada. Guardar todo aumenta coste y puede conservar datos que ya no son necesarios. Una aplicación debe decidir qué se retiene, durante cuánto tiempo y quién puede acceder a ello.
Herramientas y observaciones
Las herramientas conectan el agente con sistemas externos: buscadores, bases de datos, calendarios o APIs internas. La respuesta de una herramienta se convierte en una observación que el controlador presenta al modelo. El modelo puede decidir que necesita otro dato o que ya puede responder.
La herramienta no debería aceptar la salida del modelo como autorización. El backend valida argumentos y permisos de manera independiente. Un contenido recuperado de un correo o documento puede contener texto que parezca una instrucción, pero conserva el nivel de confianza de su fuente.
El bucle de ejecución
Un ciclo típico contiene objetivo, decisión, llamada, resultado y evaluación de si continuar. El controlador debe imponer un número máximo de pasos, un tiempo límite y un presupuesto de recursos. Sin esos límites, una respuesta ambigua puede provocar llamadas repetidas o una cadena difícil de diagnosticar.
Las condiciones de parada pueden ser una respuesta suficiente, una falta de evidencia, un error irrecuperable o la necesidad de aprobación humana. No conviene definir el éxito solo como “el modelo ha generado texto”.
Permisos y aprobación
El agente debe disponer del mínimo acceso necesario para su tarea. Leer el estado de una incidencia no implica poder cerrarla; preparar un cambio no implica aplicarlo. Para borrar datos, modificar cuentas, enviar comunicaciones o realizar acciones financieras, una revisión explícita puede ser parte del flujo.
Una aprobación útil muestra la acción propuesta, los argumentos, los datos afectados y el efecto esperado. El usuario confirma una operación concreta, no una autorización indefinida para todo lo que el agente decida después.
Errores y supervisión
Puede fallar el modelo, una herramienta, una fuente de datos o la propia lógica del controlador. Clasificar el error permite reintentar solo cuando tiene sentido y derivar el caso cuando no hay evidencia suficiente. La aplicación debe conservar el estado de lo ejecutado para evitar repetir cambios.
La supervisión combina logs, métricas y ejemplos de evaluación. Mide pasos por tarea, llamadas rechazadas, tiempo, coste, resultados incompletos y frecuencia de intervención humana. Un agente que termina muchas tareas pero genera operaciones incorrectas no está funcionando bien.
Cuándo un flujo determinista es mejor
Si las entradas están estructuradas y las reglas son conocidas, un workflow convencional suele ser más fácil de probar. Un agente aporta flexibilidad cuando debe interpretar lenguaje variable, escoger entre fuentes o coordinar pasos con incertidumbre. Esa flexibilidad también añade variabilidad, consumo y superficie de seguridad.
Cuándo un agente añade valor y cuándo complica una automatización sencilla
Antes de adoptar un agente, identifica qué decisión necesita interpretación y qué acciones deben seguir reglas fijas. Mantén deterministas las autorizaciones, los límites y los efectos destructivos. El agente puede ayudar a explorar y preparar; la aplicación debe decidir qué se ejecuta y dejar una evidencia revisable de cada paso.
Planificación no equivale a autonomía
Que un sistema pueda proponer varios pasos no significa que opere sin límites ni supervisión. El controlador puede imponer un presupuesto de llamadas, una lista de destinos permitidos y un plazo de ejecución. Si se agota cualquiera de ellos, el agente debe detenerse con un estado que permita continuar o derivar el caso.
La memoria también debe distinguir hechos confirmados de hipótesis del modelo. Guardar una conjetura como si fuera un dato puede contaminar pasos posteriores. Los resultados de herramientas deberían conservar su fuente y momento para que el siguiente ciclo no los trate como información permanente sin comprobar su vigencia.
Medir una tarea completa
La evaluación de un agente combina el resultado final con la trayectoria. Cuenta llamadas innecesarias, pasos repetidos, errores recuperables y ocasiones en las que debió pedir aprobación. Una tarea aparentemente correcta puede haber expuesto datos o consumido recursos de manera inaceptable.
Para una automatización de soporte, por ejemplo, el agente puede clasificar una petición y reunir información, mientras que el cierre del caso sigue una regla fija. Esa división conserva flexibilidad en la interpretación y control determinista en el efecto.