Workflow vs. Agent: a Policy-vs-Script Perspective
Stop arguing abstractions. Ask: who controls orchestration at runtime?
What the mainstream says (and where it blurs)
A widely cited split is:
- Workflows: systems where LLMs/tools are orchestrated through predefined code paths (DAGs/FSMs/“chains”).
- Agents: systems where an LLM (or other policy) dynamically directs process and tool usage at run-time. (langchain-ai.github.io)
Anthropic’s engineering guidance echoes this: workflows offer predictability and consistency for well-defined tasks; agents are better when flexibility and model-driven decisions are needed at scale. (Anthropic)
OpenAI’s Agents SDK is explicit that you can orchestrate agents via code (scripted) or let the LLM decide (policy-driven)—and many real systems mix both. (openai.github.io)
Where it blurs in practice
- Looks like an agent, but it’s a workflow: multi-role “collabs” with a fixed SOP, rich branching, retries, even voting—if all branches & stop conditions are statically knowable, it’s still scripted orchestration. (langchain-ai.github.io)
- Looks like a workflow, but it’s agentic: the system renders a DAG then changes it during execution—inserting steps, reordering tools, reallocating budget—based on observations. The artifact is a DAG; the orchestration is policy-driven. (langchain-ai.github.io)
The cleaner split: scripted vs policy-driven orchestration
Forget “open-loop vs closed-loop” (both sides can loop). The decisive question is: who controls the next action at runtime?
- Scripted orchestration: developers fix the topology/guards/stop conditions at design time; runtime only follows enumerated branches.
- Policy-driven orchestration (agentic): a learned/inferred policy (often an LLM) chooses actions/tools/parameters/stop at runtime, possibly altering the future flow.
OpenAI’s own docs frame orchestration exactly this way: either you let the LLM plan/decide next steps, or you deterministically orchestrate via code. Treat it as a spectrum, not a binary. (openai.github.io)
Rule of thumb: Workflows execute a predetermined game plan; agents improvise a plan as they go. (langchain-ai.github.io)
Gray zones & edge cases you’ll meet in the wild
DAG generators (plan-and-execute) LLM drafts a plan/DAG, then the system executes without deviation → AI-written workflow per task. If execution can revise the plan mid-flight, it crosses into agentic territory. (Related line of work: CodeAct—generate executable code as the action space, then run it under an interpreter to act and adapt.) (arXiv)
Static-but-learned workflows A fine-tuned model internalizes a multi-step routine and answers in one shot. The “workflow” is inside the weights. Great for reliability, weak for visibility/guardrails compared to explicit DAGs. (You’ve outsourced the script into a policy.)
Self-reflective/guard-railed agents Many production agents contain scripted guardrails (e.g., “if the same tool fails 3×, stop”). They’re still agentic overall—just workflow islands inside a policy loop. (Common in ReAct-style agents and vendor SDKs.) (openai.github.io)
Three hybrids that actually ship
Workflow-in-Agent (a.k.a. Code-as-Action / Plan-as-Code) The agent decides when to invoke a multi-step scripted skill (e.g., “BookFlight”), then hands off to a deterministic executor. You get agent flexibility with workflow reliability. Code-as-action (e.g., CodeAct) is the purest form: the policy writes code, the code executes. (arXiv)
Agent-in-Workflow A larger workflow provides the backbone; specific nodes delegate to an agent for open-ended reasoning/interaction, then return to the script. This is how many enterprises integrate AI into existing pipelines (e.g., “if simple → scripted refund; else → agent handles dialog”). Frameworks like AutoGen and OpenAI’s SDK explicitly support deterministic and dynamic agentic workflows in one system. (6)
Agent using Workflow as a Tool Expose whole workflows as callable tools (APIs). The agent chooses when to trigger
process_form(...)(which runs a fixed sub-DAG) and waits for the result. This “delegate to SOP when appropriate” pattern is common in multi-agent stacks like OWL or CrewAI. (OWLCrewAI)
Why workflows won’t be obsolete
From the start of AI, plans and policies have coexisted. Classical planners produced explicit action scripts; reactive robotics emphasized on-the-fly policies. Modern stacks are layered: plan and react. Cognitive science said this decades ago: scripts are our mental workflows for stereotyped situations—efficient, predictable templates we compile through experience. (colinallen.dnsalias.org)
Reinforcement learning formalized the same idea with options/skills—temporally extended actions that encapsulate reliable subroutines. Options act like callable workflows inside an agent, letting policies operate at a higher, more stable level. This is exactly the “workflow-in-agent” pattern in math form. (www-anw.cs.umass.edu)
TL;DR: Stabilize the routine (script it), strategize the uncertain (policy it). That’s how humans and robust AI systems both work.
Takeaway
- Agents sample flows; workflows execute flows. (langchain-ai.github.io)
- The practical knife-edge is scripted vs policy-driven orchestration at runtime—not whether loops exist. (openai.github.io)
- Hybridize: let policies choose and adapt; let workflows guarantee the parts that must be predictable. (Anthropic)
References & further reading
- Anthropic, Building Effective AI Agents; Writing Effective Tools for Agents. (Anthropic)
- OpenAI, Agents SDK: orchestration via LLM vs code; multi-agent examples. (openai.github.io)
- LangChain/LangGraph, Workflows & Agents (docs/tutorials). (langchain-ai.github.io)
- Microsoft AutoGen, Deterministic and dynamic agentic workflows. (GitHub 上的 Microsoft)
- Apple CodeAct (Executable Code as Action Space). (Apple Machine Learning Research)
- OWL (CAMEL-AI): paper & repo; blog context. (arXiv)
- Schank & Abelson (1977), Scripts, Plans, Goals, and Understanding. (colinallen.dnsalias.org)
- Sutton, Precup, Singh (1999), Options framework. (www-anw.cs.umass.edu)