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).
Quick update on the BFSI vertical because the numbers came in better than expected.
Deployed across 7 regional banks and 3 insurance companies in the past quarter. Common pattern: KYC automation, AML monitoring, customer support tier-1.
We built a customer support agent for a logistics company. Worked beautifully in English testing. Shipped to production across SEA, where customers write in English, Vietnamese, Thai, and Bahasa Indonesia, often mixed in one message.
