Agentic workflows: patterns that hold up in production

Workflows vs agents

A useful distinction, popularized in Anthropic’s writing on building agents: in a workflow, your code defines the path and the model fills in steps. In an agent, the model decides the path – which tool to call next, whether to retry, when to stop.

Workflows are predictable, cheaper, easier to test and easier to debug. Agents handle open-ended problems where you can’t enumerate the steps in advance: debugging an unfamiliar failure, researching across several systems, working a ticket whose shape you don’t know until you read it.

My default: start with a workflow and add model-driven decisions only at the points where the fixed path demonstrably fails on your evaluation set. Many successful “agents” in production are workflows with one or two agentic steps inside them.

The core patterns

Almost every AI agent workflow is built from these pieces.

• Prompt chaining. Break a task into sequential steps, each a model call with a narrower job, with code checks between them. Outline, then validate the outline, then draft. Trades latency for accuracy and makes each step testable.
• Routing. Classify the input first, then send it to a specialized prompt, tool set or model. Billing questions go one way, bug reports another; easy queries go to a small model, hard ones to a large one. Routing is often the highest-value pattern because it lets every downstream step be simpler.
• Parallelization. Run independent calls at once. Either split a task into sections (check a contract’s payment terms, liability and termination clauses in parallel) or run the same task several times and vote, which helps for judgements like “is this content safe”.
• Orchestrator–workers. A coordinating model breaks a task into subtasks it couldn’t have known in advance, dispatches them to worker calls (each with a focused context and tools), and combines the results. Good for multi-file code changes and research across many sources. Expensive – each worker has its own context – so use it where the subtasks really are unpredictable.
• Evaluator–optimizer loop. One call produces output; another evaluates it against explicit criteria and returns feedback; repeat until it passes or a limit is hit. Works when you can state clear criteria and the evaluation is easier than the generation – translation quality, test-passing code, schema-valid extraction. Where a deterministic check exists (tests pass, schema validates), use it instead of a model as the evaluator.
• Autonomous agent loop. The model plans, calls tools, observes results and iterates with no fixed path. Needs bounded iterations, clear stopping conditions, good tool design and a sandbox or permissions model that limits damage.

Designing tools for agents

Agents are only as good as their tools, and tool design is where most of the effort on an agent project should go.

• Shape tools around tasks, not endpoints. One “find customer by email and return plan and status” tool beats three CRUD calls the model must chain correctly.
• Write descriptions like documentation for a new colleague: when to use the tool, when not to, what it returns, and what errors mean.
• Return compact results with the fields the next step needs. Huge results crowd out the model’s attention and cost tokens.
• Make errors actionable. “Card not found – use search_cards to look up by title” lets the model recover; a stack trace doesn’t.
• Keep the tool count small per step. Route to a subset rather than exposing everything at once.
• Expose them through a standard interface where other clients will use them – an MCP server lets the same tools work from Claude, ChatGPT and IDEs. See what is an MCP server.

Human-in-the-loop design

Humans in the loop aren’t a sign the system failed. They’re how you ship agentic systems before they’re perfect, and how you collect the data to improve them. The patterns:

• Approve before act. The agent proposes an action with exact arguments; a person confirms. Use for anything irreversible or external: payments, emails to customers, merges, deletions.
• Draft and review. The agent produces a draft (reply, pull request, report) that a person edits and sends. The edit rate is your quality metric.
• Escalate on uncertainty. The agent hands off when confidence is low, tools fail, or it hits a limit – with full context so the human doesn’t start from scratch.
• Review after the fact. For low-risk, reversible actions, let the agent act and sample its work for review. Watch for drift.
• Interrupt and redirect. Let people see what an agent is doing while it runs and stop or steer it. This needs the agent’s state to be visible somewhere humans already look.

Avoid approval fatigue: if people approve dozens of trivial actions an hour, they stop reading. Gate the consequential actions and let the safe ones flow. The security reasoning behind which actions need gates is in AI agent security.

Real examples

• Agents on a shared kanban board. In Craaft, agents connect through MCP or the REST API and work the same board as the team. An agent picks up a card, reads its description and checklist, does the work, comments with what changed, and moves the card to review. A human reviews it like any colleague’s work. The board is the human-in-the-loop interface: state is visible, and anyone can step in by moving or commenting on the card.
• Coding agents behind code review. An orchestrator reads a ticket, explores the codebase, makes changes across files, runs the tests and iterates until they pass (an evaluator loop with a deterministic check), then opens a pull request. The review step is the gate.
• Support triage and drafting. A router classifies the ticket, a retrieval step pulls relevant docs and account data, a drafting call writes the reply, and a policy check validates it before a human sends it. Mostly workflow, very little autonomy, and that’s why it’s reliable. More in AI for customer support.
• Document processing. Parallel extraction calls per section, schema validation, and a review queue for low-confidence fields.

Running agentic workflows in production

• Durable execution. Long-running workflows need to survive restarts and deploys. Persist state between steps, and make tool calls idempotent so retries don’t double-act. A job queue or workflow engine you already run is usually enough.
• Budgets. Cap iterations, tokens, wall-clock time and cost per run. Stop on repeated identical tool calls.
• Tracing. Record every model call and tool call with inputs, outputs, latency and tokens, linked by run ID. Debugging agents without traces is guesswork.
• Evaluation. Test the whole workflow on realistic tasks, plus the individual steps. Track task success rate, steps per task and cost per task. See LLM evaluation.
• Versioning. Prompts, tool descriptions and model choices are code. Version them, review them and roll them out gradually.

Where to start

Pick one process, write down the steps a person takes, and implement it as a workflow with the model handling the language parts. Measure it. Then replace the fixed step that fails most often with an agentic one and measure again. That incremental path gets you to a reliable system faster than starting with a fully autonomous agent and trying to rein it in. For choosing the right first process, see AI agents for business; if you’d like help building it into your product, that’s my AI agent development work.

Related

• AI agent development for work that actually ships
• AI agents for business: what’s worth building
• What is an MCP server?
• LLM evaluation for product features
• AI agent security: a practical threat model
• Custom MCP server development for your product