Cómo funcionan los agentes de IA: el modelo, las herramientas, la memoria y el bucle de control

Un agente de IA funciona combinando un modelo con instrucciones, herramientas, memoria y un bucle de control que decide repetidamente qué hacer a continuación. El modelo aporta juicio y capacidades de lenguaje, mientras que el software circundante convierte esas capacidades en un proceso con estado que puede actuar, inspeccionar resultados, recuperarse de errores y detenerse.

Comprender esta arquitectura resulta más útil que tratar a un agente como un único objeto inteligente. La mayoría de los éxitos y fracasos provienen de cómo interactúan los componentes: un modelo excelente puede verse socavado por herramientas vagas, memoria obsoleta, permisos excesivos o un bucle de control sin una definición fiable de finalización.

Las cinco partes esenciales de un agente de IA

1. el modelo

El modelo interpreta el objetivo, razona sobre el contexto disponible y selecciona una acción. En muchos agentes actuales, se trata de un gran modelo de lenguaje capaz de seguir instrucciones y producir llamadas estructuradas a herramientas, además de lenguaje natural.

El modelo más capaz no es automáticamente la mejor opción para cada paso. Un sistema puede encaminar la planificación difícil a un modelo más potente, usar un modelo más rápido para clasificación y confiar en código determinista para la validación. Esta combinación puede mejorar la velocidad, el coste y la fiabilidad.

2. Instrucciones

Las instrucciones definen el rol del agente, sus límites, prioridades y requisitos de salida. Pueden incluir un mensaje del sistema, contexto específico de la tarea, políticas, ejemplos, descripciones de herramientas y criterios de detención.

Las buenas instrucciones son operativas. Indican al agente qué evidencia es necesaria, cuándo solicitar aprobación, qué fuentes son aceptables y cómo reconocer la finalización. Las reglas vagas o contradictorias obligan al modelo a adivinar, creando inconsistencias en tareas aparentemente similares.

3. Herramientas

Las herramientas conectan el modelo con capacidades fuera de su contexto actual. Una herramienta puede buscar en la web, recuperar un registro de cliente, ejecutar código, consultar una base de datos, controlar un navegador o crear un evento de calendario.

Normalmente, el modelo no ejecuta la función directamente. Elige una herramienta nombrada y propone argumentos estructurados. El tiempo de ejecución del agente valida esa solicitud, verifica permisos, ejecuta la operación y devuelve el resultado. Esta separación es esencial: permite al software rechazar acciones mal formadas o inseguras antes de que afecten al mundo exterior.

4. Estado y memoria

El estado es la información que el agente necesita durante la ejecución actual: el objetivo, la conversación, el plan, observaciones, salidas de herramientas y pasos completados. La memoria amplía ese concepto reteniendo información útil más allá del contexto inmediato, como preferencias previas, hechos recurrentes o lecciones de tareas anteriores.

Más memoria no siempre es mejor. Los registros irrelevantes consumen contexto y pueden dirigir al modelo hacia suposiciones desactualizadas. Los sistemas de memoria eficaces deciden qué almacenar, cómo organizarlo, cuándo recuperarlo y cómo manejar información conflictiva o caducada.

5. el bucle de control

El bucle de control es la capa de orquestación que mantiene el proceso en movimiento. Envía el estado actual al modelo, recibe una acción propuesta, ejecuta las herramientas aprobadas, registra la observación y vuelve a invocar al modelo.

Anthropic describe un agente como un modelo de lenguaje ampliado que opera en un bucle con capacidades como recuperación, herramientas y memoria en su guía para construir agentes eficaces. OpenAI enmarca de manera similar la ejecución del agente como una interacción continua entre el modelo, sus herramientas y un entorno en De modelo a agente.

Las interfaces importan tanto como los componentes

