Agent vs. Workflow
Both chain multiple steps and tool calls — here's how to pick the right one for what you're building.
Agents and Workflows both execute multi-step, tool-calling logic. The difference is who decides the next step.
Agent
The model decides the next step, in real time, based on what the user just said.
Workflow
You decide the steps in advance — a fixed graph the engine executes the same way every run.
The core distinction
A Workflow is a typed step graph you author ahead of time: intent calls, agent runs, tool calls, and conditional branches, wired together in the visual builder. The branching logic — "if confidence is below 0.8, flag for review" — is known before the first run and identical on every run. This is what makes a Workflow testable and deployable: you can test-run it against sample input and see the exact same graph a production call would take.
An Agent doesn't have a fixed graph. It runs an LLM-driven tool-calling loop: given a user message, a set of available tools, and conversation history, the model itself decides which tool to call, in what order, and when it's done — turn by turn. Two calls with the same input can take different paths if the model reasons differently, because the "next step" isn't authored anywhere — it's inferred live.
When to use which
Use a Workflow when the branching logic is something you can draw as a flowchart before you build it — a support ticket comes in, check the knowledge base, draft a reply, flag for review below a confidence threshold. The steps and conditions are fixed; only the data changes per run.
Use an Agent when the "steps" can't be fixed in advance because they depend on a free-form conversation — a caller might ask to check availability, then book, then reschedule, then ask something unrelated, in any order, across many turns. This is exactly why LiyaEngine's voice-AI receptionist reference build (a dental-clinic scheduling assistant taking calls via Vapi) is an Agent, not a Workflow: there's no fixed sequence of "book → confirm → done" to author, because the caller — not a step graph — decides what happens next. The Agent's session continuity is what lets it track that conversation across turns, recalling what was said three turns ago without you threading state through the call yourself.
They compose
A Workflow step can run a standing Agent — so a deterministic pipeline (ticket in, triage, route) can hand off a sub-task to an Agent when that sub-task itself needs open-ended reasoning (drafting a reply in the customer's tone, deciding which knowledge doc actually answers their question). You don't have to choose one architecture for an entire product; pick per step.