You wrote a tool with a clear docstring: "Maximum 10 guests per booking." Your agent calls it with 15 guests and gets back "SUCCESS." The rule was ignored because prompts and docstrings are suggestions. The LLM processes them as context, not constraints. This is the same problem web developers solved decades ago: never trust user input, validate on the server. For AI agents, the equivalent is never trust the LLM's judgment on business rules, validate at the tool layer. I'll build a guardrail system live using two components. First, rules defined as Python dataclasses: typed, testable, versionable. Each rule specifies which tool it applies to, what parameter to check, and what threshold to enforce. Second, a hook that intercepts every tool call before execution, checks it against the rules, and cancels violations with a clear message the LLM cannot argue with. The demo runs the same three invalid requests through two versions of the same agent. The prompt-only version allows all three violations. The hook-based version blocks all three and tells the LLM exactly why. You'll walk away with: • A hook-based validation pattern that works with any agent framework (about 30 lines of Python) • Rules as dataclasses you can test, version, and deploy independently from the agent • A decision framework for when you need hooks vs when prompts are enough • Understanding of the specific bypass mechanisms LLMs use against prompt-based rules • Open-source code you can adapt to payment validation, compliance checks, rate limiting, or any domain Most guardrail talks focus on content safety: toxicity, PII, prompt injection. This talk is about business logic. The rules your product must never break. The kind of violations that cost money, lose customers, and create legal liability.

Outline: • The Prompt Engineering Failure • Neurosymbolic Architecture • Live Implementation • Production Patterns • Advanced Applications