Agents vs Workflows: The One-Question Framework for Every Build

The one question that separates a great AI system from an over-engineered mess isn't about capability — it's about whether the path through the problem is known before you start. Agents vs workflows is the most consequential architectural decision you'll make in 2025, and most teams are getting it wrong by defaulting to the flashier option.

I've watched teams burn weeks wiring up autonomous agents for processes that a simple deterministic workflow would handle in an afternoon. The allure is understandable: agents feel like the future, workflows feel like plumbing. But plumbing is what keeps the building standing. Let me walk through the framework I use every time I'm scoping a new build.

The Trap: Complexity ≠ Agents

Here's the misconception I keep running into: people see a process with fifteen steps and assume it needs an agent. Step count has nothing to do with it. A deterministic workflow — where the same input always follows the same fixed sequence of steps — can handle extraordinarily complex processes as long as the path through those steps is known in advance.

Think about a password reset. Verify the user's identity, generate a reset token, send the link, confirm the reset succeeded, log the event. That's five steps, some with branching logic (what if verification fails?), but every branch is fully enumerable before a single line of code runs. You don't need a language model deciding what happens next. A plain workflow wins — it's faster, cheaper, and trivially debuggable.

Now contrast that with this support ticket: "I was charged twice, figure out what happened and fix it." The system has to check the payments table, cross-reference order history, maybe inspect a third-party payment processor's webhook logs, potentially ask the user for a screenshot or transaction ID it doesn't have yet, and then pick its next step based on what it discovers at each stage. The path literally cannot be known up front because it depends on intermediate findings. That's where an agent earns its place.

The one question, then, is deceptively simple: Is the path known before execution begins?

• Yes → Build a deterministic workflow.
• No → Consider an agent.

That's it. Everything else is implementation detail.

The Hidden Cost of Autonomy

"Why not just use agents everywhere and let them figure it out?" I hear this constantly, and the answer is that autonomy is not free. Every decision point you hand to an agent introduces a specific, measurable cost:

• Latency. Each LLM call adds hundreds of milliseconds to seconds of round-trip time. A workflow that completes in 200ms might take 3-8 seconds as an agent while it reasons through steps sequentially. For user-facing flows, that latency compounds into a noticeably worse experience.
• Cost per run. Token usage scales with reasoning depth. A deterministic workflow making zero LLM calls costs zero in inference. An agent making four to six calls per resolution might cost $0.03–$0.15 per run depending on the model. Multiply that by tens of thousands of daily executions and you're looking at a line item that finance will eventually question.
• Debuggability. When a workflow fails, you look at the step that errored and fix it. When an agent fails, you're reading through a chain-of-thought trace trying to understand why it chose step C instead of step B, often with non-deterministic outputs that don't reproduce consistently. Your mean time to resolution on bugs goes up dramatically.
• Failure surface area. Every autonomous decision is a new place where the system can hallucinate, misinterpret context, or take an action you didn't anticipate. A workflow's failure modes are bounded by its branches. An agent's failure modes are bounded by... the model's imagination.

This isn't theoretical. I've seen production agents that worked beautifully in demos start issuing refunds to the wrong customers because the model misread an ambiguous order ID. The fix wasn't better prompting — it was pulling that specific sub-task out of the agent and into a deterministic check.

The Principle: Least Autonomy Necessary

The framework isn't binary. Most real systems end up as hybrids: a deterministic workflow that handles the known path, with an agent invoked only at the specific decision points where the path genuinely can't be predetermined.

I think of it as the principle of least autonomy. Give the system exactly as much decision-making freedom as the problem requires, and not one degree more. This looks like:

1. Map the process end to end. Identify every step and every branch.
2. Mark the unknowns. Which branches depend on information that only exists at runtime and can't be enumerated in advance?
3. Deterministic by default. Every step that can be hardcoded should be hardcoded.
4. Agent only at the seams. Deploy an agent (or a tool-calling LLM) only at the steps you marked as genuinely unknown.
5. Guardrails and evals everywhere. For every agent-driven step, define guardrails (constraints on what the agent is allowed to do) and evals (automated tests that grade the agent's outputs against known-good answers). Without these, you're flying blind.

The "double charge" example from earlier is a perfect case for this hybrid approach. The initial ticket classification? Probably deterministic — regex or a lightweight classifier can route "charged twice" to the billing investigation flow. Pulling up the user's payment records? Deterministic API call. But deciding whether the duplicate charge was a processor retry, a user double-click, or a genuine system bug? That's where the agent reasons over the evidence and picks a resolution path. And even then, the agent's available actions should be constrained: it can issue a refund, escalate to a human, or request more info — nothing else.

A Concrete Comparison

Let me put the two approaches side by side for the same problem — processing an insurance claim:

Pure Workflow: Receive claim → validate policy number → check coverage → calculate payout based on formula → flag if above threshold → auto-approve or route to adjuster. Every step is a known function. Works perfectly for straightforward claims.

Hybrid with Agent: Same workflow, but at the "check coverage" step, the claim description is ambiguous — "water damage from an appliance malfunction during a storm." Does the homeowner's policy cover this as appliance failure (covered) or flood damage (excluded)? A deterministic system would need a decision tree covering every possible ambiguity, which is effectively impossible. An agent reads the policy language, reads the claim narrative, and makes a coverage determination with cited reasoning. That determination then flows back into the deterministic workflow for payout calculation.

The agent handled one step. The workflow handled everything else. That's least autonomy in practice.

The Takeaway for Your Next Build

Before you spin up LangChain, CrewAI, or any agent framework, sit with your process map for thirty minutes and ask the one question at every node: Is this path known before execution? You'll almost certainly find that 70-80% of your system is deterministic, and the agent only needs to show up for the genuinely ambiguous 20-30%.

Build the workflow first. Add the agent at the seams. Wrap it in guardrails and evals. Ship something that's fast, cheap, and debuggable — and only as autonomous as it needs to be.

That's the framework. Save it for your next build, and if you want more decision frameworks like this one — ones you can actually use in production, not just talk about on Twitter — follow along at jayprasad.com.