We had an agent that recursively called itself based on input length. One weekend, an edge case triggered the recursion. By Monday, we'd burned through a month's token budget.
Something I keep noticing in agent-building communities: we obsess over testing the code (does the tool call work, does the API respond) but we're much looser about testing the judgment (does the agent make the right call when the input is ambiguous, adversarial, or just weird).
That gap matters more for agents than for normal software. A buggy app usually fails loudly: a crash, an error message. A poorly-designed agent fails quietly. It picks the wrong tool, hallucinates a policy, or confidently takes an action nobody wanted, and everything still looks fine in the logs.
Lately I've been trying to close that gap by using a second AI as an adversarial reviewer before anything goes near production - feeding it the agent's instructions and asking it to generate the messiest, most ambiguous, or borderline-malicious inputs it can think of, then checking how the agent would actually respond to each one.
The catch: if the AI reviewer picks up on how confident I sound about the design, it tends to go easy on me - same sycophancy problem as with product ideas, just with higher stakes here, since these agents often touch real customer data, permissions, or compliance-sensitive workflows (GDPR/HIPAA territory for a lot of us building enterprise agents).
