Bucles vs. Grafos: Dos formas de arquitecturar agentes de IA
Ingeniería de bucles vs ingeniería de grafos para agentes de IA: cómo funciona cada arquitectura, cuándo elegir una en lugar de la otra, y una lista de verificación para utilizar antes de la producción.
Fuentes: Loop Engineering vs. Graph Engineering: The Architecture Shift Quietly Reshaping AI Agents
Dos términos de moda, una pregunta de arquitectura
Cualquiera que siga a agentes de IA que buscan en la web, llaman a herramientas, escriben código o ejecutan flujos de trabajo por sí solos probablemente haya escuchado recientemente dos términos: ingeniería de bucles e ingeniería de grafos. Suenan a marketing, pero se refieren a una decisión estructural real.
Imaginemos un agente que consume 40,000 tokens y seis minutos en tiempo real para resolver una pregunta que debería resolverse en tres pasos. No hay nada malo con el modelo ni con la instrucción dada. El problema está en el diseño, ya que el agente no puede saber que ya ha intentado algo. Simplemente repite los pasos de pensar, actuar y observar, sin tener registro de cómo es su propio proceso.
Ese tipo de fallo lleva el diseño de agentes más allá de la categoría de instrucciones y lo sitúa dentro de la arquitectura de software. Una vez que se lo ve de esa manera, casi todos los sistemas de agentes desplegados se basan en uno de dos patrones: bucles y grafos. Lo que sigue explica qué es cada uno, cómo se construyen, dónde fallan y por qué el paso de uno a otro cambia la forma en que los ingenieros abordan estos sistemas, más allá de un simple cambio de herramientas.
Qué está haciendo realmente un agente
En cualquier momento dado, un agente realiza una de tres cosas: piensa (una llamada a un LLM), actúa (una llamada a una herramienta) o decide qué hacer a continuación. La ingeniería de agentes consiste en gran medida en conectar esas tres funciones entre sí.
Durante los primeros años de los agentes LLM, casi todos los desarrolladores los diseñaron de la misma manera, como un bucle. Era la opción obvia. Los agentes de estilo ReAct funcionaron así desde el principio, y sigue siendo la forma en que Anthropic describe al agente más simple: un modelo que utiliza herramientas de forma autónoma en un bucle.
Más tarde, los agentes tuvieron tareas más complejas y extensas: varios subagentes especializados, intentos repetidos, aprobaciones humanas y reglas de negocio ramificadas. Un bucle simple comenzó a no ser suficiente para manejar todo eso. Los equipos querían analizar la estructura del proceso en lugar de confiar en que el bucle llegaría a converger al final, y esa necesidad dio origen a la ingeniería de grafos, que representa el proceso mediante nodos y aristas, sin dejarlo implícito en iteraciones repetidas.
Ningún patrón es incorrecto. Cada uno resuelve problemas diferentes, por lo que merece ser analizado adecuadamente.
Una analogía de la cocina
Imagínese enseñando a alguien a cocinar. La ingeniería de bucles consiste en repetir una sola instrucción: probar la sopa, añadir sal si es necesario, probar de nuevo y seguir así hasta que esté lista. Es un ciclo de actuar, verificar y repetir si es preciso. Simple, predecible y fácil de imaginar.
La ingeniería de grafos se asemeja a una receta completa con ramificaciones. Cortar las verduras mientras otra persona hierve agua. Cuando ambas estén listas, combinarlas. Si quien prueba la comida desea más sabor, devolver la olla al paso de sazonar; de lo contrario, servirla. Aquí no existe una única secuencia de pasos. Existen varios caminos, algunas acciones se realizan al mismo tiempo, otras dependen de una decisión, y solo algunas vuelven a repetirse cuando algo no está bien.
Qué significa la ingeniería de bucles
Un bucle es la forma original y más sencilla de crear un agente. Funciona en un ciclo continuo:
- Recibir la entrada, es decir, la pregunta o objetivo del usuario.
- Pensar en qué hacer a continuación, que corresponde al paso de razonamiento del modelo.
- Actuar, lo cual normalmente significa llamar a una herramienta, ejecutar código o buscar información.
- Observar qué ha producido la acción.
- Volver al paso 2 y seguir así hasta que el agente considere que se ha alcanzado el objetivo.
La gente suele denominar esto un ciclo de pensar, actuar y observar, y muchos de los primeros agentes se basaron en él. Como práctica, la ingeniería de bucles trata al agente como un único ciclo repetitivo: el modelo razona, selecciona una acción, la ejecuta, estudia el resultado y lo escribe de vuelta en su propio contexto, para luego repetir el proceso hasta concluir que la tarea está terminada o llegar a un límite.
Algunos puntos explican su popularidad:
- Esto sienta las bases del conocido patrón ReAct (razonamiento combinado con acción) propuesto por Yao y sus colegas, en el cual las huellas del razonamiento se entrelazan con las acciones y un modelo no necesita completar todo su proceso de pensamiento de antemano.
- La mayoría de los marcos de trabajo para agentes también definen un “agente” de esta manera, como un bucle de control con una ventana de contexto compartida e una interfaz para llamar a herramientas.
- Escribir uno solo requiere unas pocas líneas de código. El estado corresponde a la conversación hasta el momento, y existe una única condición de salida. Un asistente de programación que edita un archivo o un agente de investigación que busca hasta estar satisfecho no necesita nada más complejo.
- La guía de Anthropic lo deja claro: comience con el enfoque más simple que funcione, y añada estructura solo cuando la tarea lo exija.
El problema es que todo sobre lo que debe razonar el bucle, incluyendo lo que ya intentó, qué falló y cuál era el objetivo, debe estar dentro de una ventana de contexto que sigue creciendo. El proceso no cuenta con memoria separada; lo único que conserva es un registro de las acciones realizadas.
Cómo se estructura el bucle
El flujo se ejecuta de principio a fin de esta manera.
Paso a paso:
- Una tarea del usuario inicia el bucle con un objetivo específico.
- En la fase de razonamiento, el modelo lee la instrucción del sistema, el historial de la conversación y la última observación, y luego decide qué sucederá a continuación.
- La verificación de “¿Está completada la tarea?” no corresponde a un sistema separado; el propio modelo decide, basándose en su contexto, si ya ha finalizado.
- Si no está terminado, el modelo elige una herramienta y la utiliza.
- El resultado o error de la herramienta se devuelve como una observación.
- Esa observación se agrega al contexto, y el ciclo se reinicia, considerando una historia ligeramente más extensa en cada iteración.
- Cuando el modelo evalúa el trabajo realizado, el bucle finaliza y devuelve la respuesta final.
Una versión compacta en Python muestra cuán poco código se necesita para esto.
def run_agent(task: str, tools: list, max_iterations: int = 10) -> str:
context = [{"role": "user", "content": task}]
for step in range(max_iterations):
response = llm.generate(context, tools=tools)
if response.is_final_answer:
return response.content
tool_result = execute_tool(response.tool_call)
context.append({"role": "assistant", "content": response.content})
context.append({"role": "tool", "content": tool_result})
return "Stopped: max iterations reached"
Qué significa la ingeniería de grafos
La ingeniería de grafos representa de forma explícita el proceso del agente. Consiste en un conjunto de nodos, cada uno una unidad de trabajo como una llamada a un LLM, una llamada a una herramienta o un fragmento de lógica empresarial, conectados por aristas que pueden ser fijas o condicionales. Todos los nodos leen y escriben en un único objeto de estado compartido y tipado. En resumen, el flujo de trabajo se convierte en un mapa de pasos conectados con rutas entre ellos, reemplazando un ciclo repetitivo único.
Un nodo puede ser cualquiera de los siguientes:
- un agente, una IA especializada con una tarea específica como investigación, escritura o análisis
- una llamada a una herramienta, por ejemplo una búsqueda en la web, un cálculo o una consulta a una base de datos
- un punto de decisión que elige la siguiente ruta
- un punto de fusión que combina resultados de varias rutas
Varios caminos pueden ejecutarse en paralelo, y otros son condicionales y se siguen solo si se supera una prueba. Las bucles siguen siendo posibles, pero aparecen únicamente donde son necesarias, como un mecanismo controlado que hace retroceder el proceso unos pasos sin repetir todo ciegamente.
Por qué los grafos son atractivos
- Paralelismo. Las tareas independientes pueden ejecutarse simultáneamente sin esperar en una cola.
- Desarrollo en ramas. El flujo de trabajo puede tomar direcciones diferentes según la situación, en lugar de repetir siempre los mismos pasos.
- Especialización. Cada nodo puede ser un agente especializado con un único enfoque, lo cual se acerca a la forma en que un equipo humano divide el trabajo.
- Reintentos dirigidos. Cuando falla un paso, como una verificación de calidad, solo ese paso envía el trabajo para ser re hecho, sin afectar al resto.
LangGraph es un framework basado en esta idea, que modela los flujos de trabajo como grafos dirigidos cíclicos y con estado. Un grafo aún puede formar bucles, ya que un nodo puede tener un enlace que lo conecte con uno anterior, por lo que las reintentos y las iteraciones son posibles. Lo que cambia es que el bucle se convierte en un solo enlace entre muchos, representado en un mapa que se puede observar, y deja de ser toda la arquitectura.
Esto coincide estrechamente con la distinción que hace Anthropic entre flujos de trabajo, donde los LLM y las herramientas siguen rutas de código predefinidas que controlan los desarrolladores, y los agentes, donde el modelo dirige dinámicamente su propio proceso. Un grafo puede representar ambos en una sola estructura, con rutas fijas donde es importante la previsibilidad y ramas dirigidas por el modelo donde la flexibilidad es ventajosa, y la diferencia se muestra en el diagrama.
Cómo se construye el grafo
Tomemos el mismo tipo de problema: un agente que debe investigar, escribir código y revisar su propio resultado, y reorganicémoslo como un grafo.
Paso a paso:
- START es el punto de entrada al grafo.
- Un nodo de enrutamiento lee el estado actual y elige una ruta. Puede tratarse de un simple
if/else, o de una llamada a un LLM que clasifica la solicitud. - Tres nodos especializados, un agente de investigación, un agente de código y un agente de revisión, son cada uno autónomo: leen el estado, realizan su tarea y escriben los resultados de vuelta.
- Un nodo de agregación o de fusión combina todo lo que produjo la rama ejecutada en un único objeto de estado coherente.
- Un nodo de intento repetido gestiona los fallos en la revisión. Cuando la validación realizada por el agente de revisión falla, un enlace explícito redirige la solicitud al enrutador, y no se vuelve a solicitar simplemente al mismo modelo en su lugar. La ruta es visible en el grafo y no está oculta en una línea de instrucción como “si esto falla, inténtalo de nuevo.”
- Se alcanza el estado END una vez que el estado pasa la validación.
Aquí hay un pseudocódigo simplificado al estilo que suelen adoptar la mayoría de los frameworks de grafos.
from graph_engine import StateGraph, START, END
def router(state: dict) -> str:
return state["task_type"] # "research" | "code" | "review"
def research_agent(state: dict) -> dict:
state["results"]["research"] = do_research(state["query"])
return state
def code_agent(state: dict) -> dict:
state["results"]["code"] = write_code(state["query"])
return state
def review_agent(state: dict) -> dict:
state["valid"] = validate(state["results"])
return state
def aggregator(state: dict) -> dict:
state["final_output"] = merge(state["results"])
return state
graph = StateGraph(schema=AgentState)
graph.add_node("router", router)
graph.add_node("research_agent", research_agent)
graph.add_node("code_agent", code_agent)
graph.add_node("review_agent", review_agent)
graph.add_node("aggregator", aggregator)
graph.add_conditional_edges("router", {
"research": "research_agent",
"code": "code_agent",
"review": "review_agent",
})
graph.add_edge(["research_agent", "code_agent", "review_agent"], "aggregator")
graph.add_conditional_edges("aggregator", {
"valid": END,
"invalid": "router", # explicit retry edge
})
app = graph.compile()
app.invoke({"query": "...", "results": {}, "task_type": "code"})
Al colocar los dos patrones uno al lado del otro, es más fácil observar el contraste.
Por qué la industria está pasando de los bucles a los grafos
El cambio no fue repentino. Los bucles se toparon con verdaderos límites a medida que la gente intentaba crear sistemas más ambiciosos, por varias razones.
El trabajo real no avanza en línea recta. La investigación, el soporte al cliente, el análisis financiero y las cadenas de procesamiento de contenido todos se ramifican. Si la pregunta es sobre facturación, se sigue un camino, y si se trata de un problema técnico, otro. Un bucle fuerza todo eso en una larga cadena de condicionales, lo que se vuelve caótico rápidamente.
Los sistemas multiagente necesitaban una estructura mejor. Una vez que un sistema contaba con varios agentes, como un investigador, un resumidor y un verificador de hechos, un bucle no podía indicar que dos agentes debían trabajar al mismo tiempo o que uno solo debía ejecutarse si fallaba una verificación. Un grafo capta esto de forma natural.
Con el tiempo, la visibilidad y la confianza son más importantes. Antes, cuando los agentes se encargaban de tareas de alto riesgo, los equipos necesitaban una visión paso a paso de lo que ocurría. Se podía dibujar un gráfico al que hacer referencia, mostrando exactamente dónde un proceso había funcionado bien o mal, mientras que un bucle era un bloque opaco que ejecutaba el mismo código veinte veces.
Costo y velocidad. Cada iteración desperdiciada consume tiempo y, a menudo, dinero real, ya que cada paso de razonamiento implica una llamada al modelo de lenguaje. Ejecutar pasos independientes en paralelo y volver a procesar solo la parte que necesita corrección es claramente más eficiente.
Las pruebas y el mantenimiento se simplifican. Se puede crear, probar y modificar un nodo del gráfico uno por uno. Un bucle muy complejo suele seguir una lógica de todo-o-nada, por lo que modificarlo de forma segura después del lanzamiento resulta más difícil.
Elegir entre ellos
A continuación se presenta un marco general para tomar decisiones.
Utilice un bucle cuando:
- el trabajo tiene un único propósito: un agente único, un objetivo único y un conjunto de herramientas únicas
- es necesario verificar un prototipo inicial antes de invertir dinero en la arquitectura
- el número de pasos es bajo y bastante predecible
- una sola persona es responsable de todo y no hay nada que entregar a otro equipo
Utilice un grafo cuando:
- están involucrados dos o más agentes o roles especializados
- las intentonas, soluciones alternativas o aprobaciones humanas necesitan ser auditables
- partes del proceso pueden ejecutarse simultáneamente y luego deben combinarse
- la ejecución debe rastrearse, marcarse con puntos de control o reanudarse desde un punto determinado, algo que una transcripción reproducida no puede ofrecer
- personas o equipos separados son responsables de segmentos distintos, siendo el grafo el acuerdo entre ellos
He aquí una forma útil de evaluar la situación. Si el código de un bucle contiene un comentario como “en este punto ya deberíamos haber intentado X”, eso es una señal de que está modelando un grafo dentro de un bucle de manera incorrecta, y probablemente sea hora de dibujar el grafo.
En realidad no se trata de una elección binaria. Se trata de adaptar la herramienta a la tarea. Un chatbot básico que responde a las preguntas una por una, o un pequeño script que repite una acción clara hasta completarla, son adecuados para un bucle. Una tarea con varias etapas ramificadas, múltiples agentes especializados que colaboran, trabajo paralelizable o la necesidad de tener una visión clara de lo que ocurrió y por qué, es adecuada para un grafo. Una opción razonable por defecto es comenzar con un bucle y pasar a un grafo en el momento en que la lógica “si esto, entonces aquello” se vuelva difícil de seguir.
Lista de verificación para producción
Antes de implementar cualquiera de estos patrones, estos hábitos son muy útiles:
- Establezca un límite para los pasos. Ambos patrones necesitan un disyuntor, ya que un agente sin límite no tiene un techo en la factura.
- Haga que la condición de “finalización” sea verificable. La condición de salida debe ser algo que una prueba pueda comprobar, nunca una suposición que forme el modelo.
- Instrumente cada paso. Asigne a cada llamada al LLM y a cada llamada a una herramienta su propio span de OpenTelemetry o similar, y evite usar un único span para toda la ejecución.
- Versione el grafo. Mantenga las definiciones bajo control de versiones como cualquier código, ya que un cambio sutil en los enlaces modifica silenciosamente el comportamiento.
- Valide el estado en los límites de los nodos. Verifique los esquemas tipados del estado al entrar y salir de cada nodo para detener tempranamente los datos mal formados.
En resumen
Un bucle representa el diseño mínimo, con un único contexto, un ciclo y el modelo que dirige el flujo de control. Es adecuado para agentes simples y de propósito único. Un grafo describe el proceso a través de nodos, estados y conexiones que se pueden dibujar, ramificar, ejecutar en paralelo y reintentar de forma intencionada.
El cambio más profundo no radica en que los grafos sean mejores. Se trata de un paso del pensamiento procedural, que se pregunta qué viene a continuación, al pensamiento declarativo, que se pregunta qué forma tiene el sistema. Los grafos combinan bien con la disciplina de seguimiento y observabilidad que necesitan los sistemas de producción, mientras que los bucles combinan bien con la iteración rápida.
La mayoría de los sistemas de producción terminan siendo grafos construidos a partir de bucles, esencialmente máquinas de estado cuyos nodos son ciclos pequeños al estilo ReAct. Eso hace que estos dos patrones sean diferentes niveles de zoom de una misma arquitectura y no competidores. Para cualquier proyecto actual con agentes, una pregunta pertinente es si todo sigue funcionando como un único bucle largo o si ya es hora de representarlo como un grafo.
Leer más
- De los bucles de agentes a los grafos de flujos de trabajo: estado tipado, puertas de evidencia y recuperación limitada — Por qué los agentes de ejecución prolongada superan las capacidades de un único bucle, y cómo los nodos explícitos, aristas, artefactos tipados, transiciones verificadas y permisos por nodo los hacen confiables.
- Ingeniería de harness para agentes: estado, verificación y control alrededor del modelo — Una visión en tiempo de ejecución de los agentes en producción: por qué los prompts y el contexto no son suficientes, y cómo el estado duradero, la imposición de reglas, la verificación y la observabilidad cierran esa brecha.