Un diagrama de arquitectura puede mostrar cada componente como claramente separado, pero la fiabilidad real depende de los contratos entre ellos. El modelo necesita descripciones de herramientas que distingan capacidades similares. El tiempo de ejecución necesita argumentos tipados y estados de error explícitos. La recuperación de memoria requiere información de procedencia y frescura. El verificador de finalización necesita criterios que puedan probarse, no una sensación vaga de que la respuesta es suficientemente buena.

Considere una herramienta de búsqueda que devuelve una lista vacía. Ese resultado podría significar que no existen registros relevantes, que la consulta estaba mal formada, que el usuario carece de permiso o que el servicio expiró. Si la herramienta colapsa las cuatro condiciones en la misma salida, el modelo no puede razonar de forma fiable sobre lo ocurrido. Una interfaz bien diseñada devuelve evidencia estructurada: estado, fuente, marca temporal, consulta, recuento de resultados y un error legible por máquina cuando corresponda.

El mismo principio se aplica al contexto. Las instrucciones, registros autoritativos, pasajes recuperados, notas creadas por el modelo y contenido externo no confiable no deben tratarse como texto equivalente. Etiquetar su origen y autoridad ayuda al tiempo de ejecución a aplicar políticas y al modelo a ponderar la evidencia correctamente. Esto constituye una forma práctica de ingeniería de contexto: decidir no solo qué información ve el modelo, sino cómo está organizada y qué permite el sistema controlar.

Ejemplo paso a paso

Imagine que se le pide a un agente comparar tres proveedores potenciales y preparar una recomendación.

1. Recibir el objetivo: el agente lee los criterios de decisión, la fecha límite, el presupuesto y la salida requerida.
2. Inspeccionar el contexto disponible: verifica si los nombres de los proveedores, los requisitos internos y los documentos fuente están presentes.
3. Crear un plan: decide recopilar precios, información de seguridad, términos de servicio y evidencia de clientes para cada proveedor.
4. Seleccionar una herramienta: busca en un almacén de documentos aprobado o llama a una herramienta de investigación externa.
5. Observar: el tiempo de ejecución devuelve resultados, incluidos posibles errores o campos ausentes.
6. Actualizar el estado: el agente registra lo aprendido y marca preguntas sin resolver.
7. Adaptar: modifica consultas, consulta otra fuente o solicita a una persona un documento no disponible.
8. Verificar: comprueba que cada recomendación esté respaldada y que las comparaciones usen los mismos criterios.
9. Detener o solicitar aprobación: produce un borrador de recomendación, pero deja la decisión de compra a la persona autorizada.

El punto importante es que la secuencia no estaba completamente codificada. El sistema seleccionó pasos en función de lo que encontró, pero siguió operando dentro de los límites diseñados.

La planificación no siempre es una fase separada

Algunos agentes generan un plan completo antes de actuar. Otros deciden un paso a la vez. Muchos usan un enfoque híbrido: crear un plan preliminar, ejecutar la siguiente acción y revisar el plan restante a medida que llegan las observaciones.

Los planes extensos y rígidos pueden quedar obsoletos tras el primer resultado inesperado. Los agentes puramente reactivos pueden divagar o repetir trabajo. Un diseño práctico mantiene suficiente planificación para preservar la dirección, al tiempo que permite replantear cuando el entorno cambia.

El marco ReAct es un ejemplo fundamental de intercalado de razonamiento con acciones y observaciones. Su idea central es que un resultado externo puede corregir, refinar o redirigir el siguiente paso de razonamiento.

Cómo saben los agentes cuándo detenerse

Detenerse es un problema de diseño del sistema. Un modelo puede declarar éxito demasiado pronto, seguir puliendo después de cumplir el objetivo o entrar en bucle cuando una herramienta falla repetidamente.

Los agentes fiables combinan varios mecanismos de detención:

• Criterios de finalización: condiciones explícitas como campos requeridos, pruebas aprobadas o citas verificadas.
• Presupuestos: límites de pasos, tiempo, tokens del modelo, llamadas a herramientas o coste.
• Umbrales de error: escalado tras fallos repetidos o observaciones de baja confianza.
• Puertas de aprobación: una pausa antes de acciones de alto impacto o irreversibles.
• Evaluadores externos: verificaciones deterministas o modelos separados que juzgan si la salida satisface la tarea.

