Workflow or agent? A practical line I use to decide

I'm building ByteFlow, a no-code platform for agentic applications. It started as a workflow-automation tool and was later repositioned toward agents, so I've spent a lot of time thinking about where one ends and the other begins. I've also watched teams make the mistake in both directions: forcing an agent into a job a five-node workflow would do better, and stretching a workflow until it becomes an unmaintainable decision tree.

This is the checklist I use now. It applies whether you build with n8n, Make, Zapier, LangGraph, a hand-rolled loop or anything else. None of it depends on a particular product.

The one-sentence version

If you can write the steps down in advance, and they don't change based on what the input means, use a workflow. Add an agent only for the steps that have to read, judge or decide.

Most real systems end up as a workflow with one or two agentic steps inside it, not an "agent" from end to end.

Five questions to ask before reaching for an agent

1. Can you draw the flowchart today?
If every branch is known ("if the invoice is over X, route it to finance"), a workflow is cheaper, faster and easier to debug. Agents earn their keep when the branches depend on unstructured input, such as an email that might be a complaint, an order, or both.

2. What does a wrong answer cost?
A workflow usually fails loudly: a node errors and you get an alert. An agent can fail quietly, by confidently doing something that looks reasonable and is wrong. If an action is irreversible (refunds, messages to customers, writes to a system of record), put it behind a deterministic check or a human approval step, however good the model is.

3. How much of the input is unstructured?
If structured JSON comes in and structured JSON goes out, use a workflow. PDFs, voice calls, free-text chat messages and scanned forms are where an LLM step pays for itself. Even then it's usually an extraction or classification step feeding a normal workflow, not an open-ended agent.

4. Do you need the same output every time?
Compliance reports, billing and anything that gets audited want determinism. If a model is involved there, pin the prompt, constrain the output to a schema, validate it, and log inputs and outputs.

5. Who maintains it in six months?
A 40-node workflow full of nested IFs is also a program, just a hard-to-read one. When a workflow fills up with code nodes and string-matching branches trying to guess intent, that's usually the sign that one step should become an agentic step with a clear contract.

A pattern that works: agents as bounded steps

The design I keep coming back to:

1. Triggers and plumbing stay deterministic. Webhooks, schedules, dedupe, retries and rate limits are boring, and they should stay that way.
2. The agent gets a narrow job and a narrow toolset. "Classify this ticket and draft a reply" with read-only tools, not "handle support".
3. The output has a schema. Validate it. If validation fails, retry once, then route to a human.
4. Side effects go back through deterministic steps, with idempotency keys generated by the orchestrator (not by the model), so a retry doesn't send the same message twice.
5. Everything is logged, so you can answer "why did it do that?" later.

Where agents genuinely beat workflows

• Multi-step lookups where the next step depends on the last result. For example: "find the customer, check their recent orders, work out which one they're talking about".
• Voice and chat conversations. You can't flowchart a phone call. Callers interrupt, change their minds, and in India often switch languages mid-sentence. Rigid IVR-style trees handle that badly. A conversational agent with a small set of well-defined actions handles it much better.
• Choosing among many integrations. Once a system can reach hundreds of connectors or MCP servers, hand-wiring every path stops scaling. In general, giving a model every tool at once hurts accuracy. Filtering the toolset down to what's relevant for each step works far better.

The costs people forget

• Tokens per run vary. A workflow costs roughly the same every time it runs. An agent's cost depends on how many reasoning and tool-call loops it takes. Cap the steps per run.
• Latency. Every model call adds time. For voice, latency is the user experience, so measure end to end, not per call.
• Evaluation. Keep a small set of real inputs with expected outcomes, and re-run them after every prompt or model change. Without that, "it seemed fine" is your test suite.
• Pricing units. For voice, businesses find a per-minute price much easier to budget than token maths. When you compare quotes, check whether telephony, speech-to-text and text-to-speech are included, and whether billing is per second or per started minute. That's where quotes that look similar turn out to be very different.

Where the agent runs matters too

With enterprise teams in India, the first question often isn't "which model?" but "where does this execute, and where does our data live?" That's why we built an on-prem sandboxed execution option and let clients use Supabase as a data store they own.

The general lesson holds even if you never touch our product. Decide early where your agent executes, how isolated that environment is, and who owns the data it produces (run history, extracted fields, memory). That is far harder to retrofit than a prompt.

A quick decision table

What I'd tell my past self

Start with the workflow. Add an agentic step only when you catch yourself writing branches that try to guess what the input means. Keep the agent's job small, its tools few, and its side effects behind something deterministic.

I'd like to hear where others draw this line, especially people running voice agents in Indian languages or deploying agents on-prem.

Disclosure: I'm the founder of ByteFlow. This post was written with AI assistance and reviewed before publishing.