Agents and workflows are useful at different points in an application, so the right design depends on where a team needs power or control.
2
Workflow APIs should let engineers read the control flow without learning graph theory.
3
The strongest systems combine agents, workflow steps, tools, handoffs, dynamic tool selection, and nested workflows.
Summary
Sam Bhagwat argues that the debate over agents versus workflows has become too ideological. He describes agents as turn-based loops that choose actions and call tools, while workflows encode dependencies, branching, parallelism, conditions, loops, suspension, resuming, and replay. The choice is a trade-off between power and control. Teams can start with an agent and add structure where reliability suffers, or use a workflow for the parts that need predictable execution. Bhagwat prefers fluent workflow syntax over APIs built around graph nodes and edges because engineers can read the control flow directly. He gives several composition patterns: an agent can be a workflow step, a workflow can be an agent tool, agents can supervise other agents, and workflows can handle handoffs. He also recommends dynamic tool injection when an agent has too many tools. His practical advice is to explain and diagram an architecture with colleagues, then combine primitives based on what works in production.
The agents-versus-workflows debate should not become development dogma
Bhagwat opens by describing the recent argument around Anthropic's "Building effective agents" post and an OpenAI paper that he says included an anti-workflow message. His concern is that large model providers have an elevated position in the ecosystem, so their advice carries unusual weight. He compares this with past web development debates, where guidance from large companies sometimes pushed developers toward difficult technologies. His first practical warning is to avoid assuming that one organization knows the only correct way to build software. He wants the discussion to stay grounded in the systems teams are actually building.
Bhagwat says graph node and edge APIs can force developers to learn graph theory before they can write a production workflow. He compares this with Gatsby's earlier use of GraphQL as a default data-fetching pattern. The problem is not that GraphQL or graphs are inherently bad. The problem is making a particular abstraction the default when many users want a simpler framework. He prefers fluent syntax, such as the Mastra workflow style, where engineers can read from the top of the file to the bottom and see what happens next. He also wants colleagues on a team to use the framework without first studying graph theory.
Agents and workflows solve different control problems
Bhagwat explains agents as a turn-based game. A person takes a turn, the agent takes a turn, and the agent may take another turn or call a tool. Workflows are closer to a rules engine or a technology dependency tree. A later step depends on an earlier one, like researching iron working after bronze working in Civilization. Workflows often look like data pipelines that execute steps in order, but they can also include branching, parallelism, conditions, loops, suspension, resuming, and replaying. Conversations produce properties such as threads and memory. Workflows become especially useful in AI engineering because non-determinism makes tracing and understanding what happened much more important.
Power and control should be assigned where each is useful
Bhagwat reduces the architectural choice to a trade-off between power and control. Teams can decide which parts of an application need an agent's freedom and which parts need explicit structure. One approach is to start with power, then add control to the areas that go off the rails. In a whiteboarding example, a large language model was given a giant medical-documentation PDF and asked to diagnose twelve symptoms, but it was not reliably extracting the right information. Bhagwat suggests breaking one model call into twelve calls and adding structure where reliability is weak. He recommends examining which part of an application performs poorly, then choosing a more structured process for that part.
Composition lets agents and workflows fill each other's roles
Bhagwat says agents have tools and workflows have steps, but the primitives can cross those boundaries. An agent can be a workflow step. A workflow can be a tool for an agent. An agent can also be a tool or a step. He presents composition as the source of much of the practical power. In an agent supervisor pattern, an orchestrator agent calls a research agent and a summary agent as tools. In another pattern, a workflow can plan a location, check the weather, and plan a trip before passing the result to an agent that can iterate and decide. These combinations keep the individual primitives simple while allowing larger designs.
Tool selection and handoffs need their own structure
Bhagwat describes dynamic tool injection as another composition pattern. Agents may start failing when they receive double-digit numbers of tools, so a system can decide which tools to provide for a particular task at a particular time. Workflows can also perform agent handoffs, and workflows can be nested as steps inside other workflows. The implementation details grow in production because real applications contain a surprising amount of detail. His point is not that one pattern always wins. Teams need to combine the patterns according to the task and the failure modes they observe.
Working systems are more reliable evidence than abstract theory
During questions, Bhagwat is asked whether a deep research agent with twenty tools should be combined with a workflow. His answer is practical: if the agent works as needed, use it, even if it does not fit a theory. He describes the field as a community of practice more than a community of theory. AI agent practice is evolving faster than the theory around it, so a supposedly incorrect design may indicate that the theory is incomplete. This gives teams permission to test different arrangements instead of rejecting an architecture because it does not match a preferred model.
"I do not think you should need to learn graph theory to write workflows to build production applications."04:28
Who should watch
You are choosing between a ReAct-style loop and a structured workflow for a new AI feature.
Your workflow framework exposes nodes and edges, and your team wants a more readable way to express control flow.
You have an agent that works in simple cases but needs structure around reliability, tool selection, or handoffs.
