5 AI Agent Design Patterns That Survive Production

Microsoft's "AI Agents for Beginners" course teaches five patterns that show up in nearly every serious agent system: tool-use, planning and reflection, multi-agent handoff, human-in-the-loop escalation, and some form of self-check before output ships. Call them the five AI agent design patterns everyone now points to. On a slide, each one is a clean diagram with an arrow in and an arrow out. In a fleet running 325 agents against real traffic, only some of those diagrams survive contact with what actually happens: rate limits, malformed tool responses, an agent that's technically correct but about to do something expensive.

The academic version of each pattern teaches you the shape. It doesn't teach you the failure mode the shape exists to prevent — and that's the only part that matters once you're not the only one hitting the system. I've watched all five of these patterns break in production, watched the fix, and watched which ones actually held once volume went up. This is the field version.

The throughline across all five: AI agent design patterns earn their place in an architecture by naming a specific way agents fail unsupervised, not by looking elegant in a diagram. If a pattern can't point at the failure it prevents, it's decoration.

Pattern 1 — Tool-Use: Prevents Hallucinated Actions

The textbook definition of tool-use is simple: give the model a defined set of functions, let it decide when to call them, and it stops guessing at facts it doesn't have. That's true, but it undersells what tool-use is actually defending against in production.

The failure mode tool-use prevents is the model inventing an action instead of taking one — describing a file it didn't write, summarizing a query it didn't run, reporting a deploy that never happened. Without a tool boundary, the model has no way to distinguish "I did this" from "I would plausibly say I did this." Tool calling turns every claim of action into a verifiable event: a function signature, a return value, a log line.

Where this breaks in the field isn't the calling convention — it's the response contract. Agents fail quietly when a tool returns something the calling agent didn't expect: an empty array instead of an error, a 200 with a null body, a truncated JSON blob from a flaky upstream. The pattern looks solved in a demo because demos don't hit degraded APIs. Production does, constantly.

tool_result = call_tool("fetch_pr_status", {"pr": 4821})
# demo assumption: tool_result is always a well-formed dict
# production reality: tool_result can be {}, None, or a 502 body
if not isinstance(tool_result, dict) or "status" not in tool_result:
    raise ToolContractViolation("fetch_pr_status", tool_result)

Tool-use that survives production validates the shape of what comes back, not just whether the call succeeded. That single check is the difference between an agent that degrades gracefully and one that hallucinates a status because the real one came back malformed.

Pattern 2 — Planning and Reflection: Prevents Compounding Drift

Planning and reflection — decompose a task, execute a step, check the result against the plan, adjust — reads as an efficiency pattern in the course material. Fewer wasted actions, tighter loops. In production it's a containment pattern. The failure it prevents is an agent executing five steps in the wrong direction before anything notices, because nothing checked the first step.

Without a reflection checkpoint, error compounds silently. An agent that misreads a requirement on step one doesn't just fail step one — it builds steps two through five on top of the wrong foundation, and the failure surfaces three files later, in a place that has nothing to do with the actual mistake. Debugging that after the fact means untangling five steps to find the one that was rotten. A reflection checkpoint after each meaningful step catches the drift where it started.

The part the textbook skips: reflection is expensive if you do it after every micro-action, and useless if you only do it at the very end. The teams running this well in production calibrate the checkpoint to the blast radius of the step — reflect hard before a step that writes to shared state, skip it for a step that only reads. That calibration is the actual skill; "add a reflection loop" is not.

Pattern 3 — Multi-Agent Handoff: Prevents Context Overload

Multi-agent handoff — splitting work across specialized agents that pass context to each other — is usually pitched as a division-of-labor pattern. Specialists are better than generalists. True, but that's not the failure mode that forces you into this pattern in production.

The real failure it prevents is context overload: one agent holding so much accumulated state — the original task, five tool results, three prior corrections, the user's original phrasing — that its judgment degrades even though nothing about the model changed. A single agent carrying an entire multi-step build from spec to test to deploy will start making worse decisions late in the run, not because it got dumber, but because the signal-to-noise ratio in its context collapsed.

