The Bug That Made My Pentesting Agent Give Up

the fix is right, but there's a layer under it worth naming: the problem isn't just the scope of the cache key — it's that all failure types ended up in the same "blacklisted" bucket.

a permission-denied on a target is probably valid to carry forward (the tool genuinely can't run there). a timeout is likely transient. a missing dependency is global. three different failure types, three different valid scopes.

engagement-scoped keys solve the worst case, but failure-type classification is what determines which scope actually applies. your simplified note at the bottom already points at this — it's the real extension of what you built.

Good writeup. The engagement-scoped cache pattern you landed on is the right fix, and it mirrors something that shows up across agent systems more broadly: every piece of cached state needs an explicit scope boundary that matches its validity domain. The same trap appears in idempotency keys on tool results. If a tool call returns a transient error and the result gets cached without a request-scoped idempotency key, the next call against a different target inherits the stale negative result. We started threading request IDs through the entire execution chain for the same reason you added engagement_id. The silent-failure property you mention is the dangerous part. A cache that quietly accumulates false negatives is harder to detect than a crash.