flowchart TB
O[Objetivo]
C[Contexto]
M[Modelo]
T[Herramientas]
OR[Orquestación]
CT[Controles]
R[Resultado / nuevo estado]
O --> OR
C --> M
OR --> M
M --> OR
OR --> T
T --> R
R --> OR
OR --> C
CT -. limita y valida .-> OR
CT -. limita .-> T
Anatomía de un agente
Cinco piezas para dejar de mirar al agente como una caja negra: modelo, contexto, herramientas, orquestación y controles.
En las páginas anteriores construimos la idea de agente desde su comportamiento.
Primero vimos que un agente no se limita a responder: mantiene un objetivo durante varios pasos. Después definimos el agente como un sistema que trabaja en un ciclo. Finalmente observamos ese ciclo en movimiento: observar, seleccionar un próximo paso, actuar, evaluar y continuar o pedir ayuda.
Ahora necesitamos cambiar nuevamente de perspectiva.
Ya no preguntaremos solamente qué hace un agente.
Preguntaremos:
¿de qué está hecho el sistema que permite que ese comportamiento ocurra?
La pregunta es importante porque la expresión agente de IA puede crear la impresión de que existe una pieza única —“el agente”— que recibe un encargo y actúa. En una aplicación real, lo que llamamos agente suele ser una composición de componentes con funciones distintas.
El material del curso utiliza cinco piezas para hacer visible esa arquitectura:
modelo, contexto, herramientas, orquestación y controles.
Idea central
Un agente no es solamente un modelo conectado a herramientas.
Para comprenderlo necesitamos distinguir al menos cinco preguntas:
- Modelo: ¿qué componente produce lenguaje, clasificaciones o selecciones probables?
- Contexto: ¿qué información tiene disponible para este paso?
- Herramientas: ¿qué puede consultar o ejecutar fuera del modelo?
- Orquestación: ¿qué mantiene unido el ciclo y coordina las transiciones?
- Controles: ¿qué limita, valida, registra o detiene el trabajo?
El valor de esta anatomía no está en memorizar cinco palabras. Está en poder localizar dónde se encuentra una capacidad, una decisión o una falla.
Una arquitectura, no un personaje
Cuando una interfaz muestra:
“El agente está revisando su contrato…”
puede estar ocurriendo algo mucho más descompuesto.
Por ejemplo:
- la aplicación recibe el contrato;
- una capa de software prepara el texto y el estado del caso;
- el modelo recibe instrucciones y ciertos documentos;
- el modelo devuelve una selección: “buscar el DPA”;
- la orquestación comprueba si existe una herramienta autorizada para hacerlo;
- la herramienta consulta el repositorio;
- el resultado se incorpora al siguiente contexto;
- el modelo vuelve a ser llamado;
- una regla exige aprobación humana antes de enviar cualquier comunicación externa.
Desde fuera podemos percibir una sola acción continua.
Desde dentro existen varias piezas con responsabilidades distintas.
Podemos representarlo de manera simplificada así:
El diagrama no pretende describir todas las implementaciones posibles. Sirve para una pregunta más práctica: ¿qué componente está haciendo qué?
1. Modelo: el motor probabilístico
El modelo es el componente que aporta capacidades como generación, clasificación, extracción, comparación o selección de próximos pasos.
En un agente basado en un LLM, por ejemplo, el modelo puede recibir:
- el objetivo actual;
- instrucciones;
- información del expediente;
- una lista de herramientas disponibles;
- resultados de pasos anteriores;
para producir una salida útil para la orquestación.
Esa salida podría ser texto:
“Falta el anexo de tratamiento de datos.”
Pero también podría expresar una acción estructurada:
“usar la herramienta
buscar_documentocon el parámetroDPA.”
La distinción importa porque el modelo no tiene por qué ejecutar físicamente la acción. Puede proponer o seleccionar una operación que otra parte del sistema ejecutará.
Un modelo potente no resuelve toda la arquitectura
Es fácil concentrar el análisis del agente en la pregunta:
“¿Qué modelo usa?”
La pregunta importa, pero es insuficiente.
Dos agentes pueden utilizar exactamente el mismo modelo y comportarse de manera radicalmente distinta porque reciben contextos diferentes, tienen herramientas diferentes o están sometidos a controles diferentes.
Imaginemos dos sistemas que utilizan el mismo LLM.
Sistema A recibe solamente el contrato y puede generar texto.
Sistema B recibe el contrato, puede recuperar el playbook interno, consultar anexos y registrar hallazgos, pero no puede enviar comunicaciones sin aprobación.
El modelo es el mismo.
La capacidad operacional no.
Qué conviene evaluar del modelo
En un agente interesa especialmente si el modelo es competente para las funciones que se le asignan.
Si debe elegir herramientas, debe hacerlo con suficiente consistencia.
Si debe clasificar una solicitud para dirigirla a una ruta, debemos evaluar esa clasificación.
Si debe extraer cláusulas antes de que otra etapa las analice, una falla de extracción puede contaminar todo lo que sigue.
Huyen enfatiza precisamente que, en agentes, los errores pueden acumularse a través de varios pasos. Por eso la selección del modelo debe evaluarse respecto de la tarea concreta y no sólo por rankings generales (Huyen, 2025, cap. 6).
2. Contexto: lo que el modelo tiene delante ahora
Un modelo no trabaja con todo lo que existe en la organización.
Trabaja con la información que el sistema pone a su disposición durante una llamada concreta.
Ese conjunto constituye, en términos operativos, el contexto de ese paso.
Puede contener:
- instrucciones de la aplicación;
- la solicitud del usuario;
- fragmentos del contrato;
- una política recuperada;
- estado del expediente;
- resultados de herramientas;
- ejemplos relevantes;
- descripciones de las herramientas que puede utilizar.
El contexto cambia durante el ciclo
Ésta es una de las diferencias más importantes respecto de imaginar un prompt estático.
En el primer paso, el sistema podría disponer sólo de:
Objetivo: revisar el contrato del proveedor.
Documentos disponibles: contrato principal.
Estado: revisión iniciada.Después de buscar en el repositorio, el siguiente contexto podría incorporar:
Resultado de búsqueda:
- DPA encontrado.
- SLA encontrado.
- Anexo de seguridad no encontrado.
Estado actualizado:
- privacidad: pendiente
- seguridad: bloqueada por documento faltanteEl modelo puede seleccionar un paso distinto porque la información disponible cambió.
Contexto no es memoria permanente
No debemos adelantar aquí toda la discusión sobre sesión, RAG y memoria. Basta una frontera mínima.
El hecho de que algo aparezca en el contexto actual no significa que el modelo lo “recuerde” para siempre.
El contexto es una ventana de trabajo preparada para una operación concreta.
Más adelante estudiaremos cómo el sistema decide qué incluir, qué conservar y qué recuperar.
El riesgo de contexto incorrecto
Un modelo puede ejecutar correctamente la operación solicitada sobre un conjunto de información equivocado.
Por ejemplo:
- recibe una versión desactualizada del contrato;
- se incorpora la política de otro cliente;
- se omite un anexo;
- el resultado de una herramienta pertenece a otro expediente;
- una inferencia previa se reintroduce como si fuera un hecho.
Entonces el problema no es necesariamente “el modelo razonó mal”.
Puede ser un problema de construcción de contexto.
3. Herramientas: capacidades para percibir y actuar
Sin herramientas, un agente puede seguir existiendo, pero su capacidad queda mucho más limitada.
Las herramientas permiten al sistema obtener información o producir efectos fuera de la generación del modelo.
Las clases utilizan una analogía útil: las herramientas son las manos del agente.
La analogía ayuda porque distingue entre:
- generar una intención de acción;
- tener un mecanismo para ejecutarla.
Pero deja de servir si parece sugerir que el modelo tiene acceso libre y directo a todo. En un sistema bien diseñado, las herramientas tienen interfaces, permisos, parámetros y controles propios.
Herramientas para leer
Pueden permitir:
- buscar en una base documental;
- abrir un PDF;
- consultar un expediente;
- recuperar una política;
- leer un correo autorizado.
Estas herramientas amplían lo que el sistema puede observar.
Herramientas para producir efectos
Otras permiten:
- crear un borrador;
- completar una planilla;
- actualizar un ticket;
- registrar un hallazgo;
- enviar una comunicación;
- modificar un estado.
Aquí aparece una distinción que más adelante desarrollaremos con detalle: leer no tiene el mismo impacto que escribir o ejecutar una acción externa.
Inventario de herramientas
Huyen denomina tool inventory al conjunto de herramientas disponibles para el agente. La idea es útil porque obliga a hacer explícita una propiedad básica:
un agente sólo puede utilizar las capacidades que su sistema le proporciona.
Si debe comprobar una norma vigente pero no tiene acceso a una fuente jurídica, su planificación puede ser correcta y aun así resultar imposible de ejecutar.
Por el contrario, entregar herramientas innecesarias amplía el espacio de acciones y puede hacer más difícil seleccionar correctamente.
4. Orquestación: lo que mantiene unido el trabajo
La orquestación es probablemente la pieza menos visible para un usuario y una de las más importantes para comprender el sistema.
Podemos pensarla como la lógica que coordina:
- qué información se prepara;
- cuándo se llama al modelo;
- qué salida se espera;
- cómo se interpreta esa salida;
- qué herramienta se ejecuta;
- cómo se incorpora el resultado;
- qué estado se actualiza;
- si debe repetirse el ciclo;
- si corresponde detenerse o escalar.
Google describe la orquestación como la capa que ejecuta el ciclo del agente y gestiona su comportamiento. En el marco de este curso utilizamos una idea equivalente, pero evitando suponer que toda transición debe quedar entregada al modelo.
Parte dinámica y parte determinista
Éste es un punto crucial.
Un agente puede contener decisiones dinámicas y reglas completamente fijas.
Por ejemplo:
Dinámico: seleccionar si el próximo análisis relevante es privacidad, seguridad o propiedad intelectual según el contenido encontrado.
Determinista: toda comunicación externa requiere aprobación humana.
O:
Dinámico: elegir qué documento buscar a continuación.
Determinista: nunca consultar expedientes de otro cliente.
La agencia no exige que todo sea probabilístico.
Una buena arquitectura puede reservar flexibilidad donde aporta valor y utilizar reglas duras donde necesitamos certeza.
Orquestación no es lo mismo que modelo
Si una aplicación siempre ejecuta los pasos A, B y C porque fueron programados así, no debemos decir que “el modelo decidió” esa secuencia.
Puede existir una llamada al modelo dentro de cada paso sin que el modelo controle el orden.
Del mismo modo, un modelo puede seleccionar una herramienta, pero la orquestación puede rechazar esa selección porque no está permitida.
Esta distinción ayuda a reconstruir responsabilidades técnicas.
5. Controles: la frontera de la capacidad
La quinta pieza evita una lectura ingenua de las cuatro anteriores.
Un agente no queda gobernado solamente porque tenga un objetivo claro y herramientas bien descritas.
Necesitamos mecanismos que determinen qué puede ocurrir, bajo qué condiciones y qué evidencia queda.
En esta página utilizaremos controles en un sentido amplio para incluir:
- límites de herramientas;
- permisos;
- validaciones;
- restricciones de acceso;
- reglas de parada;
- revisión humana;
- evaluación;
- registro de eventos relevantes.
No desarrollaremos todavía cada uno de estos temas. Tienen páginas propias más adelante.
Instrucción no equivale a control
Podemos decir al modelo:
“No envíes ningún correo sin autorización.”
Eso es una instrucción útil.
Pero, si la acción es importante, puede ser preferible que la aplicación no exponga la herramienta de envío hasta que exista una aprobación válida.
La diferencia puede representarse así:
INSTRUCCIÓN
"no hagas X"
CONTROL
"el sistema no permite X sin condición Y"La primera intenta orientar la selección del modelo.
La segunda limita el espacio de acción disponible.
Control también significa saber detenerse
Un límite puede consistir en obligar al sistema a detenerse cuando:
- falta un documento indispensable;
- una clasificación es incierta;
- el asunto está fuera de alcance;
- una acción requiere autorización;
- existe una contradicción no resuelta.
En agentes, detenerse correctamente es parte del diseño.
Cómo se relacionan las cinco piezas
La anatomía adquiere valor cuando dejamos de ver las piezas por separado.
Volvamos al caso conductor:
“Llegó un contrato de proveedor de IA. Prepara la revisión necesaria antes de la decisión.”
Modelo
Clasifica información, genera análisis y puede seleccionar próximos pasos.
Contexto
Recibe el contrato, criterios, estado del caso y resultados relevantes.
Herramientas
Puede buscar anexos, leer documentos y registrar hallazgos.
Orquestación
Gestiona las llamadas, actualiza el estado y conecta resultados con nuevos pasos.
Controles
Impiden acciones fuera de alcance, exigen evidencia y reservan decisiones determinadas a una persona.
Podemos observar una ejecución concreta:
1. CONTEXTO
Contrato principal disponible. DPA no localizado.
2. MODELO
Selecciona: buscar DPA.
3. ORQUESTACIÓN
Valida que la herramienta está disponible.
4. HERRAMIENTA
Busca en repositorio autorizado.
5. RESULTADO
DPA encontrado.
6. ORQUESTACIÓN
Actualiza estado e incorpora documento al nuevo contexto.
7. MODELO
Selecciona: revisar tratamiento de datos.
8. CONTROL
Si aparece uso secundario no aprobado, exigir revisión humana.Aquí aparece con claridad una idea central: el comportamiento del agente es emergente de la interacción entre componentes, no una propiedad exclusiva del modelo.
Diagnosticar fallas por capa
La anatomía también sirve para investigar errores.
Supongamos que el informe final afirma que no existe DPA, aunque el documento estaba en la carpeta.
Podemos preguntar:
Modelo: ¿seleccionó correctamente la búsqueda?
Contexto: ¿sabía que debía comprobar la existencia del DPA?
Herramienta: ¿buscó correctamente?
Orquestación: ¿incorporó el resultado de la herramienta?
Control: ¿existía una regla que prohibiera cerrar el expediente con documentos obligatorios pendientes?
La etiqueta “falló la IA” desaparece y se convierte en preguntas verificables.
Qué no debemos concluir todavía
Esta anatomía nos permite ver el sistema, pero todavía no responde cuánto puede decidir cada agente.
Un sistema puede tener exactamente estas cinco piezas y continuar siendo muy asistido.
Otro puede utilizar la misma arquitectura con capacidad mucho mayor para seleccionar y ejecutar acciones.
La diferencia no se explica solamente por la anatomía.
Se explica por el grado de autonomía que el diseño concede dentro de esa anatomía.
Qué debes recordar
Un agente se comprende mejor cuando dejamos de tratarlo como una unidad indivisible.
El modelo aporta capacidades probabilísticas.
El contexto determina qué información tiene disponible en cada paso.
Las herramientas amplían lo que puede observar o hacer.
La orquestación coordina el ciclo y las transiciones.
Los controles delimitan, validan y supervisan la operación.
La misma pregunta puede entonces formularse de manera mucho más precisa:
“¿Por qué el agente hizo esto?”
se convierte en:
“¿qué recibió el modelo, qué seleccionó, qué permitió la orquestación, qué herramienta se ejecutó y qué control debía intervenir?”
El problema que todavía queda abierto
Ya podemos abrir la caja y distinguir sus piezas.
Ahora debemos responder una pregunta distinta:
¿cuánto puede seleccionar y ejecutar el sistema sin que una persona determine cada paso?
No todos los sistemas que llamamos agentes operan con el mismo grado de autonomía.
La siguiente página construye una escala desde el asistente hasta los sistemas de agentes y muestra por qué más autonomía exige más gobierno.