Patterns¶
Production techniques that transfer. Each one was paid for by a failure in a running system, and each is written to stand on its own — you should not need to know anything about the system it came from.
They are deliberately free of client, product and vendor identity. Where a concrete implementation matters it is named as an example, never as a prerequisite.
The contract¶
Every pattern has six sections, in order:
| Section | What it must do |
|---|---|
| Problem | the failure, concretely, including how it presents |
| Technique | what to do, specifically enough to apply |
| When it applies | the conditions that make it worth the cost |
| When it does NOT apply | where it is wrong, and what it does not cover |
| Evidence | the scar it came from |
| See also | related patterns |
When it does NOT apply is the section that makes the rest trustworthy. A technique with no stated limits is a slogan, and a reader cannot tell whether their case is one the author considered.
Running agents in production¶
| Pattern | The short version |
|---|---|
| Keep stdout clean on a stdio protocol channel | Redirect logging to stderr before any other import, or a library's stray print corrupts the protocol |
| A resilience ladder for streaming agent calls | Skip parse errors, retry process errors, fall back to single-turn — three failures that behave differently |
| Capture the subprocess stderr you were told to check | The library reports "check stderr" and discarded it by default |
Generated content you intend to keep¶
| Pattern | The short version |
|---|---|
| Validate generated artifacts, then regenerate rather than discard | Conversational leakage is a shape, not a phrase; re-ask with the failure fed back |
| Inject the literal date, never "today" | The model has no clock and will answer anyway |
| A gate ladder for auto-merging generated changes | Size cap, CI, read-only reviewer, merge-or-comment — each disqualifying |
| Never let an automated actor write to a protected branch | Enforce it in the writer class, not the credential |
Data and pipelines¶
| Pattern | The short version |
|---|---|
| MERGE on identity alone, then SET the rest | The MERGE pattern must contain exactly what the uniqueness constraint covers |
| Incremental index with an automatic full-rebuild fallback | Every failure mode routes to rebuild rather than to a subtly wrong index |
| The submit-poll-postprocess-review pipeline | Four teams built this independently and none of them named it |
Contributing¶
A pattern earns its place by having cost something. If you cannot write the Evidence section from a real failure, it is a preference, not a pattern — and if you cannot write When it does NOT apply, you have not finished thinking about it yet.