Definición en una frase
Sistema que utiliza un modelo para decidir pasos, mantener estado y operar herramientas bajo objetivos, permisos y reglas definidos.
Qué es un agente de IA
Un agente de IA es un sistema que recibe información de un entorno, selecciona acciones en función de un objetivo y observa qué ocurre después para decidir si continúa, cambia de curso o se detiene. La palabra importante es «sistema»: el agente no es necesariamente un modelo de inteligencia artificial aislado. Puede incluir un modelo o una política de control, instrucciones, información de contexto, herramientas, un entorno y reglas que limitan las acciones posibles.
Esta definición describe un ciclo de percepción, decisión y acción. No exige que el sistema tenga una personalidad, conciencia, memoria permanente ni libertad para hacer cualquier cosa. Tampoco exige que utilice un modelo de lenguaje grande (LLM). El marco clásico de los agentes es más amplio que los asistentes generativos actuales; estos son una familia de implementaciones posibles, no la definición completa.
En esta ficha, «agente» se usa en un sentido funcional: importa si el sistema puede elegir entre acciones posibles a partir del estado que observa y de la tarea que debe cumplir. Un sistema puede tener autonomía muy limitada —por ejemplo, seleccionar una herramienta entre dos opciones autorizadas— y seguir mostrando un comportamiento agéntico. La autonomía, por tanto, no es un interruptor binario.
Componentes posibles y ciclo de funcionamiento
Un agente puede combinar varios elementos. El objetivo define qué se intenta conseguir; el modelo o política de control ayuda a elegir el siguiente paso; las instrucciones y el contexto delimitan la tarea; el estado recoge la información necesaria para continuar; las herramientas o actuadores permiten actuar; y el entorno es aquello que el agente observa o modifica. También pueden existir permisos, comprobaciones, límites de uso y condiciones de parada. Son componentes posibles, no una lista de requisitos que todos los agentes deban cumplir.
En una implementación con un modelo generativo, el bucle puede consistir en enviar al modelo la tarea y el estado disponible, inspeccionar su respuesta, ejecutar una herramienta si el sistema lo permite y volver a consultar al modelo con el resultado. El proceso termina cuando se obtiene una respuesta final, se cumple un criterio de parada, se alcanza un límite o se requiere intervención humana. La documentación de un SDK concreto describe un ciclo de ejecución de este tipo; otros diseños pueden organizarlo de manera distinta.
La memoria también requiere precisión. El sistema puede conservar información durante una tarea o recibir estado guardado entre tareas, pero no debe suponerse que toda implementación lo hace. Del mismo modo, puede usar una sola herramienta, varias o ninguna. Tener herramientas disponibles no significa que el agente pueda invocarlas sin restricciones: los permisos y las reglas de control determinan qué acciones son efectivamente posibles.
Un ciclo agéntico, paso a paso
- 01Recibir una tarea y determinar el objetivo y los límites aplicables.
- 02Observar el estado relevante del entorno y el contexto disponible.
- 03Elegir entre responder, pedir información, usar una herramienta permitida o detenerse.
- 04Ejecutar la acción autorizada y recoger su resultado.
- 05Actualizar el estado con la nueva observación y decidir si continuar, escalar la tarea o finalizar.
- 06Comprobar la condición de parada y, cuando corresponda, verificar el resultado antes de presentarlo.
Cuatro ejemplos en ámbitos distintos
Los ejemplos siguientes son esquemas ilustrativos, no afirmaciones de que todos los productos de esos sectores funcionen así. En cada caso, lo que hace que el diseño sea agéntico es el ciclo entre observación, selección de acciones y revisión de resultados. Una tarea acotada puede tener permisos reducidos y controles humanos sin dejar de ser un sistema que elige pasos según lo que encuentra.
blocks
paragraphs
Agente, chatbot, herramienta y automatización: diferencias prácticas
Un chatbot suele describirse por su interfaz conversacional: recibe mensajes y produce respuestas. Puede limitarse a responder, pero también puede incorporar acciones y un ciclo de decisión. Por eso «chatbot» y «agente» no siempre son categorías excluyentes: el primer término puede nombrar la forma de interacción, mientras que el segundo describe cómo el sistema selecciona acciones para avanzar hacia una tarea.
Una llamada a herramientas es una capacidad o un paso de ejecución, no una garantía de autonomía amplia. Un modelo puede decidir qué herramienta llamar, cuándo hacerlo y con qué argumentos, como estudia Toolformer; aun así, el sistema completo incluye el mecanismo que autoriza y ejecuta esa llamada. También puede haber agentes que no recurran a herramientas externas. Una interfaz de herramientas, como MCP, es un concepto relacionado, pero la mera conexión a una herramienta no basta para determinar cuánto decide el sistema.
Una automatización o flujo de trabajo especifica pasos de antemano: si se cumple una condición, se ejecuta una acción fijada. Si se introduce un LLM en uno de esos pasos, el flujo pasa a incluir IA, pero no necesariamente adquiere selección dinámica de acciones. En un sentido amplio, alguien podría llamar «agéntico» a un flujo que incorpora decisiones. En esta ficha reservamos «agente dinámico» para un diseño que puede escoger el siguiente paso según la tarea y las observaciones, en vez de recorrer únicamente una secuencia cerrada.
Un asistente es una categoría de producto o rol que puede abarcar desde responder preguntas hasta realizar tareas con herramientas; no determina por sí misma la arquitectura. Un sistema multiagente coordina más de un agente, pero el número de componentes no demuestra una mejor solución. La memoria de agente, la ingeniería de contexto, la recuperación aumentada por generación (RAG) y el humano en el circuito son conceptos relacionados que pueden aparecer en algunos diseños; ninguno es un requisito universal para llamar agente a un sistema.
Tabla de decisión: ¿qué describe mejor el sistema?
| Lo que observas | Descripción más precisa | Qué falta comprobar |
|---|---|---|
| Recibe mensajes y responde, sin que se describan acciones posteriores. | Chatbot o interfaz conversacional. | Si puede seleccionar y ejecutar acciones fuera de la respuesta. |
| Ejecuta siempre los mismos pasos ante la misma condición. | Automatización o flujo predeterminado. | Si existe elección dinámica del siguiente paso según nuevos resultados. |
| El modelo solicita una herramienta y el sistema la ejecuta. | Uso de herramientas; puede formar parte de un agente. | Quién decide, qué permisos hay y cómo se usa el resultado. |
| Observa resultados y elige entre acciones permitidas para avanzar en una tarea. | Comportamiento agéntico, con el grado de autonomía que permitan sus controles. | Alcance, verificaciones, intervención humana y condiciones de parada. |
Errores frecuentes y límites
El primer error es tratar al agente como si fuera solo el LLM. Un modelo puede producir una propuesta de acción, pero el sistema que la recibe decide si ejecutarla, con qué permisos y cómo devolver el resultado al siguiente paso. La diferencia importa para analizar seguridad y responsabilidad: una respuesta en texto y una acción que modifica un recurso no tienen las mismas consecuencias.
El segundo error es inferir autonomía extensa a partir del uso de herramientas. El sistema puede tener una única herramienta disponible, requerir aprobación en cada acción o funcionar dentro de un entorno de prueba. En sentido contrario, una automatización sin LLM puede seleccionar acciones en función de observaciones. Conviene describir el comportamiento y los controles en vez de depender de una etiqueta comercial.
Tampoco debe confundirse autonomía con fiabilidad. Un agente puede interpretar mal una tarea, planificar de forma inadecuada, recibir observaciones incompletas o utilizar incorrectamente el resultado de una herramienta. Puede repetir acciones en un bucle, detenerse demasiado pronto o producir una síntesis que no refleje la evidencia recuperada. Una respuesta fluida, una demostración o una ejecución satisfactoria no prueban por sí solas un rendimiento consistente.
Cuando un sistema procesa instrucciones o contenido externo, ese material puede intentar influir en sus decisiones, por ejemplo mediante prompt injection. El riesgo depende de qué datos lee el sistema, qué acciones puede ejecutar y cómo se separan las instrucciones de confianza del contenido observado. Los permisos mínimos, la revisión humana en pasos sensibles y la capacidad de revertir cambios son medidas de diseño que pueden reducir consecuencias, pero no convierten una tarea abierta en una tarea infalible.
Por último, contar con memoria persistente, planificación explícita o varios agentes no es requisito universal ni garantía de mejores resultados. Son opciones de diseño. Su utilidad depende de la tarea, de cómo se implementen y de cómo se evalúen. Las fuentes disponibles para esta ficha no permiten establecer una comparación general de rendimiento entre todas esas opciones ni respaldar una clasificación universal de los agentes.
Cómo evaluar un agente antes de usarlo
Empieza por definir una tarea observable. «Ayudar con operaciones» es demasiado amplio; «clasificar solicitudes de una categoría y preparar una propuesta de respuesta sin enviarla» permite identificar entradas, salida esperada y límites. Después describe el entorno, la información a la que accede el sistema y las acciones que puede realizar. Así se distingue una respuesta generada de una intervención efectiva.
Especifica permisos y controles: qué acciones son de solo lectura, cuáles modifican datos, cuáles requieren aprobación y cuáles quedan prohibidas. Define también qué debe ocurrir ante datos ausentes, resultados contradictorios, fallos de herramientas o incertidumbre. Las condiciones de parada deben ser explícitas; por ejemplo, detenerse ante una acción no autorizada o escalar una petición que no encaje con los criterios acordados.
Evalúa la tarea y la seguridad por separado. Una medida puede indicar si el resultado cumple el objetivo, pero no basta para saber si el sistema respetó permisos, evitó cambios no deseados o pidió ayuda cuando debía. Comprueba también costes, tiempo, repetición de acciones, facilidad para revisar los resultados y capacidad de revertir una operación. El método de evaluación debería incluir casos normales y casos límite del entorno real.
La intervención humana no tiene que ser idéntica en todas las etapas. Puede ser necesaria antes de una acción irreversible, después de una propuesta o cuando el sistema detecte ambigüedad. Lo importante es que quede claro quién aprueba, qué información recibe y si el sistema puede actuar antes de esa aprobación. Si la verificación del resultado depende del mismo agente que lo produjo, considera si hace falta una comprobación independiente.
Lista práctica de evaluación
- 01Describe la tarea, las entradas aceptadas y la salida que cuenta como éxito.
- 02Enumera el entorno, las fuentes de información y todas las acciones disponibles.
- 03Separa permisos de lectura, escritura, envío y acciones que requieren aprobación.
- 04Fija condiciones de parada, escalado, reversión y respuesta ante fallos o incertidumbre.
- 05Prueba casos habituales, ambiguos y adversos; registra tanto errores como intervenciones necesarias.
- 06Revisa calidad, seguridad, coste y posibilidad de auditar los resultados antes de ampliar el alcance.
Conceptos relacionados y criterios finales
La llamada a herramientas ayuda a entender cómo un modelo puede solicitar una acción externa; la memoria de agente y la ingeniería de contexto se relacionan con la información que el sistema conserva o recibe; RAG trata de incorporar información recuperada a una respuesta o tarea. El humano en el circuito y el principio de menor privilegio sirven para pensar en supervisión y límites de acceso. Son temas que conviene enlazar con las fichas específicas del glosario, no asumir como componentes obligatorios de todo agente. También es útil consultar la comparación entre agentes y otras formas de automatización para examinar los casos fronterizos.
En síntesis, llama agente a un sistema cuando puedas describir un objetivo, observaciones del entorno y una selección de acciones que se ajusta a los resultados obtenidos. Para juzgarlo, no te quedes en la etiqueta: pregunta qué decide, qué puede ejecutar, qué necesita aprobación, cómo verifica el resultado y cuándo se detiene. Una descripción concreta de esos límites es más informativa que afirmar simplemente que un producto es autónomo.
