Ask HN: How are you testing AI agents before shipping to production?

We've been running reliability audits on AI agents before production deployment, and the failure patterns are consistent enough that I built a framework around them.

Some context on why this matters right now: Gartner predicted over 40% of AI agent projects will fail by 2027. In January 2026, a prompt injection in a customer support agent processed a $47,000 fraudulent refund. These aren't fringe cases anymore.

The 7 failure modes we see most often:

1. Hallucination under unexpected inputs — works perfectly in demos, invents data when the input is slightly off

2. Edge case collapse — null values, Unicode names (O'Brien, José, 北京), empty fields, concurrent requests

3. Prompt injection — if your agent processes external content, users can hijack its behavior through that content

4. Context limit surprises — agent works for 95% of conversations, then silently misbehaves when the context window fills. No error. Just wrong behavior.

5. Cascade failures — tool call #1 fails, agent keeps going, by the time a human sees the result 3 calls have compounded the error

6. Data integration drift — built against your schema in January, schema changed in February, still calling deprecated endpoints in March

7. Authorization confusion — multi-tenant system, cached context from User A bleeds into User B's session

We've built 50+ test cases across these categories. Most teams test #1 and #3. Almost no one systematically tests #4, #5, and #6 before shipping.

Happy to share the framework. Curious what failure modes you've hit that I haven't listed.

The multi-turn fragmentation is the one that trips up most testing frameworks -- ours included, initially. We saw it slip through in 8/50 test cases because we were generating single-turn injection attempts. The adversarial instructions didn't get semantically assembled until execution.

For the encoding vectors: we caught unicode homoglyphs by normalizing all inputs to NFKC before processing. Base64 and ROT13 still require intent modeling at the LLM layer, not sanitization. A proxy that doesn't decode 'this is base64' will pass it straight through.

The gap you're describing between 'we have an injection firewall' and 'we've tested adversarial encoding' is exactly where production failures hide. Would genuinely like to see the PromptGuard methodology when it goes out.

Cross-session memory drift is a great addition -- we've seen exactly this. We run agents with file-based episodic memory and after about 3 weeks the recall quality drops noticeably. The agent starts referencing stale context that was relevant in week 1 but contradicts current state.

Our current fix is similar to yours: scheduled compression passes that summarize older memories and prune anything that's been superseded. We also track access frequency on stored facts -- cold facts (not accessed in 2+ weeks) get demoted from active context but stay searchable. That alone cut our context pollution by roughly 40%.

The checkpoint gates for cascade failures are smart. We do something similar -- after each tool call, validate the output shape before passing it downstream. Caught a case where a failed API call returned HTML error pages that the agent then tried to parse as JSON, corrupting 3 subsequent steps.

Will check out the playbook. Thanks for sharing.

[dead]

This thread is an incredible resource for adversarial security testing, but I'd love to pull on the "Cascade failures" (#5) thread from the original post, because that's what actually takes down production systems most often.We spend so much time testing if the model will break, and almost no time testing if the workflow can recover when the model inevitably does break. If an agent is executing a 4-step sequence and fails on step 3, how do you test what happens next? Does it orphan the data from steps 1 and 2? Does it infinitely retry and duplicate records?The biggest gap in agent testing right now is that we test agents like they are stateless functions, when in reality they are long-running stateful processes. You can't just test the prompt; you have to test the system's idempotency. If you can't safely kill an agent mid-task and restart it without corrupting your database, the system isn't production-ready, regardless of how robust your prompt injection firewall is. Please do share the framework, curious where we miss the point - the surface si ever expanding post Openclaw.