Agentic Workflows vs. Autonomous Agents: What's the Difference?
Learn how agentic workflows and autonomous agents differ by examining who owns control flow — a human writing code, or a model reasoning at runtime.
In this article, you will learn how to distinguish agentic workflows from autonomous agents by focusing on who owns control flow — a human writing code in advance, or a model reasoning at runtime.
Topics covered include:
- Why the real axis separating these systems is predictability versus autonomy, not whether an LLM is involved.
- How deterministic workflows, orchestrated workflows, reactive agents, and autonomous multi-agent systems differ, with runnable code that makes the control-flow distinction concrete.
- Why workflows, not fully autonomous agents, dominate production today, and why hybrid architectures are the pattern that holds up.
Introduction
Deloitte projects that by 2027, up to 50% of companies using generative AI will have launched agentic AI pilots or proofs of concept. That’s a wave of adoption large enough that the word agentic has started covering almost anything with an LLM call in it — from a fixed five-step pipeline where step three happens to call GPT for a summary, to a fully self-directing system that plans its own path with no script at all.
Those are not the same thing. Treating them as interchangeable leads to one of two mistakes: over-engineering a simple, well-understood task with unnecessary autonomy, or under-engineering a genuinely open-ended problem by forcing it into a rigid pipeline that breaks the moment reality deviates from the plan.
Anthropic draws the foundational line in their widely cited Building Effective Agents piece: workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents are systems where LLMs dynamically direct their own process and tool usage, maintaining control over how they accomplish a task. Everything in this article falls underneath that single distinction.
This piece maps the full spectrum of deterministic workflows, orchestrated systems, reactive single agents, and autonomous multi-agent systems, with code at each stage that makes the control-flow difference concrete rather than abstract. The code here illustrates architecture, not a deployable system; the point of each snippet is to show who decides what happens next, not to ship a feature.
The Real Axis Isn’t “AI vs. No AI”: It’s Predictability vs. Autonomy
Before comparing architectures, it’s worth replacing the wrong question. The question isn’t does this system use an LLM — almost everything does now. The two questions that actually matter are: does this process need to be repeatable, auditable, and explainable step-by-step? And: is the correct path even known in advance, or does the system need to discover it at runtime?
A system can lean heavily on an LLM and still be fully deterministic in structure — a fixed pipeline where one step happens to call a model for text generation, but the next step is hardcoded regardless of what comes back. A system can also be “agentic” with very little real autonomy: a tightly scripted loop with only two allowed actions and a hard step limit. The presence of an LLM call is not the signal. Ownership of control flow is.
Google Cloud’s own design-pattern documentation draws this exact line operationally: deterministic workflows include tasks with a clearly defined path known in advance, where the steps don’t change much from one run to the next. Workflows that require dynamic orchestration involve problems where the agent must determine the best way to proceed, without a predefined script. That’s the spectrum this article walks through, one stage at a time.
Deterministic Workflows
This is the baseline. A deterministic workflow has a known sequence of steps decided at design time, by a human, in code. An LLM can sit inside any step — generating text, classifying input, drafting a summary — but it does not choose what happens after its own step runs. The orchestrating code does that, regardless of what the model returns.
# 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("How do I reset my password")
print(result_1)
print(result_2)The key observation: both inputs travel through the exact same four functions in the exact same order. The LLM call in classify() returns different labels for these two inputs, but that difference never influences routing. A human decided at design time that the path is always extract → classify → summarize → notify, and nothing at runtime can change that.
This is appropriate when the task is well-understood, the steps are stable, and auditability matters. It is inappropriate when the correct path genuinely depends on what the input turns out to be.
Orchestrated Agentic Workflows
One step up the autonomy ladder: the LLM’s output now influences which branch of code runs next. The human still writes all possible branches in advance — the model cannot invent a new step that wasn’t anticipated — but the routing decision is delegated to the model at runtime rather than hardcoded.
# orchestrated_workflow.py
# Prerequisites: none beyond Python's standard library
# Run: python orchestrated_workflow.py
def mock_llm_route(text: str) -> str:
"""
Mock routing call. In production this would be a structured-output LLM
call that returns one of a fixed set of labels the human defined in advance.
The human still owns all possible branches; the model just picks among them.
"""
if "refund" in text.lower() or "charge" in text.lower():
return "billing"
if "password" in text.lower() or "login" in text.lower():
return "auth"
return "general"
def handle_billing(text: str) -> str:
return f"[BILLING HANDLER] Opened billing ticket for: {text[:50]}"
def handle_auth(text: str) -> str:
return f"[AUTH HANDLER] Sent password-reset link for: {text[:50]}"
def handle_general(text: str) -> str:
return f"[GENERAL HANDLER] Logged general inquiry: {text[:50]}"
ROUTE_MAP = {
"billing": handle_billing,
"auth": handle_auth,
"general": handle_general,
}
def run_orchestrated_workflow(raw_input: str) -> str:
"""
The LLM now owns the routing decision, not just a data field.
But the human still owns the complete set of possible routes --
the model can only choose from branches the developer wrote.
"""
text = raw_input.strip()
route = mock_llm_route(text)
print(f" [router] LLM chose route='{route}'")
handler = ROUTE_MAP.get(route, handle_general)
return handler(text)
if __name__ == "__main__":
inputs = [
"I want a refund for my last charge",
"I cannot log in to my account",
"What are your business hours",
]
for inp in inputs:
print(run_orchestrated_workflow(inp))
print()The model now makes a real decision that changes execution. But the human still defined every possible handler, every valid route label, and the fallback behavior. The boundary of what the system can do is still set entirely at design time. This is the most common pattern in production today: it gives flexibility without surrendering the auditability that engineering and compliance teams require.
Reactive Single Agents
Here the model gains a new power: it can decide whether to call a tool, and then decide again based on what that tool returns. The loop is not written out step-by-step in the orchestrating code. The model reasons about its current state and picks its next action.
# reactive_agent.py
# Prerequisites: none beyond Python's standard library
# Run: python reactive_agent.py
import re
# --- Simulated tool implementations ---
def tool_search_kb(query: str) -> str:
"""Simulates a knowledge-base lookup."""
kb = {
"refund policy": "Refunds are processed within 5-7 business days.",
"password reset": "Use the 'Forgot Password' link on the login page.",
"business hours": "We are open Monday-Friday, 9am-6pm EST.",
}
for key, answer in kb.items():
if key in query.lower():
return answer
return "No relevant article found."
def tool_escalate(reason: str) -> str:
"""Simulates escalating to a human agent."""
return f"Ticket escalated to human support. Reason: {reason}"
TOOLS = {
"search_kb": tool_search_kb,
"escalate": tool_escalate,
}
# --- Mock LLM that returns structured tool-call decisions ---
def mock_llm_agent_step(history: list[dict]) -> dict:
"""
Simulates one reasoning step of a tool-calling LLM.
Returns either a tool call or a final answer.
The real version would serialize `history` and send it to the model API.
"""
last_user = next(
(m["content"] for m in reversed(history) if m["role"] == "user"), ""
)
last_tool = next(
(m["content"] for m in reversed(history) if m["role"] == "tool"), None
)
# If the KB search already returned a real answer, wrap it up
if last_tool and "No relevant article" not in last_tool:
return {"type": "final", "content": last_tool}
# If we already searched once and got nothing, escalate
if last_tool and "No relevant article" in last_tool:
return {
"type": "tool_call",
"tool": "escalate",
"args": {"reason": f"KB had no answer for: {last_user[:60]}"},
}
# First step: always try the KB
return {"type": "tool_call", "tool": "search_kb", "args": {"query": last_user}}
def run_reactive_agent(user_input: str, max_steps: int = 5) -> str:
"""
The model drives the loop. After each tool call it re-evaluates and
decides the next action. The developer set the allowed tools and the
step limit -- but not the path through them.
"""
history = [{"role": "user", "content": user_input}]
for step in range(max_steps):
decision = mock_llm_agent_step(history)
print(f" [step {step+1}] model decision: {decision}")
if decision["type"] == "final":
return decision["content"]
if decision["type"] == "tool_call":
tool_fn = TOOLS.get(decision["tool"])
if tool_fn is None:
return f"Error: unknown tool '{decision['tool']}'"
result = tool_fn(**decision["args"])
history.append({"role": "tool", "content": result})
return "Max steps reached without a final answer."
if __name__ == "__main__":
queries = [
"How do I get a refund?",
"My issue is very unusual and nothing in your docs covers it",
]
for q in queries:
print(f"\nQuery: {q}")
print("Answer:", run_reactive_agent(q))The model here owns the loop. After seeing a tool result, it decides whether that was enough or whether another action is needed. The developer wrote the tools and set a step limit, but did not write out the path. A three-step resolution and a one-step resolution look structurally different at runtime because the model made that call, not the code.
This pattern handles open-ended tasks that a static branch list cannot anticipate. The cost is reduced predictability: the path is harder to inspect, and failures require reasoning about model behavior rather than reading a fixed flowchart.
Autonomous Multi-Agent Systems
At the far end of the spectrum, multiple agents operate in parallel or in sequence, with one agent able to spawn or direct others. No single piece of code holds the complete execution plan. Planning, delegation, and synthesis all happen at model-reasoning time.
# multi_agent_system.py
# Prerequisites: none beyond Python's standard library
# Run: python multi_agent_system.py
import textwrap
# --- Simulated sub-agent implementations ---
def research_agent(topic: str) -> str:
"""Simulates a specialized research sub-agent."""
return (
f"Research findings on '{topic}': "
f"Three peer-reviewed studies confirm a strong positive correlation. "
f"Sample sizes ranged from 200 to 4,000 participants."
)
def critic_agent(draft: str) -> str:
"""Simulates a critic sub-agent that reviews a draft."""
return (
f"Critique of draft: The claim is well-supported but the conclusion "
f"overgeneralizes. Recommend softening the final sentence."
)
def writer_agent(findings: str, critique: str) -> str:
"""Simulates a writer sub-agent that synthesizes research and critique."""
return (
f"Revised summary incorporating critique:\n"
f" Based on multiple studies, the evidence suggests a positive "
f"correlation, though generalization beyond the studied populations "
f"requires caution."
)
SUB_AGENTS = {
"research": research_agent,
"critic": critic_agent,
"writer": writer_agent,
}
# --- Mock orchestrator LLM ---
def mock_orchestrator_plan(task: str, completed: list[str]) -> dict:
"""
Simulates an orchestrator LLM deciding the next sub-agent to invoke.
In production this would be a full LLM call with the task description
and the growing list of completed steps.
"""
if not completed:
return {"action": "delegate", "agent": "research", "input": task}
if "research" in completed and "critic" not in completed:
last_result = completed[-1]
return {"action": "delegate", "agent": "critic", "input": last_result}
if "critic" in completed:
findings = next((r for r in completed if "findings" in r.lower()), "")
critique = next((r for r in completed if "critique" in r.lower()), "")
return {
"action": "delegate",
"agent": "writer",
"input": {"findings": findings, "critique": critique},
}
return {"action": "finish", "result": completed[-1]}
def run_multi_agent_system(task: str, max_rounds: int = 6) -> str:
"""
The orchestrator reasons about what to do next after each sub-agent
completes. No single function holds the full execution plan -- it
emerges from orchestrator decisions at runtime.
"""
completed_results: list[str] = []
completed_agents: list[str] = []
for round_num in range(max_rounds):
plan = mock_orchestrator_plan(task, completed_results)
print(f" [round {round_num+1}] orchestrator plan: action={plan['action']}", end="")
if plan["action"] == "finish":
print()
return plan.get("result", "No result.")
agent_name = plan["agent"]
agent_fn = SUB_AGENTS.get(agent_name)
print(f", agent={agent_name}")
if agent_fn is None:
return f"Error: unknown agent '{agent_name}'"
agent_input = plan["input"]
if isinstance(agent_input, dict):
result = agent_fn(**agent_input)
else:
result = agent_fn(agent_input)
completed_results.append(result)
completed_agents.append(agent_name)
return "Max rounds reached."
if __name__ == "__main__":
task = "Summarize the evidence on exercise and cognitive performance"
print(f"Task: {task}\n")
final = run_multi_agent_system(task)
print(f"\nFinal output:\n{textwrap.indent(final, ' ')}")The orchestrator here doesn’t follow a script. After each sub-agent returns, it reassesses and decides which agent to invoke next. In a production system this reasoning would handle partial failures, conflicting sub-agent outputs, and dynamic replanning — none of which the developer could fully anticipate at design time.
The power is genuine: this pattern can tackle tasks that no static pipeline could handle. The costs are also genuine: debugging requires understanding what the orchestrator model decided and why, testing must account for non-deterministic paths, and failure modes compound across agents.
Why Workflows Dominate Production
Given that multi-agent autonomy is technically possible, it’s worth asking why most deployed systems are orchestrated workflows rather than fully autonomous agents. The answer comes down to four operational realities.
Auditability. Regulated industries — finance, healthcare, legal — require that every decision can be traced to a specific, human-readable rule. A workflow step can be pointed to directly. A model’s in-context reasoning cannot.
Failure isolation. In a fixed pipeline, a failure in step three is a step-three problem. In an autonomous agent, a bad decision at step three can propagate through every subsequent step in ways that are difficult to detect until the final output is wrong.
Cost predictability. Autonomous loops that can call tools repeatedly and spawn sub-agents produce unpredictable token and API costs. Workflows have known, bounded costs per run.
Latency. Each reasoning step adds latency. A workflow with five LLM calls has roughly predictable end-to-end latency. An agent that might take two steps or twelve does not.
These aren’t arguments against autonomy — they’re arguments for matching architecture to requirements. An autonomous agent is the right choice when the task is genuinely open-ended and the operational costs of autonomy are acceptable. A workflow is the right choice when the task is understood well enough to be scripted and the costs of unpredictability are not acceptable.
Hybrid Architectures: The Pattern That Holds Up
Most production systems that handle real complexity aren’t purely one or the other. They use a tiered structure: deterministic orchestration at the top level, with autonomous agents scoped to well-bounded sub-problems where full autonomy is actually needed.
A practical example: an enterprise support system might use a deterministic router to classify incoming requests by type, an orchestrated workflow to handle the 80% of cases that fit known patterns, and a reactive agent only for the 20% of cases that fall outside those patterns. The autonomous behavior is real, but it’s sandboxed by the outer deterministic structure.
This is the pattern Anthropic describes when they recommend starting with the simplest solution and only adding complexity when simpler approaches fall short. It’s also what Google Cloud’s documentation means when it distinguishes between tasks appropriate for deterministic workflows and tasks that genuinely require dynamic orchestration.
The practical implication: when designing a system, map each sub-problem onto the spectrum independently. Use the least autonomous architecture that can reliably handle each sub-problem, and only reach for more autonomy where the task genuinely requires it.
Summary
The distinction between agentic workflows and autonomous agents is not about whether a system uses an LLM. It is about who owns control flow. In a workflow, a human writes the control flow in advance, in code, and the LLM fills in data or makes bounded choices within that structure. In an autonomous agent, the LLM owns the loop and decides what happens next based on its own reasoning at runtime.
The four points on the spectrum — deterministic pipelines, orchestrated workflows, reactive single agents, and autonomous multi-agent systems — represent increasing degrees of runtime autonomy, with corresponding increases in flexibility and decreases in predictability. Production systems tend to sit at the workflow end of that spectrum, not because autonomy is impossible to achieve, but because auditability, failure isolation, cost predictability, and latency bounds are engineering requirements that matter as much as capability. Hybrid architectures that apply the right level of autonomy to each sub-problem independently remain the most robust pattern for systems that need both reliability and genuine flexibility.