Lessons 00 through 32 built a tool-calling system one correct decision at a time: how to shape a schema, how to write a description, how to test a handler, how to version a tool without breaking the agents already calling it. This lesson looks at what happens when several of those decisions go wrong in ways that keep recurring across teams and codebases, regardless of what the underlying capability actually does. It is a consolidation lesson on purpose: each failure below gets a name, a stated symptom you'd actually observe in production traces or an eval run, a root cause, and a fix specific enough to act on -- not a vague complaint that a tool "feels broken."
Several of the ten patterns here are not independent defects with independent fixes. A handful of them are literal opposites of each other, sitting at two ends of the same axis, and the corrective instinct that genuinely fixes one is exactly the instinct that creates the other if it's pushed past the point that actually helps. Naming both ends explicitly is the point of this lesson: a team that only knows one half of a pair will "fix" a real problem by walking straight into its mirror image, and neither the schema linter nor a code reviewer skimming a diff will catch that kind of regression, because nothing about it looks wrong in isolation.
Read each pattern the same way: symptom first -- what you'd actually see in a tool-selection eval from lesson 25, a trace from lesson 26, or a production incident -- then root cause, then fix. The lesson closes with a short review checklist built from all ten, meant to be walked category by category against an existing catalogue on a fixed cadence, not read once and forgotten.
Analogy🏏Cricket
🏏 Think of it like cricket: every good batting coach at a first-class academy keeps a named list of recurring technical faults, not a running commentary of individual mistakes. "Playing around the front pad" is a fault: the symptom is getting bowled or lbw to deliveries that shape back in, the root cause is a bat that comes down at an angle instead of straight past the pad, and the fix is a specific drill -- throwdowns angled to force the bat through the gate. "Chasing the wide one" is a different named fault: the symptom is caught behind, the cause is hard hands reaching outside the frame, and the fix is a leave-based net session. A coach who just says "you got out again" teaches nothing; a coach who says "that's playing around the front pad, here's the drill" gives the batter something to correct on their own the next time it recurs, against any bowler, in any match. Cheteshwar Pujara's long county stints were built exactly on drilling named faults out of his game one at a time, not on vague encouragement to concentrate harder. A tool catalogue accumulates the same kind of recurring, nameable faults -- not one broken tool, but a pattern that keeps reappearing across different tools written by different engineers. Naming the pattern, stating its symptom, root cause and fix, is what turns "this tool feels broken" into something a team can actually correct -- and, just as important, a coach who over-corrects one fault can create a new one, which is the exact trap this lesson has to watch for too.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.