Bucles vs. grafos: cómo estructurar tus agentes de IA

Pusiste tu agente en producción para procesar tickets de soporte y a los diez minutos se cayó la red. Si el agente recibe una consulta incompleta y falla al manejar la respuesta, te deja el estado inconsistente o te quema la cuota de APIs externas con reintentos ciegos. La brecha entre una demo que anda bien en local y un sistema real aparece justo ahí: cuando metés componentes probabilísticos como los LLMs dentro de sistemas distribuidos con datos ruidosos.

Para que tu sistema sea predecible, necesitás definir cómo estructurar su lógica interna. En este post te explico las dos formas principales de orquestar un agente (bucles y grafos), analizamos sus tradeoffs técnicos y vas a ver cuándo te conviene implementar cada una según la complejidad de tu caso de uso.

El agente en bucle: simpleza y rapidez, con un límite claro

El modelo de agente en bucle implementa de forma directa el ciclo clásico “Perceive-Reason-Act”. El agente observa el entorno, procesa esa información para tomar una decisión, ejecuta una acción y vuelve a observar de inmediato. Esta estructura te da un desarrollo rápido y un flujo muy fácil de seguir mentalmente.

Así funciona su ciclo básico:

graph TD
    A[Inicio] --> B(Percibir Entorno);
    B --> C{Razonar / Planificar};
    C -- "Decisión de Acción" --> D(Ejecutar Acción);
    D --> E{"¿Tarea Completa?"};
    E -- "No" --> B;
    E -- "Sí" --> F[Fin];

En cada iteración, el agente ejecuta estos cuatro pasos:

1. Percibe (Observe): recopila información del entorno, como leer un email, consultar una base de datos o escuchar un sensor.
2. Razona (Think/Plan): usa un LLM para interpretar lo que percibió, infiere el estado actual y decide la próxima acción según su objetivo predefinido (encadenando prompts o usando herramientas).
3. Actúa (Act): ejecuta la acción que decidió, como mandar un email, modificar un registro o llamar a una API externa.
4. Repite: reinicia el ciclo percibiendo el nuevo estado del sistema.

Las ventajas principales de este enfoque son tres:

1. Simpleza: resulta fácil de implementar y depurar en tareas lineales y predecibles.
2. Rapidez de prototipado: te permite validar ideas y armar pruebas de concepto en poco tiempo.
3. Menor overhead: requiere mucho menos código de orquestación explícita que un grafo.

Sin embargo, esta simpleza muestra límites serios cuando el entorno se vuelve impredecible o cuando necesitás manejar estados complejos:

1. Gestión de estado implícita: el estado se maneja en el contexto del LLM o con variables globales. Si el LLM alucina o falla a mitad de una secuencia, perdés coherencia en el flujo.
2. Recuperación de errores deficiente: si una acción falla (por ejemplo, una API devuelve error 500), el bucle no suele tener vías explícitas para reintentar o escalar. Si no sumás salvaguardas como las que vimos al controlar agentes de IA con un sandbox operativo, podés dejar al sistema atrapado en reintentos infinitos.
   • Ejemplo concreto: imaginá un agente de soporte al cliente que responde preguntas frecuentes. Si recibe la consulta ambigua “¿Ayuda con mi cuenta?” y su herramienta de búsqueda no encuentra resultados directos, entra en un loop: percibe la duda, razona que debe buscar FAQs, busca, percibe “sin resultados” y vuelve a razonar que debe buscar FAQs, sin escalar a un humano ni pedir aclaraciones.
3. Dificultad para bifurcaciones dinámicas: si la ejecución depende de condiciones intermedias (por ejemplo: si el pago falló, reintentar con otro método; si no, confirmar), el bucle se transforma en un if/else anidado dentro del prompt del LLM, volviéndose muy frágil.
4. Auditoría y observabilidad limitadas: cuesta mucho reconstruir el camino exacto que siguió el agente a lo largo de varias iteraciones si el razonamiento del LLM queda como una caja negra.

Orquestación de agentes de IA con grafos: resiliencia y control

Los agentes basados en grafos resuelven estas limitaciones modelando el flujo como una máquina de estados o un grafo dirigido que admite ciclos para reintentos y rutas de fallo. Como documenta Anthropic en su guía sobre diseño de sistemas con agentes, estructurar flujos con pasos discretos y bifurcaciones claras reduce la tasa de error frente a bucles autónomos sin restricciones. Cada nodo representa un paso puntual (validar entrada, llamar a una API, generar respuesta) y las aristas marcan las transiciones según el resultado anterior.

Su mecanismo se apoya en tres componentes:

1. Nodos (Estados/Pasos): cada nodo encapsula una unidad de trabajo aislada (una llamada al LLM, una herramienta, una consulta a base de datos o una decisión lógica).
2. Aristas (Transiciones): definen cómo se mueve el control entre nodos de forma incondicional o condicional según el resultado previo, permitiendo bifurcaciones explícitas.
3. Estado explícito: los datos recopilados, respuestas y errores se guardan en un objeto estructurado que viaja entre nodos. Esto facilita auditorías y recuperaciones, algo clave si aplicás spec-driven development en agentes de IA.

