Agents or workflows: who should choose the steps?
BusyBot gives you two ways to automate work with the same set of nodes. A workflow runs the steps you wired, in the order you wired them. An agent is given a goal and a set of tools and decides for itself what to call next. Both can send the email, update the CRM and write the row. The difference is who chooses the steps, and that choice decides how a piece of automation behaves when something unexpected happens.
This is how we decide which one to build.
Two ways to run the same nodes
A workflow is a directed graph of nodes. You place the nodes on a canvas and connect them; anything with no unmet dependency runs immediately, and branches that don’t depend on each other run at the same time. A workflow starts from a trigger (a webhook, a polling check or a schedule), by hand, or when an agent calls it. Every run is kept as an execution, so you can open a run later and see the exact data each node received and returned.
An agent is a saved configuration: the model that drives it, the tools it may use, the saved workflows it may run, the knowledge bases it may search, and the instructions that shape how it behaves. Given a task, it runs a loop: reason, call a tool, read the result, reason again, until the job is done. For longer tasks it drafts a plan first and checks its progress against it, changing course when something isn’t working.
The tools are the same in both cases. When an agent calls a tool, the platform runs the real node under your permissions, and the model never touches your credentials or the network directly.
When we wire it ourselves
We build a workflow when we can draw the steps before the first run and they will be the same every time.
Invoices that arrive by email. A Gmail Trigger watches a label, OpenAI Structured Output parses each invoice into line items with amounts and descriptions, and Google Sheets appends the rows. There is nothing to decide here. The model does one well-defined job, extracting fields, and the graph does everything else. An agent would add a planning step and the possibility of a different path on every run, and gain nothing from it.
Payment failures. A Stripe Trigger fires on each Stripe event, a Switch node sends each event type down its own branch, and the failed-payment branch posts to Slack and records the customer. Volume is the reason this is a workflow. It may run many times a day, and we want every run to cost about the same, behave the same and fail in the same findable place.
The common thread is that the process is already known. A workflow writes it down once, and its executions show you exactly which node did what when a run goes wrong.
When we let the model choose
We build an agent when the right next step depends on what the last step found.
Support questions. A customer writes in. Sometimes the answer is in the product documentation, sometimes it depends on the customer’s account, and sometimes it needs a ticket for a person. An agent with the documentation in a knowledge base, and Zendesk and HubSpot as tools, can search the docs, look up the customer, and decide whether to answer or open a ticket. Wiring that as a graph means guessing every branch in advance, and the branches nobody guessed are exactly the questions that go wrong.
Open-ended research. “What changed in this vendor’s terms since last year, and does it affect us?” An agent with a web-search node and the contract in a knowledge base can search, read what it finds, run a second, narrower search based on the first, compare the result against the contract, and write it up. How many searches it runs, and what it reads next, are decided as it goes. That is the job an agent is for.
The common thread here is that the inputs vary and the path depends on them.
The middle ground: workflows as agent tools
A lot of real automation is a mix: one judgement call surrounded by steps that should never vary. BusyBot lets an agent run a saved workflow as one of its tools, and that is the pattern we recommend for most jobs with both kinds of step.
Billing a client. Creating an invoice in Invoice Ninja, emailing it to the client and recording it in a spreadsheet is the same three steps every time, so we save it as a workflow. The agent decides whether a client should be invoiced, for what and when, and then calls that workflow as a single tool. Inside the workflow it cannot improvise a fourth step or skip the email, because the order lives in the graph, not in the prompt.
The split keeps the model’s freedom where it helps and removes it where it is a risk. It also keeps the fixed part testable on its own: you can run the workflow by hand and watch each node’s output while you get it right, before any agent depends on it.
A rough rule
When we can’t decide, we ask four questions.
- Can we draw the steps today? If yes, start with a workflow. If the drawing keeps growing branches for cases we keep discovering, the job probably wants an agent.
- What does a wrong step cost? Sending an email, charging a card or deleting a record belongs inside a workflow the agent calls, not among the free choices in the agent’s loop.
- How often does it run? High-volume, repetitive jobs belong in workflows, where each run does the same work.
- Who reads the output? If a person reviews every result anyway, an agent’s variability is cheap. If nobody does, prefer the graph.
Cost and control
Both approaches draw on the same credit balance, but they spend it differently. Wherever a model runs, its tokens are metered, and an agent’s loop can make several model calls for one task: planning, reasoning about each step, checking its progress. A workflow calls a model only at the nodes where you put one, and its compute is charged by the hours its runtime is alive beyond what your plan includes. The pricing page has the figures for each plan.
None of this makes one approach better than the other. A workflow is a decision you make once; an agent is a decision you delegate every time it runs. We pick the one that puts the decision where it belongs, and when the honest answer is both, the agent calls the workflow.
Last reviewed .