Agent vs Workflow. When to pick which

Picking between Agent and Workflow is an engineering decision, not stylistic. Production systems usually need both, composed together (see Composition).

This page is the decision rubric.

The core distinction

Both share Loom’s observability spine, multi-tenant user_id partition, retry policy, telemetry, and audit log. Those are framework-level guarantees, not per-primitive.

Pick Agent when…

• The number of steps is hard to predict upfront. ReAct-style observe / think / act handles “I don’t know how many tool calls I’ll need” better than any DAG.
• Tools occasionally fail or return surprising data that should re-shape the plan. The LLM can adapt; a static graph can’t.
• You want the cheapest interactive UX. A single ReAct agent with parallel tool dispatch is the lowest-friction shape.
• The user’s intent is the input. “Help me plan a Tokyo trip” doesn’t decompose cleanly; the agent figures out the steps.

Reach for an agent architecture (ReAct / PlanAndExecute / ReWOO / Reflexion / Supervisor / etc.) when the LLM should own iteration but you want it iterating in a specific shape.

Pick Workflow when…

• The graph IS the contract. Compliance flows, multi-stage approval chains, BPMN-like signoff sequences. The diagram is what auditors / lawyers / legal review.
• Every run should be deterministic given the same input. Workflow paths are functions of the classifier outputs, not the LLM’s free-form reasoning. Same input → same path.
• Cost predictability matters. A Workflow’s cost is sum(node costs) for a known set of nodes per path. Far more bounded than an agent’s “until the LLM thinks it’s done”.
• The flow uses tools the LLM doesn’t need to choose. If you KNOW the next step, calling a tool is a workflow node, not an agent decision.
• You want to wire LLM-driven steps and deterministic steps in one graph. Pre-process input → run agent → post-process output → write to DB. Half the steps don’t need an LLM.

Reach for a Workflow.chain / Workflow.route / Workflow.parallel when the shape is one of those three. Drop to the explicit graph builder for cycles or non-trivial branching.

Decision flowchart

                 Does the LLM need to decide *what* to do next?
                                       │
                       ┌───── yes ─────┴───── no ─────┐
                       ▼                              ▼
                    Agent                          Workflow
                       │                              │
                       │                  Is the graph linear?
                       │                              │
                       │              ┌──── yes ──────┴───── no ────┐
                       │              ▼                              ▼
                       │       Workflow.chain          One classifier? One fan-out?
                       │                                            │
                       │                          ┌──── classifier ─┴── fan-out ──┐
                       │                          ▼                                ▼
                       │                  Workflow.route               Workflow.parallel
                       │                          │
                       │                          │   (cycles?)
                       │                          ▼
                       │              Explicit graph builder
                       ▼
              Which architecture?
                       │
        ┌──────────────┼─────────────────┐
        │ default       │ multi-agent     │ refinement
        ▼               ▼                 ▼
      ReAct         Supervisor /      Reflexion /
                    Router /          ActorCritic /
                    Swarm /           SelfRefine /
                    Debate /          TreeOfThoughts
                    Blackboard

Cost comparison (rough orders of magnitude)

For a “support triage” task. Classify, then dispatch to a specialist:

Workflow.route and the Router architecture are roughly equivalent in cost. Pick Router when you want the routing inside an Agent (retries / structured outputs / full Agent semantics); pick Workflow.route when you want a deterministic graph that other nodes can route into and out of.

”But which is more flexible?”

Agent is more flexible per turn (the LLM can pick anything from the tool surface). Workflow is more flexible per system (you can embed multiple agents, multiple sub-workflows, deterministic processing. The framework doesn’t care which).

The honest answer: modern production systems use both. Examples:

• Agent inside a Workflow: deterministic gating + LLM-driven middle + deterministic logging.
• Workflow inside an Agent: open-ended UX + a deterministic refund-flow tool the agent invokes.
• Workflow chaining Agents: classify-and-dispatch where each specialist is itself an architecture (Supervisor, Reflexion, etc.).

Don’t pick one and use it everywhere. Pick the right primitive at each layer.

What you don’t have to decide

These are framework guarantees regardless of which primitive you use:

• user_id partitions memory, budgets, audit, permissions.
• Retry policy auto-wraps network model adapters.
• Hooks (@before_tool / @after_tool) and permissions gate every tool call.
• Telemetry traces nest correctly across composed agents and workflows.
• The audit log records who did what, signed.

So the choice is purely about iteration shape and predictability, not “which framework gives me observability”.