Agentic Workflows: Patterns That Actually Work

In short

• Five patterns cover most real work: chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer.
• Anthropic's guidance is to find the simplest solution that works and add complexity only when it demonstrably improves outcomes.
• Every pattern has a cost signature: how many model calls it spends per record.
• Choose the pattern from the shape of the task, not from how advanced it sounds.
• Before production: structured outputs, an eval set, a cost ceiling, a human gate and a kill switch.

The foundation: one model, augmented

Before any pattern, there is the building block Anthropic calls the augmented LLM: a model given retrieval, tools and memory. One call, one answer, with access to the things it needs.

Most operators skip past this and lose money doing it. A single well-prompted call with the right context attached solves a surprising share of real tasks — classification, extraction, summarizing a transcript into fields — at one call per record and near-zero debugging surface. Only when that genuinely fails should you add steps.

Pattern 1: Prompt chaining

What it is: split a task into fixed steps, where each model call works on the previous output, with programmatic checks between them.

Use it when the task decomposes cleanly into subtasks you can name in advance.

Revenue example: step one extracts structured facts from a call transcript (outcome, objection, next step, amount). A code check validates that "outcome" is one of five allowed values. Step two writes the follow-up message using only those validated facts.

Why it works: the check in the middle is the point. You trade a little latency for the ability to stop a bad result before it propagates.

Failure mode: chaining a step that did not need to exist. Every link doubles the cost and adds a place to fail.

Cost signature: N calls per record, where N is the number of links.

Pattern 2: Routing

What it is: classify the input first, then send it down a specialized path.

Use it when the work splits into distinct categories that are genuinely better handled separately — one of Anthropic's named use cases is routing simple questions to smaller, cheaper models.

Revenue example: an inbound message is classified as quote request, support, billing or spam. Each label goes to a different downstream workflow with its own prompt, its own data and its own owner.

Why it works: it lets you write one narrow, high-quality prompt per category instead of one enormous prompt that tries to cover everything and does each part badly.

Failure mode: an ambiguous taxonomy. If two labels overlap, the classifier will flip between them and you will blame the model. Define the categories so a human could apply them consistently, then test that they can.

Cost signature: 1 classification call + 1 specialist call per record — and often lower total cost, because the cheap model handles the easy lane.

Pattern 3: Parallelization

What it is: run model calls at the same time, in two variations. Sectioning breaks independent subtasks apart; voting runs the same task several times and compares the answers.

Use it when speed matters, or when you want more than one opinion. Anthropic points to guardrails as a sectioning use case — screening content in a separate call from the one generating the response — and to voting for things like reviewing code for vulnerabilities from multiple angles.

Revenue example (sectioning): enrich a company by running "summarize what they sell", "find recent hiring signals" and "identify compliance constraints" as three parallel calls, then assemble.

Revenue example (voting): before an AI writes to a customer-facing field, run a second, separately-prompted call whose only job is to answer "does this message contain any claim not supported by the input data?"

Failure mode: voting on a question the model gets wrong the same way every time. Three identical mistakes look like consensus. Vary the prompt, not just the seed.

Cost signature: N simultaneous calls per record — same wall-clock time, multiplied spend.

Pattern 4: Orchestrator-workers

What it is: a central model breaks the task into subtasks, delegates them to worker calls, and synthesizes the results.

Use it when you cannot predict the subtasks in advance. That unpredictability is the whole justification, and Anthropic names it explicitly as the distinguishing condition.

Revenue example: "research this account and tell me whether it fits our ICP" — the orchestrator decides that this particular company needs a look at their careers page, their pricing page and a regulatory filing, while a different company needs something else entirely.

Failure mode: using it where routing would do. If you can list the subtasks in advance, you do not need a planner; you need a chain. Orchestrators are also where context grows fastest, and Anthropic's documentation warns that accuracy and recall degrade as token count grows — a phenomenon their docs call context rot. More context is not automatically better context.

Cost signature: 1 planning call + K worker calls + 1 synthesis call, with K unknown until runtime. Budget for the worst case, not the average.

Pattern 5: Evaluator-optimizer

What it is: one call generates, a second call evaluates it against criteria and gives feedback, and the first revises. Loop until it passes or you hit a limit.

Use it when you have clear evaluation criteria and iterative refinement measurably helps — Anthropic's own framing of the condition.

Revenue example: a first-touch message is generated, then graded against a written rubric (mentions a verifiable fact about the company, under 90 words, no unverified claims, one clear ask). Fails go back once with the specific failure attached.

Failure mode: the evaluator is too agreeable. Researchers at OpenAI and Georgia Tech argued in Why Language Models Hallucinate that standard training and evaluation procedures reward guessing over admitting uncertainty, because a model optimized to score well on tests does better by answering than by abstaining. Your evaluator inherits that bias. Give it an explicit, enumerated rubric and make "fail" the default rather than a judgment call, or it will wave things through.

Cost signature: 2 calls minimum per record, up to 2N with retries. Always cap the loop.

The MitHub pattern picker

Answer left to right. The first row that matches is your pattern.

When not to build an agentic workflow

Agentic systems trade latency and cost for task performance, and that trade is not always worth making. Skip the whole category when:

• A rule would do. If the decision can be written as a condition, write the condition. Rules are free, instant and testable.
• The step runs thousands of times a day on identical inputs. Multiply your cost signature by volume before you commit.
• You cannot describe what "correct" looks like. If you cannot grade an output, you cannot improve it, and you certainly cannot let it run unattended.
• The data is unreliable. An agentic workflow on bad data produces confident, well-structured wrong answers faster than a human could.
• Nobody owns it. An unowned workflow is a liability the moment it drifts.

The decision between a rule, an AI step and an agent is laid out in more detail in AI agents vs automation.

The four gates before production

MitHub's rule: no agentic workflow ships without these four.

1. Structured output. Every model step returns a defined shape — a label from a fixed list, a score, a JSON object — that code can validate. Free text is not an output, it is a suggestion.
2. An eval set. Twenty to fifty real, hand-labelled examples you run before and after every change. Without it, "the prompt is better now" is an opinion.
3. A cost and step ceiling. Maximum model calls per record, maximum loop iterations, maximum spend per day. Loops without limits are how a $40 workflow becomes a $4,000 one overnight.
4. A human gate and a kill switch. A person approves anything that reaches a customer or moves money, and one switch stops the whole thing. Human in the loop covers where to place the gate.

And one standing rule from MitHub's operating manual: a green execution is not proof of success. Open the record in the destination system and check the business result.

Where to go next

If the vocabulary here is new, start with What is an AI agent? and the plain-language mechanics in LLMs explained for operators. If you already know the patterns and want to know where they belong in a business process, map the process first — process mapping before automation — and then build in the Revenue Reverse Engineering faculty.