Consider a realistic workflow: an inbound contract arrives, gets summarized, checked against your playbook, routed by risk level, and — if risky — held for legal review before a response goes out. That's five steps, two branches, and one human gate. The central design decision is where the orchestration logic lives. This pattern's answer, aligned with how Anthropic's own guidance separates concerns: your code owns the workflow graph; Claude owns the judgment inside each node. Anthropic's prompting documentation explicitly covers chaining complex prompts as a technique — decomposing a task into focused steps outperforms one mega-prompt — and the "use the model for judgment, code for everything else" split keeps every transition testable, loggable, and replayable.
Chains: one job per step
Each chain step is a separate Messages API call with its own focused prompt, and each step's output should be machine-readable so the next step can consume it deterministically. Structured outputs (GA on the Claude API, Claude Platform on AWS, Amazon Bedrock, and Google Vertex AI; beta on Microsoft Foundry) are the load-bearing feature here: when step 2's input is step 1's schema-guaranteed JSON, a whole class of "the model phrased it differently this time" bugs disappears. Two cost levers apply across a chain: keep the shared preamble (role, policies, definitions) identical across steps so prompt caching serves it at 0.1x base input price, and use a cheaper model for mechanical steps — Haiku 4.5 to summarize, Opus 4.8 to judge.
Branches: route on fields, not vibes
Branching is an if statement in your code reading an enum from the previous step's schema — never a second model call to interpret prose. When a step is itself a decision ("approve / revise / reject"), make the decision field an enum in the schema and, if using tools, force the choice with tool_choice: {"type": "tool", ...} with strict: true for guaranteed-valid input (noting the documented constraint that forced tool use is incompatible with extended thinking). Every branch decision gets logged with the step's request ID — each API response carries one — so any workflow run can be reconstructed end to end.
Error handling: classify, then act
The documented error semantics give you a clean retry policy for every node:
| Failure | Documented behavior | Orchestrator action |
|---|---|---|
| 429 / 5xx / connection errors | Retryable; official SDKs auto-retry with backoff, honoring retry-after | Retry with backoff, then park the run |
| 400 / 401 / 403 / 404 / 413 | Not retryable — the request is wrong | Fail the run to a dead-letter queue; alert |
stop_reason: "max_tokens" | Output truncated, possibly invalid JSON | Retry once with higher max_tokens |
stop_reason: "refusal" | HTTP 200, billed, may not match schema | Route to human review, never auto-retry |
stop_reason: "pause_turn" | Server-tool turn paused (default limit 10 iterations) | Re-send the conversation as documented; the server resumes |
Two more documented operational rules: for requests that may run long, use streaming or batch — SDKs validate that non-streaming requests won't exceed a 10-minute timeout — and make every step idempotent (see the extraction pattern) so a mid-workflow crash can replay from the last checkpoint without double-charging a customer or double-sending an email.
Humans in the loop, at the right altitude
Place human gates where decisions are consequential and irreversible — sending external communications, changing money, deleting data — not on every step. Because your code owns the graph, a gate is simply a workflow state parked in your queue or ticketing system until someone approves, with the full payload design covered in the escalation pattern. If you build on Managed Agents instead of orchestrating yourself (beta, first-party Claude API and Claude Platform on AWS only), approval gates are built in: tools set to an always_ask permission policy pause the session until your application sends an allow/deny confirmation event.
Where to go next
When steps stop being a fixed graph and the model chooses its own next action, you've crossed into agentic loop territory — different reliability rules apply. The feature matrix shows per-platform support.