Agentic workflows — 4 patterns that survived 90 days in production
· Insights
11 agentic patterns tested, 4 survived production. Plan-then-execute, tool-augmented RAG, multi-agent with handoff, eval-gated deploy. Here's what died and why.
11 agentic patterns tested over 90 days. 4 survived production. The rest broke in ways the demos never show — infinite loops, token explosions, silent failures, hallucinated tool calls. Here's what survived, what died, and why.
Survivor #1 — Plan-then-execute
The pattern: agent generates a step-by-step plan first, then executes. No tool calls during planning.
# Execute step for step in plan.steps: result = execute(step) # tool calls happen here if result.failed: break
This won because planning and execution have different failure modes. Planning fails on bad context. Execution fails on bad tool output. Separating them means a planning failure is cheap (one LLM call) and an execution failure is debuggable (you see which step broke).
The ReAct-style "think-act-observe in one loop" pattern died because errors compound — a bad observation corrupts the next thought, which corrupts the next action.
Survivor #2 — Tool-augmented RAG
The pattern: agent retrieves relevant docs via a search tool, then reasons over them.
# This: response = claude.complete( query, tools=[searchcorpustool], # agent decides when to search )
The difference: with a search tool, the agent decides when it needs more context. With pre-fetched RAG, you're guessing what's relevant — and you're wrong 30% of the time.
I tested both on a 1,000-doc support knowledge base. Tool-augmented RAG got 87% correct answers. Pre-fetched RAG got 61%. The 26-point gap is the difference between "ship it" and "scrap it".
Survivor #3 — Multi-agent with explicit handoff
The pattern: specialist agents with clear responsibilities, explicit handoff protocol.
Each agent has one job. The router decides who handles the request. The synthesizer merges outputs. No agent does another agent's job.
What died: open-ended multi-agent systems where any agent can call any other agent. Infinite loops. Token explosions. Two agents arguing about whether to call a third.
The handoff protocol matters — I use a strict "one agent in, one agent out" rule. A specialist agent can't escalate or delegate. It does its job and returns.
Survivor #4 — Eval-gated deployment
The pattern: every agent change goes through an eval suite before deploy.
Without eval gates, agent changes drift. Last month I shipped a "small prompt tweak" that improved 3 cases and broke 17 others. Eval gates catch this before users do.
The eval suite is just a JSON file of input/expected-output pairs:
Run it on every PR. Block merges if accuracy drops. This is the difference between agents you can ship and agents you can't.
What died — and why
Cost reality check
I tracked token cost across all 11 patterns over 90 days:
Multi-agent is 5x more expensive than single-agent with tools. Most production tasks don't need it.
The decision tree
Before adding an agent, ask:
1. Can a single LLM call with good context solve this? If yes, no agent needed. 2. Can a single agent with 2-3 tools solve this? If yes, use plan-then-execute. 3. Does the task need parallel work? If yes, multi-agent with handoff. 4. Is the cost of being wrong higher than the cost of an extra LLM call? If yes, add eval gates.
That's it. 90% of "agentic" use cases are #1 or #2. Most teams reach for multi-agent when they need single-agent with better tools.
Verdict
Ship these 4 patterns. Skip the rest until you have a specific reason not to. The hype around "autonomous agents" misses the point — production work is 80% boring single-agent with good tools and 20% multi-agent with strict handoff.
If you want help designing an agentic workflow for your use case, the work with me page has a build-sprint option. For more on Claude Code specifically, see my MCP servers ranked list and Claude Code vs Cursor.