Run the Dark Code: Why Your Agent's Error Handling Has Never Executed - and How to Run It on Purpose

Your agent chains LLM calls, tool subprocesses, RAG lookups, and HTTP requests. You wrote error handling for every link in that chain: the retry after a 429, the cleanup when a tool gets killed, the fallback when your vector DB returns garbage. This talk's thesis is uncomfortably simple: you wrote that code, but you've never seen it run, and none of your current testing tools can run it.

Why? Because agent failures don't live at a single layer. An SSE response that cuts off mid-token lives in HTTP semantics. A tool subprocess that gets OOM-killed lives at the stdio layer. An ENOSPC lives at the syscall layer. Unit tests test the mock. Kubernetes-level chaos tools inject at the wrong layer entirely. Agent failures live at the SDK/API boundary, and that's exactly where fault injection has to happen.

I'll demonstrate this live with two mechanisms: an HTTPS proxy with a per-run ephemeral CA that synthesizes vendor-accurate 429s and stream truncations over a real TLS connection, so the SDK sees exactly what production would send it, and eBPF kprobes that rewrite syscall returns in the kernel, so the target gets a real ECONNRESET, not a simulated one. The tool is open source (faultkit), but this is a methods talk, not a tool pitch. In the live demo, we inject the llm-api-degraded scenario into a real agent test suite and find two red tests that didn't exist yesterday: two production incidents that won't exist tomorrow.

Bonus lesson: a resilience test that passes green without firing a fault is more dangerous than one that fails red. That's the story of exit code 3.

One memorable takeaway:

"Your error paths are code too. Don't let production be the first place they run! Run them on purpose, today."