Ten Principles for Production AI Agents, Missing the Eleventh: Know Your Scope

Rohit (@rohit4verse) published a ten-principle framework for building production-grade AI agents. It's long, detailed, and covers real ground — threat modelling, typed contracts, sandboxed execution, observability, evaluation pipelines. It also opens with an unsourced statistic and never once asks the question that matters most before you adopt any of its advice.

The thing it gets right that others don't. Principle 5 — knowledge grounding as a governed tool — makes an architectural distinction I haven't seen stated this clearly elsewhere: retrieval capabilities and execution capabilities must be separately authorised. Reading a knowledge base should never implicitly grant write access or API permissions. That's a specific, actionable design constraint, and it's the kind of thing that prevents the exact class of confused-deputy failures the piece warns about. Most agent tutorials treat RAG as a monolithic capability. This correctly treats it as a permission boundary.

The thing it doesn't earn. The piece opens by claiming "over 40% of agentic AI projects fail" — no source, no definition of failure, no timeframe. It then sprinkles numbers throughout: 73% of deployments have prompt injection vulnerabilities (attributed vaguely to "OWASP"), five documents can manipulate responses "90 percent of the time," LLM judges align with humans "up to 85 percent." For an article whose entire thesis is engineering rigour over demo culture, the evidentiary standard is demo-grade. The OWASP figure appears to reference their LLM Top 10 list, which doesn't make that specific claim in that form. The "five documents" stat likely traces to a research paper on RAG poisoning, but without a citation you can't verify the conditions under which it holds — or whether those conditions resemble your deployment.

This matters because the piece presents all ten principles as equally urgent. Hardware security modules, mutual TLS, field-level encryption, workload identity federation — these appear alongside "validate your tool inputs" as though they belong at the same priority level. They don't. A team building an internal agent that summarises meeting notes needs typed contracts and error handling. It does not need a hardware security module. The piece never makes this distinction, which means a reader either over-engineers a simple tool or dismisses the whole framework as enterprise theatre.

The self-promotional tweet embedded mid-article — "how to build an agent that never forgets" — dropped without integration into the surrounding argument, confirms the suspicion. This is a content marketing piece structured as an engineering guide. The engineering content is real, but the packaging optimises for shares over utility.

Read principle 5 and principle 8 (reliability mechanics). Skip the rest until you've actually shipped something that needs it.