Artificial intelligence workflows are systems in which model calls and tool calls run along a path your code decides: classify a ticket, retrieve the policy, draft a reply, check it, send it. They differ from agents, where the model chooses the next step itself. Most production AI features are workflows, and the ones that fail in production usually fail on the plumbing around the model calls — retries, state, cost and visibility — rather than on the prompts.
This guide defines AI workflows against agents, walks through the five patterns that cover most of them, names the tools teams run them on, and sets out the production concerns that decide whether a workflow survives real traffic.
What are artificial intelligence workflows?
Anthropic's engineering team draws the line this way: workflows orchestrate models and tools through predefined code paths, while agents let the model direct its own process and tool use1. Both are "agentic systems" in the broad sense; the difference is who holds the control flow.
| AI workflow | AI agent | |
|---|---|---|
| Who picks the next step | Your code | The model |
| Number of model calls per run | Known, or bounded by the design | Unknown until the run ends |
| Cost per run | Predictable within a range | Wide spread; needs hard limits |
| Testing | Each step testable in isolation | End-to-end evaluation on whole runs |
| Failure | A named step fails | The loop wanders, repeats or stops early |
| Good fit | Tasks you can decompose in advance | Open-ended tasks where the path depends on what is found |
The same article's advice is to find the simplest solution that works, start with direct API calls rather than a framework, and add complexity only when it clearly improves the outcome1. In practice that means writing the workflow first and replacing a step with an agent only when the fixed path cannot handle the variety of inputs.
Five AI workflow patterns
Anthropic names five workflow patterns that cover most of what teams build1. Each one has a distinct cost and failure profile.
Prompt chaining
The task is split into sequential steps, each consuming the previous step's output, with optional checks between them. Outline, then draft, then translate. Chaining trades latency for accuracy: each call does one thing well. Put a cheap programmatic check between steps — valid JSON, required fields present, length within bounds — so a bad intermediate result stops the run instead of travelling to the end.
Routing
A first step classifies the input and sends it to a specialised follow-up: a different prompt, a different tool set or a different model. Routing is where cost control often lives, because easy inputs can go to a small, fast model and hard ones to a larger one. The classifier is a step like any other: log its decision, and measure how often it routes wrongly.
Parallelisation
Independent subtasks run at the same time and code combines the results. Anthropic separates sectioning, where different parts of a task run in parallel, from voting, where the same task runs several times and the outputs are compared1. Parallel branches multiply spend by the fan-out, and they multiply rate-limit pressure too: ten branches against one provider account arrive as ten concurrent requests.
Orchestrator-workers
A central model breaks the task into subtasks it decides at run time, hands them to worker calls and synthesises the results1. This is the boundary case: the shape of the run is no longer fixed, so its cost is not either. Cap the number of subtasks the orchestrator may create, and treat the orchestrator like an agent for budgeting.
Evaluator-optimizer
One call generates, another evaluates against criteria and returns feedback, and the loop repeats until the output passes1. It works when there is a clear rubric. It needs a maximum number of rounds and a defined outcome when the limit is reached — ship the best attempt, or hand it to a person — or a hard input becomes an unbounded loop.
Tools for AI workflow automation
The tools fall into three groups, and many teams use more than one.
- Visual automation platforms. n8n describes building AI workflows from language model providers, agents, tools, memory and MCP servers, and combining several models in one workflow2. These suit integration-heavy flows owned by operations teams.
- Durable execution engines. Temporal workflows recover after a crash by replaying an ordered event history of everything the workflow has done, reusing recorded activity results instead of running them again3. These suit long-running, side-effecting work where losing progress costs money.
- Agent and graph frameworks. LangGraph keeps a graph's state in a checkpointer, so a run can continue a conversation, resume after an interruption or recover from a failure4. These suit workflows with agent steps and in-process control.
The choice matters less than whether the tool gives you the properties below. Each is something you can test before production.
What production AI workflows need
Idempotent steps and safe retries
Model calls fail transiently: rate limits, overloaded providers, timeouts. Retrying is correct; retrying a step that already sent an email or wrote a record is not. Temporal retries a failed activity automatically under its retry policy and recommends writing activities so that running them again is safe5. LangGraph gives the same advice for human-in-the-loop pauses: the paused node restarts from its beginning on resume, so code before the pause runs again and its side effects should be idempotent6.
Concretely: give each step a deterministic key derived from the run id and the step name, record the step's result under that key, and check for it before doing the work again. Retry provider failures at the gateway or client with a capped backoff; retry business failures, such as a failed validation, in the workflow with a counted limit.
Durable state
A workflow that holds its progress in memory loses it on the first deploy or crash, and the restart pays again for every model call already made. Persist each step's output before moving on. For short chains, a row per run in your own database is enough; for runs that wait on people or on slow media jobs, use an engine or a checkpointer built for it.
Timeouts at every level
Set a timeout per model call, a deadline per step and a deadline per run. A streaming call that stalls holds a worker and a connection until something gives up; it should be your code, on a schedule you chose. Media generation is slower still and should run as an asynchronous job the workflow waits on, not as a held request.
Cost per run, and a budget per workflow
The bill arrives per request, but the decision is made per workflow: is this feature worth what one run costs? Sum the estimated cost of every call in a run — including retries, fallbacks and failed validations — and track the median and the high percentile, not only the average. Dividing by successful runs gives the figure to compare designs on, as cost per successful task shows.
A budget belongs in two places. Inside the run, stop when its estimated spend passes a ceiling. Outside the run, give each workflow its own key or project with a hard cap at the gateway, so that a bug in the run's own guard is still contained. Bounding AI agent loops covers both layers in detail.
A trace across every step
When a run produces a wrong answer, the question is which step went wrong. Give every run one trace id, attach it and the step name to every model and tool call, and record each call's model, provider, latency, tokens and estimated cost. The run can then be read back as one ordered timeline with cost by step; tracing an AI agent run shows the propagation with W3C traceparent.
Human in the loop
Some steps need a person: approving a refund, choosing between drafts, signing off generated media. The workflow must pause without holding resources and resume with the person's answer. LangGraph implements this as an interrupt that saves the graph's state and waits until the run is resumed with a value on the same thread6. Whatever the tool, record who decided, what they saw and when, as part of the run.
Evaluation per step and per run
Evaluate each step against its own criterion — the classifier's accuracy, the extractor's field coverage — and the whole run against the outcome that matters to the user. Re-run both when a model, prompt or provider changes. Workflows make this easier than agents do, because each step's input and expected output can be recorded and replayed. The wider stack an agent or workflow sits in is laid out in the AI agent infrastructure stack.
One gateway under every step, and Studio Flows for media
INFRO sits under the model calls of a workflow, whatever engine runs it. Each step calls INFRO with a gateway key on your own provider connections: through the OpenAI-compatible endpoint, or Anthropic's Messages and OpenAI's Responses APIs for agent SDKs. Routes fail over between your own connections when an attempt fails before the response starts, and budgets refuse a request before the provider call when a hard cap at the organization, project, member or key would be exceeded — so a workflow given its own key or project gets its own ceiling.
Each request can carry workflow, step and trace_id metadata (or X-INFRO-Workflow, X-INFRO-Step and X-INFRO-Trace-Id headers, with a W3C traceparent as the fallback), and every request records the provider that served it, the attempts, latency and estimated provider cost (request traces). Unit economics groups that by workflow and reports cost per run as a median and p90, a run being one workflow and trace id, with the unpriced share beside every figure.
For image, video and audio work, INFRO Studio's Flows chain Studio steps — text, pictures, video, sound and finishing — on one canvas, with the estimated provider cost shown before a run, a pick step that waits for a person to choose a result, and batches that run a Flow or recipe once per item of a list, up to 200, each item its own run retried alone if it fails (Studio).