{"slug": "12-rules-for-building-ai-agents-that-survive-production", "title": "12 Rules for Building AI Agents That Survive Production", "summary": "An engineer who took the Claude Certified Architect exam distilled 12 rules for building production-grade AI agents from the experience. The exam tests judgment over trivia, emphasizing principles such as enforcing determinism in code rather than prompts, picking the cheapest fix for root causes, and avoiding over-engineering. The rules also cover tool selection, attention management, and error handling, with traps like suppressing errors or relying on model confidence highlighted as common pitfalls.", "body_md": "I sat the Claude Certified Architect exam expecting questions about model parameters, context limits, and API flags. I got something else. The exam barely tests trivia. It tests judgment: given a broken agent and four plausible fixes, which one actually addresses the root cause?\n\nThe interesting part was how few ideas the whole thing rests on. The same handful of rules kept deciding the \"right\" answer, and they are the same rules that decide whether an agent holds up once real users touch it. Below are the twelve I kept running into, plus the four traps that look like solutions and are not.\n\nThis is my own study material, derived from publicly available exam guidance. It reflects how I build, not an official Anthropic position.\n\n**The twelve rules**\n\nEnforce determinism in code, not in prompts\n\nIf a rule has to fire every single time, it is not a job for a prompt. A prompt is a suggestion the model usually follows. \"Usually\" is not a guarantee. When you need a guarantee, put it in a hook, a gate, or an allowlist. Code enforces. Prose requests.\n\nPick the cheapest fix that hits the root cause\n\nBefore you build a subsystem, try the levers that cost minutes: a sharper tool description, an explicit acceptance criterion, a config change. Most \"we need to build X\" moments dissolve once you test the cheap fix first. Reach for the classifier only after the one-line change fails.\n\nBad tool selection? Start with the descriptions\n\nWhen an agent keeps picking the wrong tool, the description is almost always the culprit, not the model. Tool descriptions are the primary signal the model uses to choose. Rewrite them to say exactly when to use the tool and when not to, before you go anywhere near few-shot examples.\n\nOver-engineering is almost always the wrong answer\n\nNarrowing scope and improving the prompt beat a new subsystem far more often than engineers expect. Every subsystem you add is one more thing to debug, monitor, and keep in sync. Complexity is a cost you pay forever, not once.\n\nA bigger context window does not fix attention\n\nStuffing more into the window does not make the model pay better attention to what matters. It often does the opposite. Decomposition and structure fix attention: smaller tasks, cleaner inputs, explicit boundaries. \"Just use the model with the larger context\" is a non-answer.\n\nModel confidence and tone are not signals\n\nA confident-sounding answer is not a correct one. Self-assessed confidence is poorly calibrated, and on the hard cases the model is often most sure precisely when it is wrong. Never gate a decision on how certain the model claims to be. Verify with something external.\n\nAn independent instance beats self-review\n\nA model grading its own work is biased toward its own work. A fresh instance, with no memory of having produced the output, catches far more errors. If you want a real review step, spin up a separate reviewer, do not ask the author to check itself.\n\nLeast privilege for tools\n\nGive each agent role only the tools it needs, roughly four to five. This is not only a security point. More tools measurably degrade selection quality: the model gets worse at choosing when the menu is longer. Fewer, sharper tools beat a giant toolbox.\n\nStructure beats free text, everywhere\n\nStructured errors, structured outputs, structured handoffs between agents, all with explicit provenance. Free-text prose between components is where information quietly rots. When agent A hands to agent B, pass a schema, not a paragraph.\n\nDo not suppress errors, and do not panic\n\nHandle transient failures locally: retry the flaky network call, back off, move on. For everything else, escalate with context so the coordinator can decide. The two failure modes to avoid are swallowing the error silently and blowing up the whole run over something recoverable.\n\nMatch the API to your latency requirement\n\nThe Batch API costs about half as much but can take up to 24 hours. That is great for an overnight job and useless for anything a human is waiting on. Pick synchronous calls for human-blocking tasks and batch for the rest. Cost and latency are a trade you make on purpose.\n\nA retry fixes format, not missing data\n\nRetrying a call can correct a malformed structure. It cannot conjure information that was never in the source. If the data is not there, running it again just wastes tokens and time. Know which problem you have before you hit retry.\n\nThe four traps\n\nThese are the answers that feel smart in the moment and cost you later. Every one of them showed up as a tempting-but-wrong option.\n\n\"Just write in the prompt that it is mandatory.\" Shows up exactly when you need determinism, which is the one thing a prompt cannot give you. See rule 1.\n\n\"Add few-shot examples.\" Genuinely useful for ambiguous judgment calls. Useless for hard rules, where it creates the illusion of a guarantee without the guarantee.\n\n\"Build a classifier.\" A heavy solution reached for before anyone tested the cheap levers. Sometimes correct, usually premature. See rule 2.\n\n\"Make one tool that does everything.\" Merging tools feels like simplification. It makes selection worse, because now the model has to guess intent inside a single overloaded tool. See rule 8.\n\nIt collapses into three ideas\n\nStrip away the specifics and the twelve rules are really three:\n\nWhat must always work goes in code, not in a request. Determinism is an architecture decision, not a wording decision.\n\nMatch the complexity of the fix to the size of the problem. Cheap lever first, subsystem last.\n\nPass structure, not prose. Between components, schemas beat sentences.\n\nNone of this is exotic. It is the difference between an agent that demos well and one that is still running in three months. The exam rewards it because production rewards it.\n\nSzymon Paluch. I work with teams on agentic system strategy, taking Claude Code and agents from demo to production.", "url": "https://wpnews.pro/news/12-rules-for-building-ai-agents-that-survive-production", "canonical_source": "https://dev.to/szymonpaluch/12-rules-for-building-ai-agents-that-survive-production-4j9h", "published_at": "2026-07-17 12:30:14+00:00", "updated_at": "2026-07-17 13:01:54.543497+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "developer-tools", "large-language-models"], "entities": ["Claude Certified Architect", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/12-rules-for-building-ai-agents-that-survive-production", "markdown": "https://wpnews.pro/news/12-rules-for-building-ai-agents-that-survive-production.md", "text": "https://wpnews.pro/news/12-rules-for-building-ai-agents-that-survive-production.txt", "jsonld": "https://wpnews.pro/news/12-rules-for-building-ai-agents-that-survive-production.jsonld"}}