Workflows vs. agents: a pragmatic decision framework
A reliability-first approach to choosing between predictable workflows and flexible agents, with four reusable patterns and concrete selection heuristics.
| Resource | Link |
|---|---|
| Implementation | ravikanchikare/herdr-agent-factory |
| Workflow patterns | Building effective agents |
| Tool control | Tool use with Claude |
Reliability determines whether a system needs a workflow or an agent. A known sequence belongs in code; runtime discoveries justify giving the model control over the next action.
The core heuristic
Workflows are predictable, testable, and debuggable — every step follows a known path. Agents are flexible combiners of tools that determine their own next action. Use workflows when you can articulate the ideal sequence; reach for an agent only when the path genuinely depends on what the model discovers at runtime.
Four reusable workflow patterns
Four patterns cover common cases without requiring an open-ended loop.
Parallelization
Split a complex multi-criteria decision into independent evaluations, run them simultaneously, then aggregate.
Input
Complex decision arrives.
Split
Decompose into independent criteria.
Evaluate in parallel
Run specialized prompts simultaneously — each optimized for one criterion.
Aggregate
Compare results and reconcile disagreements.
Output
Return a unified recommendation.
Example: A material designer application where users upload images of parts and receive material recommendations. Instead of cramming criteria for metal, polymer, ceramic, composite, elastomer, and wood into one massive prompt, send six parallel requests — each with specialized criteria for one material — then feed all results into a final comparison step.
Benefits: Claude can concentrate on one evaluation at a time rather than juggling competing considerations. Individual prompts can be optimized independently. Adding new materials means adding a new parallel request without touching existing prompts.
When to use: Complex decisions factorable into independent sub-evaluations, where each sub-evaluation benefits from specialized criteria or tools.
Chaining
Break a task into sequential steps where each builds on the previous output.
Input
Task and context arrive.
Generate
Produce the first draft without overthinking constraints.
Revise
Apply constraints — length, tone, format, content rules — against the draft.
Validate
Check the output meets all requirements.
Final
Return the ready result.
The chaining trick for constraint-heavy prompts: When a prompt has many constraints, use one call to generate and a second to revise against the rules. This creates an inspectable intermediate result and gives validation a clear input.
When to use: Tasks with many constraints, multi-stage transformations (extract then format then validate), or any process where intermediate outputs enable quality checks before proceeding.
Routing
Classify the input, then dispatch to a specialized handler.
Input
Incoming request arrives.
Classifier
Categorize the request — billing, technical, account, or general.
Specialized handlers
Dispatch to a handler optimized for the category, with domain-specific examples, tools, and tone guidance.
Response
Return the category-specific answer.
Example: A customer support system that categorizes incoming questions (billing, technical, account, general) and routes each to a prompt optimized for that category. Each handler can have domain-specific examples, tools, and tone guidance.
When to use: Heterogeneous input where the ideal response strategy depends on the input category.
Evaluator-optimizer
A feedback loop: generate, evaluate against a rubric, identify gaps, improve, repeat.
Generate
Produce a draft of the output.
Evaluate
Score the draft against a rubric using a separate Claude call with a separate prompt.
Pass?
Check whether scores meet the threshold.
Improve
Fix identified gaps, then loop back to evaluation.
Final
Return the accepted output.
Example: A writing assistant that produces a draft, evaluates it against criteria (clarity, completeness, tone, accuracy), and automatically revises until the evaluation scores pass a threshold.
The evaluator uses a separate call, rubric, and context. Independence comes from separating generation evidence from evaluation instructions; it does not require a different model name.
When to use: Quality-critical outputs where “good enough” is definable and automated evaluation is feasible.
Tool choice: a spectrum between workflow and agent
The tool_choice parameter from the Claude API provides a concrete mechanism that spans the workflow-to-agent spectrum:
| tool_choice | Behavior | Where it sits |
|---|---|---|
{"type": "none"} |
Claude cannot call a tool | No tool step — the response stays model-only |
{"type": "tool", "name": "..."} |
Claude must call the named tool | Constrained step — tool selection is fixed |
{"type": "any"} |
Claude must call a tool | Guided choice — tool use is required |
{"type": "auto"} |
Claude decides whether to call a tool | Flexible choice — tool use is optional |
Forcing a named tool fixes the selection, not the arguments: the model still generates tool input. Add strict: true to a custom tool definition when its input must conform to the declared schema. With auto, the model may call a tool or answer directly; with any, it must choose at least one tool.
The complete tool use workflow
The client-side tool loop has four steps:
- Client provides Claude with tools + user prompt
- Claude responds with
stop_reason: "tool_use" - Client executes the tool, returns
tool_resultwith matchingtool_use_id - Claude uses the result to formulate the final answer
Repeat while stop_reason is "tool_use". Any other stop reason exits the client-tool loop; "end_turn" is a completed response, while "max_tokens", "stop_sequence", or "refusal" needs its own handling. Server tools have a separate "pause_turn" continuation path.
When agents are the right answer
Agents become useful when the model needs to decide what to do next. Give them abstract, combinable tools rather than encoding an entire task into each tool.
Good agent tools: bash, read_file, write_file, web_search, run_query — general capabilities that chain together.
Poor agent tools: refactor_code, fix_bug, optimize_performance — hyper-specialized tools that constrain flexibility and prevent creative problem-solving.
Environment inspection
An agent cannot verify effects it cannot observe. Provide tools that let it inspect the results of its actions:
- Read a file before editing it
- Take a screenshot after a UI interaction
- Check an API response before proceeding
- List a directory before assuming file paths
Without observation capability, agents make decisions on stale or incorrect assumptions. Every action tool should have a corresponding observation tool.
Agent Factory: a workflow around agents
Agent Factory applies the hybrid pattern to building and evaluating agents. The outer loop is structured: define a Target Agent and measurable criteria, select an Environment, create a Factory Run, delegate work, collect evidence, evaluate the result, and decide whether to iterate or finish.
The executable Run contract has three durable session roles: Orchestrator, Coding, and Evaluation. The Orchestrator may assign Validator or Auditor work to a managed agent, but those are responsibilities rather than additional Run state machines.
Herdr owns live workspaces, panes, processes, terminals, topology, and lifecycle. Agent Factory’s Rust runtime owns the durable Factory ledger, policy, evidence, and Run control. Git owns worktree and repository facts, while the Orchestrator alone decides to delegate, iterate, evaluate, escalate, or finish.
That authority split prevents runtime signals from becoming workflow conclusions. A settled or closed pane is a process fact, not evidence that the Factory Run met its criteria.
| Factor | Prefer workflow | Prefer agent |
|---|---|---|
| Predictability | Steps are known | Path depends on discoveries |
| Reliability needs | Must not deviate | Flexibility is more valuable |
| Debugging | Need clear failure points | Can tolerate exploration |
| Cost | Fixed number of calls | Variable number of calls |
| Latency | Parallelizable or fixed | Unbounded loop |
Takeaways
Known steps favor workflows
Use workflows when the path is predictable and agents only when runtime discoveries genuinely determine the next action.
Four patterns provide a workflow baseline
Parallelization, chaining, routing, and evaluator-optimizer loops add reusable structure before open-ended agency is necessary.
Constraint-heavy prompts chain well
A generation call followed by a revision call lets the model focus on one mental task at a time.
Agent tools should be abstract
General tools like bash, read, write, and search compose better than narrow tools like `fix_bug` or `optimize_performance`.
Observation tools are required
Agents need ways to inspect files, screenshots, API responses, and directories so decisions are based on current state.