En este artículo, aprenderá cómo distinguir los flujos de trabajo agentes de los agentes autónomos centrándose en quién posee el flujo de control: un código humano que escribe con anticipación o un modelo de razonamiento en tiempo de ejecución.
Los temas que cubriremos incluyen:
Por qué el verdadero eje que separa estos sistemas es la previsibilidad versus la autonomía, no si hay un LLM involucrado. En qué se diferencian los flujos de trabajo deterministas, los flujos de trabajo orquestados, los agentes reactivos y los sistemas autónomos de múltiples agentes, con código ejecutable que concreta la distinción entre control y flujo. Por qué los flujos de trabajo, y no los agentes totalmente autónomos, dominan la producción hoy en día, y por qué las arquitecturas híbridas son el patrón que se mantiene.
Introducción
Deloitte proyecta que para 2027, hasta el 50% de las empresas que utilizan IA generativa habrán lanzado pruebas piloto o de concepto de IA agente. Se trata de una ola de adopción lo suficientemente grande como para que la palabra "agencial" haya comenzado a cubrir casi cualquier cosa que incluya una convocatoria de LLM, desde un proceso fijo de cinco pasos donde el paso tres llama a GPT para obtener un resumen hasta un sistema totalmente autodirigido que planifica su propio camino sin ningún guión.
Esos no son lo mismo. Tratarlos como intercambiables conduce a uno de dos errores: diseñar excesivamente una tarea simple y bien entendida con autonomía innecesaria, o diseñar insuficientemente un problema genuinamente abierto, forzándolo a entrar en una tubería rígida que se rompe en el momento en que la realidad se desvía del plan.
Anthropic traza la línea fundamental en su artículo ampliamente citado “Construyendo agentes efectivos”: los flujos de trabajo son sistemas donde los LLM y las herramientas se organizan a través de rutas de código predefinidas. Los agentes son sistemas donde los LLM dirigen dinámicamente su propio proceso y uso de herramientas, manteniendo el control sobre cómo realizan una tarea. Todo lo que se incluye en este artículo se detalla debajo de esa distinción.
Esta pieza mapea el espectro completo de flujos de trabajo deterministas, sistemas orquestados, agentes únicos reactivos y sistemas autónomos de múltiples agentes, con código en cada etapa que hace que la diferencia entre control y flujo sea concreta en lugar de abstracta. El código aquí ilustra la arquitectura, no un sistema implementable; El objetivo de cada fragmento es mostrar quién decide qué sucede a continuación, no publicar una característica.
El verdadero eje no es “IA versus no IA”: es previsibilidad versus autonomía
Antes de comparar arquitecturas, vale la pena reemplazar la pregunta equivocada. La pregunta no es "¿este sistema utiliza un LLM?". Casi todo lo hace ahora. Las dos preguntas que realmente importan, tomando prestado un marco que ha ganado fuerza real en los círculos de la arquitectura, son: ¿este proceso necesita ser repetible, auditable y explicable paso a paso? Y: ¿se conoce la ruta correcta de antemano o el sistema necesita descubrirla en tiempo de ejecución?
Un sistema puede depender en gran medida de un LLM y aún tener una estructura completamente determinista: una canalización fija donde un paso llama a un modelo para la generación de texto, pero el siguiente paso está codificado independientemente de lo que regrese. Un sistema también puede ser “agente” con muy poca autonomía real: un ciclo estrictamente programado con sólo dos acciones permitidas y un límite estricto de pasos. La presencia de una llamada LLM no es la señal. La propiedad del flujo de control es.
La propia documentación de patrones de diseño de Google Cloud traza exactamente esta línea operativa: los flujos de trabajo deterministas incluyen tareas con una ruta claramente definida y conocida de antemano, donde los pasos no cambian mucho de una ejecución a la siguiente. Los flujos de trabajo que requieren una orquestación dinámica implican problemas en los que el agente debe determinar la mejor manera de proceder, sin un script predefinido. Ese es el espectro que recorre este artículo, una etapa a la vez.
Flujos de trabajo deterministas
Esta es la línea de base. Un flujo de trabajo determinista tiene una secuencia conocida de pasos decididos en tiempo de diseño, por un humano, en código. Un LLM puede sentarse dentro de cualquier paso (generar texto, clasificar entradas, redactar un resumen), pero no elige lo que sucede después de ejecutar su propio paso. El código de orquestación hace eso, independientemente de lo que devuelva el modelo.
# deterministic_pipeline.py
# Prerequisites: none beyond Python’s standard library
# Run: python deterministic_pipeline.py
def mock_llm_classify(text: str) -> str:
“””
Mock LLM call — stands in for a real API call to keep this example
runnable without an API key. The point is structural: whatever this
returns, the NEXT function that runs is already decided below.
“””
if “refund” in text.lower() or “charge” in text.lower():
return “billing”
return “general”
def extract(raw_input: str) -> str:
“””Step 1 — always runs, always leads to step 2. No branching here.”””
return raw_input.strip()
def classify(cleaned_text: str) -> str:
“””
Step 2 — calls an LLM to produce a label, but the label has no effect
on which function runs next. That’s the deterministic part: the model
fills in a piece of data, it doesn’t influence the route.
“””
label = mock_llm_classify(cleaned_text)
print(f” [classify] LLM returned label=”{label}” (informational only)”)
return cleaned_text
def summarize(cleaned_text: str) -> str:
“””Step 3 — always runs after step 2, regardless of the label from step 2.”””
return f”Summary: {cleaned_text[:40]}…”
def notify(summary: str) -> str:
“””Step 4 — always runs last. The path is fixed at design time.”””
return f”Notification sent: {summary}”
def run_deterministic_pipeline(raw_input: str) -> str:
“””
The control flow here is written entirely by a human, in advance.
Every run takes the identical path: extract -> classify -> summarize -> notify.
The LLM call inside classify() produces a label, but that label is never
used to decide what function runs next — it’s data flowing through a fixed pipe.
“””
step1 = extract(raw_input)
step2 = classify(step1)
step3 = summarize(step2)
step4 = notify(step3)
return step4
if __name__ == “__main__”:
# Two inputs that the LLM would classify completely differently
result_1 = run_deterministic_pipeline(“I want a refund for my last charge”)
result_2 = run_deterministic_pipeline(“What are your business hours?”)
print(f”nResult 1: {result_1}”)
print(f”Result 2: {result_2}”)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
# deterministic_pipeline.py
# Prerequisites: none beyond Python’s standard library
# Run: python deterministic_pipeline.py
def mock_llm_classify ( text : str ) -> str :
“” “
Mock LLM call — stands in for a real API call to keep this example
runnable without an API key. The point is structural: whatever this
returns, the NEXT function that runs is already decided below.
“ “”
if “refund” in text . lower ( ) or “charge” in text . lower ( ) :
return “billing”
return “general”
def extract ( raw_input : str ) -> str :
"" "Paso 1: siempre se ejecuta, siempre conduce al paso 2. Aquí no hay bifurcaciones". ""
devolver entrada_bruta . banda ( )
def clasificar ( texto_limpiado : cadena ) -> cadena :
"" "
Paso 2: llama a un LLM para producir una etiqueta, pero la etiqueta no tiene ningún efecto
sobre qué función se ejecuta a continuación. Esa es la parte determinista: el modelo.
rellena un dato, no influye en la ruta.
" ""
etiqueta = mock_llm_classify ( texto_limpiado )
print ( f " [clasificar] LLM devolvió label="{label}" (solo informativo)" )
devolver texto_limpiado
def resumir ( texto_limpiado : cadena ) -> cadena :
"" "Paso 3: siempre se ejecuta después del paso 2, independientemente de la etiqueta del paso 2." ""
devolver f "Resumen: {texto_limpiado[:40]}…"
def notificar ( resumen : cadena ) -> cadena :
"" "Paso 4: siempre se ejecuta al final. La ruta se fija en el momento del diseño." ""
devolver f "Notificación enviada: {resumen}"
def run_deterministic_pipeline ( raw_input : cadena ) -> cadena :
"" "
El flujo de control aquí lo escribe íntegramente un humano, de antemano.
Cada ejecución toma la misma ruta: extraer -> clasificar -> resumir -> notificar.
La llamada LLM dentro de classify() produce una etiqueta, pero esa etiqueta nunca se
se utiliza para decidir qué función se ejecuta a continuación: son datos que fluyen a través de una tubería fija.
" ""
paso1 = extraer ( entrada_bruta )
paso 2 = clasificar ( paso 1 )
paso 3 = resumir ( paso 2 )
paso 4 = notificar ( paso 3 )
devolver paso 4
si __nombre__ == "__principal__" :
# Dos insumos que el LLM clasificaría de manera completamente diferente
resultado_1 = run_deterministic_pipeline ( "Quiero un reembolso por mi último cargo" )
resultado_2 = run_deterministic_pipeline ( "¿Cuál es su horario comercial?" )
imprimir ( f "nResultado 1: {resultado_1}" )
imprimir ( f "Resultado 2: {resultado_2}" )
Cómo ejecutar: python deterministic_pipeline.py, no se requieren dependencias.
Producción:
[classify] LLM returned label=”billing” (informational only)
[classify] LLM returned label=”general” (informational only)
Result 1: Notification sent: Summary: I want a refund for my last charge…
Result 2: Notification sent: Summary: What are your business hours?…
[ classify ] LLM returned label = ‘billing’ ( informational only )
[ classify ] LLM returned label = ‘general’ ( informational only )
Result 1 : Notification sent : Summary : I want a refund for my last charge . . .
Resultado 2 : Notificación enviada : Resumen : ¿Cuáles son sus horarios de atención ? . . .
Observe lo que sucedió: el LLM simulado clasificó las dos entradas de manera completamente diferente, facturación versus general, y no hizo ninguna diferencia en la ruta que tomó cualquiera de las entradas. Ambos realizaron exactamente las mismas cuatro funciones en el mismo orden. Esa es la definición completa de determinista: la ruta es fija, incluso cuando un LLM está haciendo un trabajo real dentro de uno de los pasos.
Flujos de trabajo orquestados
Este es el término medio que con mayor frecuencia se etiqueta erróneamente como “agencial”, y vale la pena detenerse aquí porque es la línea que la mayoría de las personas realmente cruzan cuando comienzan a usar esa palabra de manera vaga.
Un flujo de trabajo orquestado todavía tiene un gráfico de posibles rutas definidas completamente de antemano, pero la ruta que se toma ahora depende de una decisión en tiempo de ejecución, frecuentemente tomada por una llamada de LLM. Este sigue siendo un flujo de trabajo. Cada rama que se podía tomar fue anticipada y escrita en código por un humano antes de que el sistema se ejecutara. El LLM elige una rama de un menú que escribió otra persona. No inventa un nuevo elemento en ese menú.
Esta es precisamente la categoría de “orquestación dinámica” que Google Cloud separa de los agentes genuinos: el sistema necesita planificar y enrutar, pero dentro de una estructura que un ser humano aún diseña por completo.
# orchestrated_pipeline.py
# Prerequisites: none beyond Python’s standard library
# Run: python orchestrated_pipeline.py
def mock_llm_classify(text: str) -> str:
“””Mock LLM classification call.”””
text_lower = text.lower()
if “refund” in text_lower or “charge” in text_lower:
return “billing”
if “crash” in text_lower or “error” in text_lower or “bug” in text_lower:
return “technical”
return “general”
def extract(raw_input: str) -> str:
return raw_input.strip()
# Three pre-defined downstream handlers. A human wrote all three of these
# in advance. The LLM does not invent a fourth path — it can only select
# among branches that already exist in this code.
def handle_billing(text: str) -> str:
return f”[BILLING TEAM] Routed: {text[:50]}”
def handle_technical(text: str) -> str:
return f”[TECH SUPPORT] Routed: {text[:50]}”
def handle_general(text: str) -> str:
return f”[GENERAL QUEUE] Routed: {text[:50]}”
# The branch map IS the entire decision space. Every key here was written
# by a human ahead of time. The LLM’s job is to pick a key — not define one.
ROUTE_MAP = {
“billing”: handle_billing,
“technical”: handle_technical,
“general”: handle_general,
}
def run_orchestrated_pipeline(raw_input: str) -> str:
“””
Still a workflow, not an agent: every possible path was anticipated
and coded by a human ahead of time, sitting in ROUTE_MAP. The LLM call
decides WHICH pre-built branch executes for this specific input, but
it cannot invent a branch that isn’t already a key in ROUTE_MAP.
“””
cleaned = extract(raw_input)
label = mock_llm_classify(cleaned)
print(f” [route] LLM classified as ‘{label}’ -> dispatching to handle_{label}()”)
handler = ROUTE_MAP.get(label, handle_general)
return handler(cleaned)
if __name__ == “__main__”:
test_inputs = [
“I was charged twice for my refund request”,
“The app keeps crashing with an error on startup”,
“What are your business hours?”,
]
for inp in test_inputs:
result = run_orchestrated_pipeline(inp)
print(f” Result: {result}n”)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# orchestrated_pipeline.py
# Prerequisites: none beyond Python’s standard library
# Run: python orchestrated_pipeline.py
def mock_llm_classify ( text : str ) -> str :
“” “Mock LLM classification call.” “”
text_lower = text . lower ( )
if “refund” in text_lower or “charge” in text_lower :
return “billing”
if “crash” in text_lower or “error” in text_lower or “bug” in text_lower :
return “technical”
return “general”
def extract ( raw_input : str ) -> str :
return raw_input . strip ( )
# Three pre-defined downstream handlers. A human wrote all three of these
# in advance. The LLM does not invent a fourth path — it can only select
# among branches that already exist in this code.
def handle_billing ( text : str ) -> str :
return f “[BILLING TEAM] Routed: {text[:50]}”
def handle_technical ( text : str ) -> str :
devolver f "[SOPORTE TÉCNICO] Enrutado: {texto[:50]}"
def handle_general ( texto : cadena ) -> cadena :
devolver f "[COLA GENERAL] Enrutado: {texto[:50]}"
# El mapa de sucursales ES todo el espacio de decisión. Cada clave aquí fue escrita
# por un humano con anticipación. El trabajo del LLM es elegir una clave, no definirla.
RUTA_MAPA = {
"facturación" : manejar_facturación ,
"técnico" : manejar_técnico ,
"general" : manejar_general ,
}
def run_orchestrated_pipeline ( raw_input : cadena ) -> cadena :
"" "
Sigue siendo un flujo de trabajo, no un agente: se anticiparon todos los caminos posibles
y codificado por un humano con anticipación, sentado en ROUTE_MAP. La convocatoria del LLM
decide QUÉ rama prediseñada se ejecuta para esta entrada específica, pero
no puede inventar una rama que no sea ya una clave en ROUTE_MAP.
" ""
limpiado = extraer ( entrada_bruta )
etiqueta = mock_llm_classify ( limpiado )
print ( f "[ruta] LLM clasificado como '{label}' -> envío a handle_{label}()" )
entrenador de animales = RUTA_MAPA . obtener ( etiqueta , manejar_general )
devolver manejador ( limpiado )
si __nombre__ == "__principal__" :
entradas_prueba = [
"Me cobraron dos veces por mi solicitud de reembolso" ,
"La aplicación sigue fallando con un error al iniciar" ,
"¿Cuál es su horario comercial?" ,
]
para entrada en entradas_prueba :
resultado = run_orchestrated_pipeline ( entrada )
imprimir ( f " Resultado: {resultado}n" )
Cómo ejecutar: python Orchestrated_pipeline.py, no se requieren dependencias.
Producción:
[route] LLM classified as ‘billing’ -> dispatching to handle_billing()
Result: [BILLING TEAM] Routed: I was charged twice for my refund request
[route] LLM classified as ‘technical’ -> dispatching to handle_technical()
Result: [TECH SUPPORT] Routed: The app keeps crashing with an error on startup
[route] LLM classified as ‘general’ -> dispatching to handle_general()
Result: [GENERAL QUEUE] Routed: What are your business hours?
[ route ] LLM classified as ‘billing’ -> dispatching to handle_billing ( )
Result : [ BILLING TEAM ] Routed : I was charged twice for my refund request
[ route ] LLM classified as ‘technical’ -> dispatching to handle_technical ( )
Result : [ TECH SUPPORT ] Routed : The app keeps crashing with an error on startup
[ ruta ] LLM clasificado como 'general' -> despachando a manejar_general ( )
Resultado : [ COLA GENERAL ] Enrutado : ¿Cuáles son sus horarios de atención ?
Esta vez, tres aportes diferentes tomaron tres caminos diferentes; eso es nuevo en comparación con la sección anterior. Pero mire ROUTE_MAP: todos los destinos posibles ya estaban escritos en el código antes de que llegara cualquiera de estas entradas. El LLM ejerció su criterio sobre qué clave utilizar. Nunca tuvo la opción de crear una clave que no estuviera allí. Esa distinción (un conjunto fijo de rutas posibles versus una ruta que se inventa en tiempo de ejecución) es exactamente donde comienza la siguiente sección.
Agentes reactivos: el ciclo ReAct y un camino genuinamente abierto
Aquí es donde comienza la verdadera autonomía. El patrón ReAct: razonamiento más actuación, presentado por Yao et al. en 2022: permite que el modelo mismo decida, en cada paso, qué acción tomar a continuación en función de lo que observó en la acción anterior. No existe una rama escrita previamente que cubra todos los casos. El agente opera en un ciclo iterativo de pensamiento, acción y observación hasta que se cumple una condición de salida, y la secuencia en sí (cuántos pasos, en qué orden y qué herramientas) no se puede conocer de antemano. Sólo se fijan las acciones disponibles; el camino a través de ellos no lo es.
Este es el umbral arquitectónico hacia el que se estaban construyendo las dos secciones anteriores. En el flujo de trabajo orquestado, un humano escribió todas las ramas posibles en ROUTE_MAP antes de que se ejecutara el sistema. Aquí, el modelo decide tanto la ruta como la longitud de la secuencia en tiempo de ejecución, aunque el conjunto de herramientas en sí sigue siendo fijo.
# react_loop.py
# Prerequisites: none beyond Python’s standard library
# Run: python react_loop.py
def search_knowledge_base(query: str) -> str:
“””A tool the agent can call. Whether and when it gets called is not
decided here — it’s decided by the model, at runtime.”””
mock_kb = {
“refund policy”: “Refunds are available within 30 days of purchase.”,
“shipping time”: “Standard shipping takes 5-7 business days.”,
}
for key, value in mock_kb.items():
if key in query.lower():
return value
return “No matching information found in knowledge base.”
def escalate_to_human(reason: str) -> str:
“””A second tool the agent can call — again, the decision to call this
instead of the search tool is made by the model, not by this code.”””
return f”Escalated to human agent. Reason: {reason}”
AVAILABLE_TOOLS = {
“search_knowledge_base”: search_knowledge_base,
“escalate_to_human”: escalate_to_human,
}
def mock_llm_decide_next_step(observations: list[str], user_query: str) -> dict:
“””
Mock LLM call standing in for the REASONING step of ReAct.
In a real system, this is an actual model call that reads the full
Thought -> Action -> Observation history and decides what happens next.
Critically: this function — not the calling loop below — decides which
tool to call and when to stop. There is no “if query contains X, call Y”
branch written anywhere in run_react_loop(). The decision is made fresh,
from accumulated context, on every single iteration.
“””
if not observations:
return {
“thought”: “I need to look up the policy before I can answer.”,
“action”: “search_knowledge_base”,
“action_input”: user_query,
}
last_observation = observations[-1]
if “No matching information” in last_observation:
# This branch was never written by a human in advance — the model
# decided, based on what it just observed, that escalation was needed.
return {
“thought”: “The knowledge base has no answer. I should escalate this.”,
“action”: “escalate_to_human”,
“action_input”: “No KB match for: ” + user_query,
}
return {
“thought”: “I found the answer. Task complete.”,
“action”: “finish”,
“action_input”: last_observation,
}
def run_react_loop(user_query: str, max_steps: int = 5) -> str:
“””
Thought -> Action -> Observation, repeated until the model itself decides
to stop. Compare this directly against run_orchestrated_pipeline() in the
previous section: there is no ROUTE_MAP here. There is no human-written
branch saying “if X happened, call Y.” Every decision about what happens
next is made by the model, at runtime, based on what it has observed so far.
“””
observations: list[str] =[]para paso en rango(max_steps): decisión = simulacro_llm_decide_next_step(observaciones, consulta_usuario) print(f" Paso {paso + 1} — Pensamiento: {decisión['pensamiento']}") if decisión["acción"] == "terminar": return f"Respuesta final: {decisión['action_input']}" tool_fn = AVAILABLE_TOOLS.get(decisión["acción"]) if tool_fn es Ninguno: return f"Error: modelo solicitó herramienta desconocida '{decisión['action']}'" observación = tool_fn(decisión["action_input"]) print(f" Paso {paso + 1} — Acción: {decisión['action']}({decisión['action_input']!r})") print(f" Paso {paso + 1} — Observación: {observación}n") observaciones.append(observación) devuelve "Pasos máximos alcanzados sin resolución". if __name__ == "__main__": print("=== Consulta A: responde desde la base de conocimientos ===") result_a = run_react_loop("¿Cuál es la política de reembolso?") print(f"Resultado: {result_a}n") print("=== Consulta B: no está en la base de conocimientos, debería desencadenar una escalada ===") result_b = run_react_loop("¿Pueden procesar mi reembolso de impuestos internacionales en cripto?") print(f"Resultado: {resultado_b}")
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
# reaccionar_loop.py
# Requisitos previos: ninguno más allá de la biblioteca estándar de Python
# Ejecutar: python reaccionar_loop.py
def search_knowledge_base ( consulta : cadena ) -> cadena :
"" "Una herramienta a la que el agente puede llamar. No importa si se llama y cuándo.
decidido aquí: lo decide el modelo, en tiempo de ejecución." ""
simulacro_kb = {
"política de reembolso" : "Los reembolsos están disponibles dentro de los 30 días posteriores a la compra". ,
"tiempo de envío" : "El envío estándar tarda entre 5 y 7 días hábiles". ,
}
para llave , valor en simulacro_kb . elementos ( ) :
si teclear consulta . más bajo ( ) :
devolver valor
devolver "No se encontró información coincidente en la base de conocimientos".
def escalate_to_human ( razón : cadena ) -> cadena :
"" "Una segunda herramienta a la que el agente puede recurrir. Nuevamente, la decisión de llamar a esto
en lugar de la herramienta de búsqueda se hace por el modelo, no por este código." ""
devolver f "Escalado a agente humano. Motivo: {motivo}"
DISPONIBLE_HERRAMIENTAS = {
"base_de_conocimientos_de_búsqueda" : base_de_conocimientos_de_búsqueda ,
"escalar_a_humano" : escalar_a_humano ,
}
def mock_llm_decide_next_step ( observaciones : lista [ cadena ] , consulta_usuario : cadena ) -> dictar :
"" "
Llamada simulada de LLM que reemplaza el paso de RAZONAMIENTO de ReAct.
En un sistema real, esta es una llamada de modelo real que lee el texto completo.
Pensamiento -> Acción -> Historial de observación y decide qué sucede a continuación.
Críticamente: esta función, no el bucle de llamada a continuación, decide qué
herramienta para llamar y cuándo parar. No hay " si" la consulta contiene x , llamar Y "
rama escrita en cualquier lugar de run_react_loop(). La decisión se toma de nuevo,
del contexto acumulado, en cada iteración.
" ""
si no observaciones :
devolver {
"pensamiento" : "Necesito consultar la política antes de poder responder". ,
"acción" : "base_de_conocimientos_de_búsqueda" ,
"entrada_acción" : consulta_usuario ,
}
última_observación = observaciones [ – 1 ]
si "No hay información coincidente" en última_observación :
# Esta rama nunca fue escrita por un humano de antemano: el modelo
# decidió, basándose en lo que acaba de observar, que era necesario intensificar la situación.
devolver {
"pensamiento" : "La base de conocimientos no tiene respuesta. Debería intensificar esto". ,
"acción" : "escalar_a_humano" ,
"entrada_acción" : "No hay coincidencia de KB para: " + consulta_usuario ,
}
devolver {
"pensamiento" : "Encontré la respuesta. Tarea completada". ,
"acción" : "finalizar" ,
"entrada_acción" : última_observación ,
}
def run_react_loop ( consulta_usuario : cadena , max_pasos : entero = 5 ) -> cadena :
"" "
Pensamiento -> Acción -> Observación, repetido hasta que el propio modelo decida
para parar. Compare esto directamente con run_orchestrated_pipeline() en el
sección anterior: no hay ROUTE_MAP aquí. No hay escrito humano
rama que dice " si incógnita sucedió , llamar Y. "Cada decisión sobre lo que sucede
El siguiente paso lo realiza el modelo, en tiempo de ejecución, en función de lo que ha observado hasta el momento.
" ""
observaciones : lista [ cadena ] = [ ]
para entrar rango ( max_steps ) :
decisión = mock_llm_decide_next_step ( observaciones , consulta_usuario )
print ( f " Paso {paso + 1} — Pensamiento: {decisión['pensamiento']}" )
si decisión [ "acción" ] == "finalizar" :
devolver f "Respuesta final: {decisión['action_input']}"
herramienta_fn = DISPONIBLE_HERRAMIENTAS . obtener ( decisión [ "acción" ] )
si herramienta_fn es Ninguno :
devolver f "Error: el modelo solicitó la herramienta desconocida '{decisión['acción']}'"
observación = tool_fn ( decisión [ "action_input" ] )
print ( f " Paso {paso + 1} — Acción: {decisión['acción']}({decisión['acción_input']!r})" )
print ( f " Paso {paso + 1} — Observación: {observación}n" )
observaciones . añadir ( observación )
devolver "Se alcanzaron los pasos máximos sin resolución".
si __nombre__ == "__principal__" :
print ( "=== Consulta A: respondible desde la base de conocimientos ===" )
resultado_a = run_react_loop ( "¿Cuál es la política de reembolso?" )
imprimir ( f "Resultado: {result_a}n" )
print ( "=== Consulta B: no está en la base de conocimientos, debería desencadenar una escalada ===" )
resultado_b = run_react_loop ( "¿Pueden procesar mi reembolso de impuestos internacionales en cripto?" )
imprimir ( f "Resultado: {resultado_b}" )
Cómo ejecutar: python react_loop.py, no se requieren dependencias.
Producción:
=== Query A: answerable from the knowledge base ===
Step 1 — Thought: I need to look up the policy before I can answer.
Step 1 — Action: search_knowledge_base(‘What is the refund policy?’)
Step 1 — Observation: Refunds are available within 30 days of purchase.
Step 2 — Thought: I found the answer. Task complete.
Result: Final answer: Refunds are available within 30 days of purchase.
=== Query B: not in the knowledge base, should trigger escalation ===
Step 1 — Thought: I need to look up the policy before I can answer.
Step 1 — Action: search_knowledge_base(‘Can you process my international tax refund in crypto?’)
Step 1 — Observation: No matching information found in knowledge base.
Step 2 — Thought: The knowledge base has no answer. I should escalate this.
Step 2 — Action: escalate_to_human(‘No KB match for: Can you process my international tax refund in crypto?’)
Step 2 — Observation: Escalated to human agent. Reason: No KB match for: Can you process my international tax refund in crypto?
Step 3 — Thought: I found the answer. Task complete.
Result: Final answer: Escalated to human agent. Reason: No KB match for: Can you process my international tax refund in crypto?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
=== Query A : answerable from the knowledge base ===
Step 1 — Thought : I need to look up the policy before I can answer .
Step 1 — Action : search_knowledge_base ( ‘What is the refund policy?’ )
Paso 1 — Observación : Los reembolsos están disponibles dentro de 30 días de compra .
Paso 2 — Pensamiento : I encontró la respuesta . Tarea completa .
Resultado : Final respuesta : Los reembolsos están disponibles dentro de 30 días de compra .
=== Consulta B : no en la base de conocimientos , debería desencadenar una escalada ===
Paso 1 — Pensamiento : I necesito busque la póliza antes I puede responder .
Paso 1 — Acción : search_knowledge_base ( '¿Pueden procesar mi reembolso de impuestos internacionales en criptografía?' )
Paso 1 — Observación : No se encontró información coincidente en base de conocimientos .
Paso 2 — Pensamiento : La base de conocimientos no tiene respuesta . I debería intensificar esto .
Paso 2 — Acción : escalate_to_human ( 'No hay coincidencia de KB para: ¿Pueden procesar mi reembolso de impuestos internacionales en criptografía?' )
Paso 2 — Observación : Escalado a agente humano . Razón : No hay coincidencia de KB para : ¿ Pueden procesar mi devolución de impuestos internacionales en cripto ?
Paso 3 — Pensamiento : I encontró la respuesta . Tarea completa .
Resultado : Final respuesta : Escalado a agente humano . Razón : No hay coincidencia de KB para : ¿ Pueden procesar mi devolución de impuestos internacionales en cripto ?
Mire lo que difiere entre las dos ejecuciones: la consulta A terminó en dos pasos, la consulta B tomó tres y la consulta B tomó una acción (escalada) que nunca fue codificada como "qué sucede cuando las consultas de reembolso mencionan criptografía". El mismo bucle, el mismo código, produjo dos recuentos de pasos y secuencias genuinamente diferentes porque el modelo decidió la ruta en tiempo de ejecución en función de lo que observó. Ese es el significado real y concreto de "sin ruta de código predefinida": no es un eslogan, sino una diferencia mensurable en cuántos pasos se ejecutaron y cuáles eran.
Las implementaciones de producción de este patrón generalmente envuelven el historial acumulado de pensamiento/observación en un "bloc de notas" y resumen los resultados de la herramienta antes de reintroducirlos en el ciclo, ya que volcar registros de errores sin procesar o respuestas API grandes en contexto tiende a confundir el siguiente paso de razonamiento en lugar de ayudarlo.
Sistemas autónomos multiagente
El otro extremo del espectro se basa directamente en el bucle ReAct anterior, simplemente anidado. En una configuración de múltiples agentes, un orquestador ejecuta su propio bucle ReAct, donde algunas de sus "acciones" disponibles son llamadas a otros agentes, cada uno de los cuales ejecuta su propio bucle ReAct completo en su interior. El orquestador razona sobre qué delegar, lo delega, observa el resultado y continúa, exactamente como el bucle de agente único de la sección anterior, excepto que algunas de sus “herramientas” son agentes completos en lugar de funciones simples.
Imagine el diccionario AVAILABLE_TOOLS del ejemplo anterior, excepto que en lugar de search_knowledge_base y escalate_to_human, las entradas son research_agent, Finance_agent y coding_agent, y llamar a una de ellas no devuelve una cadena simple; inicia el ciclo independiente de Pensamiento-Acción-Observación de ese subagente, que puede ejecutarse durante varios pasos antes de devolver algo al orquestador. Nadie anotó de antemano a qué subagente se llama, en qué orden o cuántas veces se ejecuta cada uno de ellos.
La documentación de Google Cloud etiqueta la versión más extrema de esto como el patrón "enjambre": un equipo colaborativo de agentes sin ningún orquestador central, capaz de producir soluciones creativas de excepcional alta calidad precisamente porque nada limita la forma en que interactúan. Esa misma falta de estructura también es el riesgo: sin un límite de interacción diseñado por humanos, un enjambre puede caer en bucles improductivos o simplemente no lograr converger, y el costo de ejecutar muchos agentes a través de muchos turnos se agrava rápidamente.
Este es el punto del espectro donde el eje de previsibilidad de la primera sección oscila con mayor fuerza en la otra dirección. Una canalización determinista le brinda la misma estructura de salida cada vez, por construcción. Un enjambre de agentes autónomos le brinda la flexibilidad de manejar un problema que nadie anticipó, a costa de poder predecir, de antemano, qué hará o cuánto tiempo llevará hacerlo.
Por qué esta distinción es realmente importante en la producción
Esta no es una distinción académica. Tiene un efecto directo y mensurable sobre lo que realmente envían los equipos. A pesar del volumen de publicidad en torno a los agentes autónomos, los flujos de trabajo de IA (no los agentes totalmente autónomos) ganaron la batalla de la producción en 2025: los flujos de trabajo siguen siendo el patrón dominante detrás de las implementaciones exitosas de IA generativa, mientras que los sistemas multiagente totalmente autónomos todavía son en gran medida exploratorios fuera de dominios limitados.
La razón se relaciona directamente con el eje de previsibilidad desde el comienzo de este artículo. Los sistemas agentes no son deterministas por naturaleza; entradas idénticas pueden producir resultados diferentes en ejecuciones separadas, lo cual es un serio inconveniente en procesos regulados, auditables o de alto riesgo. Si un proceso debe ser explicable paso a paso para un equipo de cumplimiento o un regulador, eso no es territorio de agente por defecto; necesita barreras de seguridad y puntos de control con presencia humana superpuestos antes de que se le puedan confiar consecuencias reales.
El patrón que en realidad está surgiendo en los sistemas maduros es híbrido, no una decisión de elegir uno. Un agente de nivel superior establece objetivos y organiza la tarea general, mientras que los cálculos críticos y bien comprendidos aún se ejecutan dentro de módulos deterministas que un ser humano ha especificado completamente. Un sistema de diagnóstico médico, por ejemplo, podría utilizar un agente para interpretar síntomas ambiguos y decidir qué pruebas ordenar (autonomía genuina, porque la secuencia correcta de pruebas no se puede conocer de antemano) mientras cada prueba pasa por un proceso validado y determinista, porque esa parte del problema tiene un camino correcto conocido y no hay razón para introducir variabilidad en él.
Conclusión
“Flujo de trabajo agente” y “agente autónomo” describen dos extremos de un espectro, no dos tecnologías en competencia, y las cuatro etapas analizadas aquí (determinista, orquestada, reactiva y multiagente autónomo) no son una clasificación de peor a mejor. Son respuestas diferentes a la misma pregunta: ¿quién decide lo que sucede a continuación? ¿Esa decisión fue tomada por un código humano escrito de antemano o por un modelo de razonamiento en tiempo de ejecución?
Los flujos de trabajo deterministas le brindan auditabilidad y repetibilidad por construcción; la misma entrada toma el mismo camino cada vez, punto. Los sistemas reactivos y multiagente renuncian a esa garantía a cambio de la capacidad de manejar problemas cuya forma realmente no se puede anticipar de antemano. Ninguna propiedad es gratuita y ninguna arquitectura es correcta por defecto.
Los sistemas que se mantienen bien en la producción no eligen un extremo de este espectro y lo aplican en todas partes. Colocan cada parte del problema en el punto del espectro que realmente requiere: una estructura fija dondequiera que exista un camino correcto conocido y la repetibilidad sea importante, con autonomía real reservada para las partes del problema que no tienen un camino correcto predefinido a seguir en primer lugar.