One phrase, two architectures
When people say "agentic workflow," they mean one of two designs. The first is the pipeline: a graph written in code where each node invokes an agent, output flows to the next node, and the framework owns control flow. The second is conversation-first: the process is stored as structure, the agent works in its own environment (a coding client, a chat), and an engine feeds it one step at a time and decides whether it may advance.
Pipelines shine when the task is fixed, high-volume, and headless: classify, extract, transform. The conversation-first style shines when the work is the kind humans do in sessions: build a feature, produce an article, run a sales motion, because the human can be in the loop natively, the agent keeps its full working context, and the process survives across sessions and executors.
Steps: instructions at the moment they apply
The atom of a workflow is the step: a named unit with instructions for exactly that unit. The delivery discipline is what separates a step from a prompt section: the agent receives the current step when the work reaches it, not the entire process up front. A model holding one instruction executes better than a model juggling forty, and an operator editing one step fixes every future run.
Steps are also where organizational knowledge stops being tribal. "Reproduce before fixing" or "cite every claim" written into a step is process that executes, not advice that depends on who is driving.
Gates: conditions the engine checks
Between steps sit the controls. A gate is a condition evaluated by the engine on every attempted advance: approval given, children complete, status reached, context recorded. The run does not move until the condition is true, and a refused advance says exactly what is missing.
This is the mechanism that lets a workflow make promises: "nothing ships without sign-off" is enforceable when sign-off is a gate, and merely aspirational when it is a sentence.
Decisions and branches: detours, not forks
Real processes branch: a bug that cannot be reproduced closes instead of proceeding; unclear scope routes to research first. A robust way to model this is decisions that evaluate real fields of the work and, when a condition matches, detour into a sub-workflow that runs to completion and returns.
The detour design keeps something valuable: the main line of the run stays single and auditable. You can always answer "where is this run?" with one cursor, even while a branch executes its own steps and gates one level down.
Loops: how work gets to done, not just through
The most important control flow in quality-bearing work is the loop: review finds problems, work returns to the fix step, and the cycle repeats until the review passes. In a conversation-first engine, this is the return trip from an invoked sub-workflow pointing backward: findings send the run back, the gate ahead only opens on green.
Loops are also where the honesty of a workflow shows. A pipeline that cannot loop ships whatever the last node produced. A workflow that loops until a gate passes has a definition of done that is enforced, not hoped for.
Parallelism and executors: lanes, then merge
Some steps do not depend on each other: the fix, its tests, its docs. A parallel group runs them concurrently, each lane with its own agent, potentially on its own runner, and merges before the workflow continues. The process stays one process; the execution fans out and comes back.
Decoupling the process from its executors is what makes the whole design durable: the same workflow can run in a person's coding client today and on a scheduled backend next month, because the engine owns the steps and the executors own only the compute.
Choosing your architecture
A short decision aid:
- Fixed transformation at volume, no humans mid-flow: build a pipeline
- Session-shaped work, humans sometimes in the loop, quality bar enforced by review: conversation-first engine
- Need the same process attended today and unattended later: conversation-first, since the process must outlive the driver
- Need per-run auditability with one answer to "where is this run?": an engine that keeps a single cursor