Así se ve un flujo con manejo explícito de excepciones y escalado:

graph TD
    A[Inicio] --> B("Validar Entrada Usuario");
    B -- "Entrada Válida" --> C("Procesar Solicitud con LLM");
    B -- "Entrada Inválida" --> D("Solicitar Aclaración");
    C -- "Éxito LLM" --> E("Ejecutar Acción Externa");
    C -- "Fallo LLM" --> F("Reintentar LLM");
    F -- "Éxito Reintento" --> E;
    F -- "Fallo Reintento" --> G("Escalar a Humano");
    E -- "Éxito Acción" --> H("Confirmar Éxito");
    E -- "Fallo Acción" --> I("Notificar Error/Rollback");
    D --> J("Fin con Aclaración");
    H --> J;
    I --> J;
    G --> J;

Este enfoque ofrece ventajas operativas claras:

1. Tolerancia a fallos: definís caminos dedicados para reintentos, rollbacks y escalado humano ante cada fallo puntual.
2. Gestión de estado explícita: como el estado pasa estructurado entre nodos, el sistema es transparente, auditable y fácil de recuperar.
3. Flexibilidad en bifurcaciones: se adapta de forma natural a procesos no lineales con lógica de negocio condicional.
4. Modularidad: podés modificar y testear cada nodo por separado sin romper el resto del sistema.
5. Observabilidad clara: sabés con exactitud por qué nodo pasó la ejecución y en qué punto ocurrió un error.

También introduce desafíos que tenés que evaluar:

1. Mayor complejidad inicial: diseñar la máquina de estados lleva más tiempo de desarrollo que armar un bucle simple.
2. Overhead de orquestación: necesitás infraestructura para persistir el estado y resolver transiciones. Frameworks como LangGraph resuelven esto con motores de ejecución que soportan ciclos y checkpoints.
3. Depuración en grafos grandes: si el grafo crece demasiado y las transiciones no están bien delimitadas, seguir el flujo completo puede volverse complejo.

Bucle vs. grafo: un cuadro comparativo de tradeoffs

La elección técnica depende de la complejidad de tu flujo. Evaluá estos tradeoffs:

Característica	Agente en bucle	Agente basado en grafo
Complejidad	Baja en flujos simples	Mayor diseño inicial, pero manejable
Robustez	Baja ante errores no previstos	Alta por manejo explícito de rutas
Gestión de estado	Implícita en variables o contexto LLM	Explícita mediante paso de estado entre nodos
Manejo de errores	Reactivo y con riesgo de loops infinitos	Proactivo con reintentos y rutas de fallo
Flexibilidad	Rígida al bifurcar	Alta para flujos dinámicos condicionales
Observabilidad	Baja al trazar decisiones intermedias	Alta con visibilidad por cada nodo
Mantenibilidad	Cae rápido al sumar lógica condicional	Alta gracias a la modularidad por pasos
Casos de uso ideal	Tareas lineales (resumir, clasificar)	Procesos multi-paso críticos con integraciones

Cuándo elegir cada enfoque y principios de diseño

La arquitectura que elijas impacta de forma directa en la estabilidad y en la factura de tus modelos.

Elegí un bucle si:

1. El flujo de trabajo es lineal y predecible.
2. Estás armando un MVP o prototipo donde la complejidad de la tarea es baja.
3. Te alcanza con reintentos simples o tolerás que un humano revise fallos aislados.

• Ejemplo: un agente que toma un texto de soporte, lo traduce y lo guarda en la base de datos.

Elegí un grafo si:

1. Construís flujos críticos donde la tolerancia a fallos es prioritaria.
2. Tenés procesos complejos con bifurcaciones, reintentos estructurados o escalado humano.
3. Necesitás auditoría paso a paso y control estricto del estado.
4. Integrás varias APIs externas que pueden fallar de forma independiente.

• Ejemplo: un agente que automatiza compras validando stock, procesando el pago (con reintentos y fallback a otro proveedor), emitiendo la factura y notificando al usuario.

Sin importar la opción que uses, aplicá siempre estos seis principios de ingeniería:

1. Modularidad: desacoplá cada paso en funciones independientes para simplificar pruebas unitarias.
2. Observabilidad: guardá logs y métricas de cada iteración del bucle o cada transición del grafo.
3. Manejo explícito de errores: no le pidas al LLM que resuelva sus propios fallos; definí reintentos con backoff exponencial y derivación a operadores.
4. Idempotencia: hacé que las llamadas críticas (como cobros o mutaciones en bases de datos) se puedan repetir sin duplicar efectos secundarios.
5. Pruebas sobre rutas de fallo: diseñá tests que fuercen errores de red y entradas malformadas, no solo el camino feliz.
6. Gestión de contexto: limpiá y seleccioná la información que le pasás al LLM en cada etapa para no saturar la ventana de contexto.