The prescriptive companion to the failure-mode field guide. That's what breaks; this is how to build so it doesn't. Named, opinionated, with the honest trade-offs and the signals to instrument.
A cheap, fast classifier reads the incoming request first and routes it to one of several narrow, single-purpose agents — each holding only the tools, context, and instructions its job needs — instead of a single god-agent carrying every tool definition and every rule for every possible request. The router's only job is picking the right specialist; the specialist's only job is the task it was built for.
Read the pattern →An agent loop runs under an explicit budget — a maximum step count, a token ceiling, and a wall-clock limit — plus a termination contract that forces every run to end in one of a small number of named states: success, failure, or escalation. When the budget is exhausted before the model reaches one of those states on its own, the harness ends the run itself rather than letting it continue indefinitely.
Read the pattern →Chunk boundaries follow the document's own structure — headings, table rows, list items, section boundaries — instead of a fixed token count, and each chunk carries its parent heading or identifying context in its own body. A table row is never separated from its header; a step is never separated from the procedure it belongs to. The chunk that gets embedded is always a complete unit of meaning, not an arbitrary slice.
Read the pattern →A cheap, high-recall first pass — vector search, optionally fused with keyword search — pulls a wide candidate set of 50 to 100 documents likely to contain the right answer somewhere. A precision reranker, usually a cross-encoder that scores the query and each candidate jointly, then re-sorts that set and applies a relevance floor allowed to return nothing rather than force a weak match to the top.
Read the pattern →The ingest pipeline subscribes to the actual change events of the source system — a webhook, a CMS publish hook, a database trigger — instead of re-crawling on a fixed schedule. An edit triggers a re-embed within minutes; a delete writes a tombstone that excludes the old chunks from retrieval immediately, before a full re-index even runs.
Read the pattern →Every tool argument is defined by a strict JSON schema — enums for known value sets, validated patterns for IDs, required fields wherever the tool genuinely needs them — with no free-text catch-all surface. A call that fails validation is rejected with a structured, actionable error the model can act on, never silently coerced or passed through to execution.
Read the pattern →Every tool the agent can call is scoped to the narrowest permission the task genuinely needs, and any action that can't be cleanly undone — a refund, a delete, an external message — requires an explicit human confirmation before it executes, not just a plausible-looking model decision. The two controls compound: least privilege bounds the blast radius of anything that slips through, and the checkpoint stops the worst actions from executing at all.
Read the pattern →A fixed, human-labelled set of real cases — each with a specific, checkable expected property, not a vibe — runs automatically in CI on every prompt or model change. A drop against the current pass-rate threshold blocks the merge the same way a failing unit test would, so a regression is caught before release, not after a user complaint.
Read the pattern →One trace ID follows a single request across every hop it takes — retrieval, every model call, every tool call — logged with enough detail to reconstruct exactly what happened after the fact. A sampled slice of traces, weighted toward low-confidence or error-flagged runs, lands in a queue a human actually reviews on a schedule, not only when a complaint forces someone to go looking.
Read the pattern →A cheap, fast model attempts every request first. A validation or confidence signal — a schema check, a self-reported confidence score, a downstream eval — decides whether that attempt is good enough to return, and only escalates to a stronger, pricier model on the fraction of requests the cheap one couldn't handle. Most traffic never reaches the expensive tier at all.
Read the pattern →The prompt is ordered with everything invariant across calls first — system instructions, tool definitions in a fixed serialization order, few-shot examples — and everything that changes per request — retrieved chunks, user input, timestamps — placed last. Because prompt caching only pays off when the shared prefix is byte-identical across requests, one volatile token near the front is enough to bust the cache for the entire call; ordering invariant-first is what makes the discount actually apply.
Read the pattern →No patterns match that filter yet.
The questions that come up before a team decides which patterns to adopt and which to skip.
The failure-mode field guide is diagnostic. It starts from a symptom you already have and works backward to a root cause and a fix. This library is prescriptive: it starts from an architectural decision you make before anything breaks. The cross-reference table above links them directly, and every failure mode traces to at least one pattern that prevents it from happening in the first place.
No. Most systems need three or four of these, not eleven. Every entry has an explicit "don't use it when" section for exactly this reason. Adopting a pattern your system doesn't need is its own kind of complexity debt, so start from whichever failure mode you're most exposed to and work from there, not from the full list.
No. Every pattern here is a structural or architectural decision: a routing layer, a schema, a caching order, a CI gate, not a prompt tuned to one model's quirks. They hold up whether the model behind them is a frontier API or a self-hosted open-weight model. See our take on staying model-agnostic by design.
A Ship Audit tells you which of these patterns your system is actually missing, prioritized against what's most likely to break first.