Handoff fixes this by giving each agent a narrow, fresh context scoped to its part of the work. A backend agent doesn't need the frontend agent's CSS debugging history. A QA agent doesn't need the seventeen dead-end approaches a build agent tried and abandoned. I write about the mechanics of getting this right — file territory ownership, peer-to-peer messaging instead of a single bottlenecked coordinator, and what happens when routing between agents is deterministic instead of LLM-guessed — in Twenty-Four Agents. Nine Rules. Zero LLM Routing. The rule count there isn't decorative; it's what replaces a model deciding, non-deterministically, which agent should go next.

Handoff done badly just relocates the context-overload problem instead of solving it — a coordinator agent that re-reads every sub-agent's full output before delegating is carrying the same overloaded context, one layer up.

Pattern 4 — Human-in-the-Loop Escalation: Prevents Autonomous Damage

Human-in-the-loop gets taught as a safety net — a pause before the risky step, a confirmation dialog. That framing makes it sound optional, a nice-to-have for cautious teams. In a fleet where agents can push code, move money, or close tickets, it isn't optional. It's the pattern that prevents autonomous damage: an agent taking an action that's correct given its own reasoning but wrong given context it doesn't have — a force-push to a branch someone else is actively working on, a database migration during a freeze window, a merge that bypasses a review someone specifically asked for.

The failure mode this prevents isn't "the agent got the task wrong." It's "the agent got the task right and the action was still the wrong one to take unsupervised." Those are different bugs and they need different defenses. Correctness checks catch the first. Escalation gates catch the second.

Where teams get this wrong is escalation granularity — either everything pauses for approval (nobody reads the queue, the gate becomes theater) or nothing does (the gate was never real). The pattern that survives production ties escalation to blast radius, not to task type: a destructive git operation, a production database write, a customer-facing message all escalate; a read, a test run, a draft PR do not. That's a design decision made per-action, not per-agent.

Pattern 5 — Verification Gates: Prevents Confident Wrongness

The last pattern — some form of self-check or verification before output ships — is the one most commonly skipped, because it's the one that doesn't demo well. A verification gate doesn't make the happy path faster. It exists entirely to catch the case where the agent is confidently, fluently wrong.

That's the specific failure mode: an LLM producing output that is well-formatted, plausible, and incorrect, with nothing in the surface presentation to distinguish it from correct output. A demo run rarely surfaces this because demo runs are short and the operator is watching closely. Production runs are long, unwatched, and parallel — exactly the conditions under which confident wrongness slips through.

A real verification gate isn't "ask the model if it's sure." That's the same model, same blind spots, marking its own homework. What holds up is an independent check — a test suite that actually runs, a second agent with a different prompt and no visibility into the first agent's reasoning, a static rule that doesn't care how convincing the explanation sounds. That's also why verification tends to live as its own composable unit instead of a paragraph buried in a longer prompt — the same instinct behind turning one tool into a fleet of them, which I cover in Claude Code Skills: 6 Stacks That Turn One Tool Into a Fleet.

What Makes These AI Agent Design Patterns Survive Production

None of these five patterns are wrong in the textbook. They're incomplete without the failure mode attached. "Add tool-use" doesn't tell an engineer anything actionable. "Add tool-use because agents will otherwise report actions they didn't take, and here's the response-shape check that catches it" does.

That's the gap between a course and a production system, and it's the case I make at length in AI Agents in Production: The Operator's Handbook — the patterns are the easy 20%. Naming what they defend against, and instrumenting for the moment a defense fails, is the other 80%.

If you're choosing the runtime these patterns live in, that decision shapes how much of this you get for free versus how much you build yourself — I compare that tradeoff directly in LangGraph vs CrewAI vs Claude Code: Picking an AI Agent Framework.

One morning that put three of these five patterns to work at once — tool-use, handoff, and a verification gate, back to back, on real branches — is documented in Three PRs. One Morning. It's a smaller-scale version of the same fleet these patterns run in day to day, and tesseractintelligence.io is where that broader agent-operations work lives.

You don't need a framework decision to start applying the verification-gate pattern today. The build-fix skill runs exactly this loop against your own codebase — fix one error, re-run, verify, stop and reassess after two failed attempts on the same error instead of guessing a third time. It's one of the free skills built to demonstrate the pattern, not just describe it. Start with the 7 free skills at jeremyknox.ai/skills-library — no signup.