flowchart LR
A[Entrada] --> B[Modelo]
B --> C[Salida]
El bucle del agente
Cómo un agente avanza por iteraciones de observar, decidir, actuar, evaluar, corregir y continuar o pedir ayuda.
Ya sabemos que un agente no se define por producir una respuesta más larga ni por parecer humano.
Se define por una arquitectura de trabajo orientada a objetivos.
Ahora necesitamos observar su movimiento interno.
Si un agente recibe:
Revisa este expediente y prepara lo necesario para la decisión.
no debería intentar resolver necesariamente todo mediante una sola generación.
Debe poder avanzar por etapas.
Observa qué tiene.
Selecciona un siguiente paso.
Ejecuta una acción.
Comprueba qué ocurrió.
Actualiza su estado.
Y decide nuevamente.
Ese patrón repetido es el bucle del agente.
Idea central
Un agente no «hace todo de una vez».
Avanza mediante una iteración controlada:
observar → decidir → actuar → evaluar → corregir → continuar o pedir ayuda.
La unidad básica ya no es solamente la respuesta final, sino el paso y la transición hacia el siguiente paso.
Del flujo lineal al ciclo
En una interacción simple podemos representar el trabajo así:
En un agente necesitamos una representación cíclica:
flowchart LR
A[Observar] --> B[Decidir]
B --> C[Actuar]
C --> D[Evaluar]
D --> E{¿Qué corresponde?}
E -- continuar --> A
E -- corregir --> B
E -- pedir ayuda --> F[Humano o sistema externo]
E -- terminar --> G[Cierre]
La diferencia fundamental es que la salida de una etapa modifica la entrada de la siguiente.
El agente no sólo produce resultados.
Los incorpora a la trayectoria.
Google describe una secuencia equivalente mediante misión, observación del entorno, análisis/planificación, acción y nueva observación. Las clases UDD la simplifican deliberadamente para un público no técnico en seis verbos: observar, decidir, actuar, evaluar, corregir y continuar o pedir ayuda.
Ésa será nuestra estructura.
Observar
El primer paso consiste en construir una representación suficientemente útil del estado actual.
Observar no significa percepción humana.
Significa recibir o recuperar información relevante sobre la tarea y sobre el resultado de operaciones anteriores.
El agente puede observar:
- el mensaje del usuario;
- documentos disponibles;
- estado del expediente;
- resultados de herramientas;
- errores;
- respuestas de APIs;
- cambios en un sistema;
- aprobaciones humanas;
- información recuperada desde una fuente.
Una observación inicial
Supongamos este encargo:
Revisa el proveedor de IA según el playbook contractual.
Estado inicial:
Contrato principal: disponible
DPA: disponible
SLA: desconocido
Cuestionario seguridad: disponible
Criticidad: alta
Datos personales: síAntes de hacer cualquier cosa, el sistema ya dispone de una «escena» que condiciona el trabajo.
Observar después de actuar
El agente busca el SLA.
La herramienta devuelve:
Resultado 1: SLA_Proveedor_2024.pdf
Resultado 2: SLA_Proveedor_2026_DRAFT.pdfAhora existe nueva información.
Pero encontrar archivos no resuelve todavía la tarea.
El sistema debe interpretar:
- ¿cuál es aplicable?;
- ¿el borrador está firmado?;
- ¿la versión 2024 sigue vigente?;
- ¿falta un documento definitivo?
El resultado de una herramienta es una observación, no necesariamente una conclusión.
La calidad de la observación limita todo lo que viene después
Si el agente observa un estado incompleto, las decisiones posteriores pueden estar mal fundadas.
Por eso en trabajo jurídico debemos prestar atención a:
- procedencia;
- vigencia;
- completitud;
- identidad del documento;
- permisos de acceso;
- relación con el expediente correcto.
Un agente no puede corregir con razonamiento sofisticado un documento que nunca recibió.
Decidir
Después de observar, el sistema debe seleccionar qué hacer a continuación.
Utilizamos decidir en sentido operacional.
No significa voluntad ni juicio moral.
Significa que la arquitectura selecciona una alternativa entre próximos pasos posibles.
Decisión simple
Estado:
DPA: disponible
SLA: faltante
Riesgo de continuidad: pendienteAcciones permitidas:
A. buscar SLA
B. revisar DPA
C. preparar informe final
D. pedir aprobaciónEl sistema puede seleccionar:
A. buscar SLA
porque la evaluación de continuidad requiere ese documento.
Decidir con restricciones
La selección nunca debería leerse aisladamente del control.
Tal vez también existe una acción:
E. escribir al proveedor solicitando SLAPero esa acción requiere autorización.
Entonces el sistema puede decidir:
«Necesito el SLA.»
sin poder ejecutar autónomamente:
«Enviar correo al proveedor.»
Puede preparar el correo y pedir aprobación.
La decisión sobre el próximo paso se mantiene dentro de un espacio permitido.
Decidir no es siempre planificar todo
Un agente puede seleccionar un paso local sin generar un plan completo.
Por ejemplo:
«Primero debo identificar qué documentos existen.»
Después de observarlos decide nuevamente.
En otros sistemas puede existir planificación más explícita.
La página sobre agente planificador desarrollará esa capacidad.
Aquí basta reconocer que cada iteración necesita una transición.
Actuar
Una vez seleccionado el paso, el sistema realiza una operación.
La acción puede ser muy sencilla:
- generar una clasificación;
- recuperar un fragmento;
- llamar una herramienta;
- ejecutar una consulta;
- crear un registro;
- preparar un borrador.
O puede producir efectos externos:
- enviar un mensaje;
- actualizar una base;
- modificar permisos;
- activar un workflow;
- ejecutar una operación sobre otro sistema.
Acciones informativas y acciones efectivas
Para gobernar agentes conviene distinguir al menos dos grandes categorías.
Acciones informativas producen o recuperan información.
Ejemplos:
- leer contrato;
- buscar política;
- calcular plazo;
- resumir documento.
Acciones efectivas modifican algo fuera del contexto interno del agente.
Ejemplos:
- enviar correo;
- crear ticket;
- cambiar estado contractual;
- actualizar permisos.
La segunda categoría suele requerir mayor control porque el error puede propagarse hacia el mundo organizacional.
La herramienta ejecuta; el agente selecciona
Una distinción ya enseñada debe mantenerse:
TOOL ≠ AGENT.
La herramienta puede tener una función definida:
buscar documento por nombre.
El agente determina:
cuándo necesita buscar y qué hacer con el resultado.
No conviene atribuir a la tool la lógica global de la tarea ni al agente la ejecución física de cada operación.
Evaluar
Una acción no demuestra éxito sólo porque se ejecutó.
Después de actuar necesitamos evaluar el resultado.
Preguntas mínimas:
- ¿la acción terminó correctamente?;
- ¿produjo lo que esperábamos?;
- ¿el resultado es pertinente?;
- ¿es suficiente?;
- ¿cambia el estado de la tarea?;
- ¿aparece un error o contradicción?;
Ejemplo: herramienta técnicamente exitosa, resultado inútil
El agente ejecuta:
buscar «DPA proveedor».
La herramienta responde sin error y devuelve tres archivos.
Desde el punto de vista técnico, la llamada fue exitosa.
Pero los documentos corresponden a otro proveedor.
La evaluación debe distinguir:
ÉXITO DE EJECUCIÓN
la herramienta respondió
ÉXITO DE TAREA
la información obtenida sirve para el objetivoNo son equivalentes.
Resultado formalmente correcto, contenido insuficiente
Lo mismo ocurre con un output estructurado.
La herramienta puede devolver:
{
"sla": "encontrado",
"version": "2024"
}El JSON es válido.
Pero todavía falta saber si ese SLA está vigente.
Recordemos la distinción transversal del curso:
forma correcta ≠ contenido correcto ≠ evidencia suficiente.
Evaluación local y evaluación global
El agente puede evaluar un paso:
«Encontré el documento correcto.»
Y también el objetivo completo:
«Aún no puedo cerrar porque falta aprobación de seguridad.»
Ambos niveles importan.
Corregir
La posibilidad de corregir la trayectoria es uno de los rasgos que hacen interesante la agencia.
Un plan inicial puede dejar de ser adecuado cuando aparece nueva información.
Un ejemplo
Plan inicial:
1. revisar contrato
2. revisar DPA
3. revisar SLA
4. preparar matrizDurante la etapa 1 aparece una cláusula que indica:
el servicio incorpora procesamiento biométrico opcional.
Eso cambia el problema.
El sistema puede necesitar:
- identificar si la función será utilizada;
- activar una revisión adicional;
- buscar documentación técnica;
- escalar a privacidad o seguridad.
Seguir mecánicamente el plan original podría omitir una cuestión material.
Corregir no significa inventar nuevas competencias
El agente puede cambiar de ruta sólo dentro de su alcance.
Si detecta un problema tributario para el cual no dispone de skill, fuente ni herramienta adecuada, la corrección correcta puede ser:
escalar a especialista.
No:
improvisar una nueva especialidad.
Corregir un error de herramienta
Supongamos que una API falla.
El sistema puede:
- volver a intentar una vez;
- utilizar un mecanismo alternativo autorizado;
- registrar el error;
- pedir ayuda.
Lo que no debería hacer es entrar en un bucle indefinido.
Continuar o pedir ayuda
Después de evaluar y, si corresponde, corregir, el agente debe escoger entre varias salidas del ciclo.
Continuar
Cuando existe un próximo paso válido:
hallazgo incompleto
→ existe herramienta autorizada
→ evidencia disponible
→ continuarTerminar
Cuando se cumple la condición de cierre:
materias revisadas
+ evidencia completa
+ pendientes resueltos o escalados
+ salida preparada
→ cerrarPedir información
Cuando falta una entrada que el sistema no puede obtener:
«Necesito saber si esta funcionalidad será utilizada por usuarios externos.»
Pedir aprobación
Cuando la acción siguiente existe, pero no está autorizada automáticamente:
«Preparé el correo al proveedor. ¿Autorizas el envío?»
Escalar
Cuando el asunto excede criterios o umbrales:
«La cláusula crea una excepción ilimitada al cap de responsabilidad. El playbook exige aprobación del Legal Director.»
Abstenerse
Cuando el sistema no tiene una ruta segura:
«No puedo determinar la vigencia del documento con las fuentes disponibles.»
Pedir ayuda es parte del bucle
Una arquitectura madura no trata la intervención humana como un accidente.
Puede diseñarla como una transición normal del sistema.
El agente no fracasa por pedir ayuda cuando el caso supera sus límites.
Fracasa si continúa como si los límites no existieran.
El bucle completo sobre un contrato
Sigamos una ejecución hipotética.
Iteración 1
Observar
Contrato disponible. No hay listado de anexos.
Decidir
Identificar referencias a documentos complementarios.
Actuar
Ejecutar extracción de referencias.
Evaluar
Aparecen DPA, SLA y Security Addendum.
Corregir
La tarea inicial asumía sólo contrato principal; ahora debe incorporar anexos.
Continuar
Buscar anexos.
Iteración 2
Observar
DPA y SLA disponibles. Security Addendum no encontrado.
Decidir
Buscar en repositorio secundario autorizado.
Actuar
Ejecutar búsqueda.
Evaluar
No aparece documento.
Corregir
Registrar falta de evidencia.
Continuar o pedir ayuda
Preparar solicitud del documento y pedir autorización para enviarla.
Iteración 3
Observar
Mientras espera autorización, puede revisar materias no dependientes del Security Addendum.
Decidir
Ejecutar revisión de responsabilidad.
Actuar
Comparar cláusula con playbook.
Evaluar
Desviación alta.
Corregir
Activar ruta de escalamiento.
Pedir ayuda
Solicitar aprobación jurídica.
La trayectoria no estaba completamente escrita desde el comienzo.
Se fue construyendo a partir de observaciones.
El bucle no debe confundirse con «chain of thought»
Para un principiante puede parecer que el ciclo del agente es simplemente «hacer que el modelo piense paso a paso».
No es lo mismo.
El bucle que nos interesa contiene eventos externos observables:
llamada de herramienta
resultado
cambio de estado
selección de próxima acción
aprobación
error
cierreNo necesitamos registrar ni exponer razonamiento interno privado del modelo para reconstruir la trayectoria operacional.
La observabilidad de un agente puede concentrarse en:
- entradas relevantes;
- herramientas seleccionadas;
- parámetros;
- respuestas;
- transiciones;
- resultados;
- decisiones de control.
Esto será importante cuando estudiemos logs y traces.
Bucles útiles y bucles peligrosos
No todo ciclo es deseable.
Bucle de corrección útil
buscar documento
→ no encontrado
→ reformular búsqueda
→ encontrado
→ continuarBucle redundante
buscar documento
→ no encontrado
→ misma búsqueda
→ no encontrado
→ misma búsquedaBucle de autoevaluación sin salida
generar
→ criticar
→ reescribir
→ criticar
→ reescribir
→ ...Sin condición de término, la capacidad de iterar puede convertirse en desperdicio.
Bucle peligroso de acción
modificar registro
→ detectar error
→ modificar otro registro
→ intentar corregir
→ producir efectos adicionalesCuanto más impacto tengan las acciones, más importante es limitar iteraciones y exigir aprobación.
Criterios de término
Un agente necesita alguna regla que responda:
¿cuándo basta?
Puede ser:
Término por objetivo
todas las categorías obligatorias fueron revisadas.
Término por evidencia insuficiente
falta documento esencial y no existen fuentes alternativas autorizadas.
Término por control
la próxima acción requiere aprobación.
Término por seguridad
se detectó una condición prohibida.
Término por recursos
se alcanzó máximo de intentos, tiempo o costo.
El criterio debe ser suficientemente explícito para evitar que el sistema confunda perseverancia con eficacia.
El bucle y el trabajo jurídico
En tareas jurídicas la iteración tiene un valor particular porque los expedientes suelen contener dependencias.
Una conclusión puede abrir una nueva pregunta.
Una fuente puede remitir a otra.
Una excepción puede cambiar el análisis de una regla general.
Un documento faltante puede bloquear una conclusión.
Un riesgo puede exigir consulta a otra función.
Por eso un sistema agente puede ser útil para coordinar investigaciones, revisiones y escalamiento.
Pero la misma estructura aumenta la necesidad de trazabilidad.
Si el agente toma quince pasos, necesitamos saber algo más que el último párrafo.
Debemos poder reconstruir:
qué observó
qué decidió
qué herramienta utilizó
qué obtuvo
qué descartó
qué corrigió
por qué continuó
por qué se detuvoLa trayectoria se vuelve una parte del producto.
Un poco más de detalle técnico: estado y transición
Podemos imaginar cada iteración como un cambio de estado.
Estado inicial:
S0 = contrato recibidoDespués de identificar anexos:
S1 = contrato + lista de documentos requeridosDespués de buscar:
S2 = DPA encontrado + SLA encontrado + seguridad faltanteDespués de evaluar:
S3 = privacidad revisada + seguridad bloqueada + responsabilidad altaEl agente selecciona una acción en función del estado actual.
En términos conceptuales:
ESTADO ACTUAL
+
OBJETIVO
+
ACCIONES DISPONIBLES
+
CONTROLES
→ PRÓXIMA ACCIÓNLa acción produce un resultado y ese resultado contribuye a formar un nuevo estado.
No necesitamos programar para comprender esta lógica.
Es suficiente reconocer que un agente fiable necesita mantener consistencia entre estados y transiciones.
Qué debes recordar
El bucle del agente puede resumirse en seis verbos:
observar
construir el estado relevante;
decidir
seleccionar el próximo paso permitido;
actuar
ejecutar una operación;
evaluar
determinar qué produjo realmente;
corregir
ajustar la trayectoria si cambió el problema;
continuar o pedir ayuda
decidir si existe una nueva iteración, si corresponde escalar o si la tarea terminó.
El valor del agente no proviene de repetir indefinidamente este ciclo.
Proviene de iterar con propósito, límites y condiciones de cierre.
El problema que todavía queda abierto
Ya sabemos cómo se mueve un agente.
Ahora necesitamos mirar qué piezas hacen posible ese movimiento.
¿Qué función cumple el modelo?
¿Qué parte corresponde al contexto?
¿Dónde aparecen las herramientas?
¿Quién coordina el ciclo?
¿Dónde se implementan los controles?
La página siguiente descompone el sistema en su anatomía: modelo, contexto, herramientas, orquestación y controles.