Arquitecturas comunes de agentes

Un bucle de agente único es el diseño más sencillo: un modelo usa repetidamente herramientas hasta terminar. Es más fácil de depurar y a menudo suficiente.

Un enrutador clasifica la solicitud y la envía a un prompt especializado, conjunto de herramientas o modelo. El enrutamiento reduce opciones irrelevantes y puede aplicar políticas diferentes a distintos trabajos.

Una arquitectura orquestador‑trabajador permite que un agente principal cree subtareas y las delegue a trabajadores, para luego sintetizar sus resultados. Resulta útil cuando el trabajo puede ejecutarse en paralelo o requiere distintas especialidades, aunque aumenta el uso de tokens y los modos de falla de coordinación.

Un bucle evaluador‑optimizador separa la generación de la crítica. Un componente produce una respuesta; otro la verifica contra criterios definidos; el primero la revisa. Funciona bien cuando la calidad es medible y la mejora mediante iteración justifica el coste adicional.

Lo que suele salir mal

• Descripciones de herramientas deficientes: el modelo elige la capacidad incorrecta o suministra argumentos inválidos.
• Contexto sin límites: transcripciones largas se llenan de detalles irrelevantes y ocultan la información decisiva.
• Errores silenciosos de herramientas: un resultado vacío o parcial se interpreta como una observación válida.
• Fundamentación débil: el agente actúa sobre una suposición en lugar de verificar el sistema de registro.
• Autonomía excesiva: el agente puede tomar acciones con consecuencias sin una revisión adecuada.
• Sin evaluación de la trayectoria: los equipos juzgan la respuesta final pero no inspeccionan cómo el agente la alcanzó.

Principios de diseño para agentes fiables

Comience con la arquitectura más pequeña que pueda resolver la tarea. Un flujo de trabajo determinista debe manejar los pasos conocidos; reserve la discreción del modelo para decisiones que realmente requieran interpretación. Asigne a cada herramienta un propósito estrecho, entradas tipadas, estados de error explícitos y acceso de menor privilegio.

Haga visible el estado. Registre cada llamada a herramienta, resultado, reintento, aprobación y decisión del modelo necesaria para el diagnóstico. Comprima el contexto antiguo en lugar de seguir añadiéndolo indefinidamente, y preserve los datos autoritativos por separado de los resúmenes generados por el modelo.

Diseñe el tiempo de ejecución de modo que los fallos sean explícitos. Una herramienta debe distinguir “no se encontraron registros” de “la solicitud falló”, y el almacén de estado debe distinguir hechos verificados de resúmenes generados por el modelo. De lo contrario, el modelo podría interpretar una ausencia causada por un tiempo de espera como evidencia de que algo no existe.

Finalmente, evalúe el sistema completo. Ejecute la misma tarea varias veces, mida el éxito y el uso de recursos, e inspeccione las trayectorias en busca de violaciones de políticas o atajos frágiles. La guía de Anthropic sobre evaluaciones de agentes enfatiza que los agentes necesitan tareas, pruebas repetibles, transcripciones y evaluadores, no solo una colección de demostraciones impresionantes.

Qué recordar sobre cómo funcionan los agentes de IA

Un agente de IA es un bucle ingenierizado, no solo un modelo inteligente. El modelo decide; las herramientas actúan; la memoria transporta el estado; el entorno devuelve evidencia; y el bucle de control determina qué ocurre a continuación.

Cuando esas partes tienen interfaces y límites claros, un agente puede abordar trabajos abiertos que la automatización convencional no puede anticipar. Cuando no los tienen, la autonomía amplifica la ambigüedad. La calidad de un agente depende tanto del diseño del sistema, los permisos y la evaluación como del modelo subyacente.