# Workflow or agent? A practical line I use to decide > Source: > Published: 2026-09-27 12:28:46+00:00 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. 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. **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. The design I keep coming back to: 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. | Situation | Start with | |---|---| | Known steps, structured data | Workflow | | Known steps, one messy input (PDF, email) | Workflow + one LLM extraction step | | Open-ended conversation (voice or chat) | Agent with narrow tools + deterministic side effects | | Irreversible actions | A deterministic step or human approval, always | | Audited or must be repeatable | Workflow, with any model step pinned, schema-validated and logged | 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.*