I asked how you all handle agent memory. Here's the pattern in the replies, and the one thing nobody's actually solved.

Posted a question here about why agents remember what sounds related instead of what actually worked. Got a bunch of genuinely thoughtful replies, so here's what I took away, because the pattern across them turned out to be more interesting than my original question. Almost nobody defended pure vector search. The recurring frustration was the same one a few people put really well: embeddings are good at "what looks similar," but what an agent actually needs is "what worked" and "what failed," and those are different retrieval problems. Someone called the missing piece "negative memory," the agent never preserves "we tried this route and it died because X," so it cheerfully walks back into the same wall. What surprised me was how many people had already built their own patch for it, and how different the patches were: Someone runs working memory entirely out of plain files, the agent decides what to write, old stuff rolls off to a vector DB, no fancy platform. Their line stuck with me: "if you have to ask, the system is broken." Someone else splits memory into layers, stable trusted facts vs citable receipts, and won't let the agent act on anything it can't point to a source for. "I found a likely match" vs "I know." A third had the agent write its own plain english post mortem after every task ("tried X, failed because Y, next time Z") and semantic searches those before new work. Their honest downside: after 30 or 40 of them the file gets noisy, so they added a summarization pass. Another proposed three ledgers (facts, run state, decisions and failures) and routing by intent before semantic search, so "did we try this already" hits the failure log first. Here's the thing that jumped out once I lined them all up. Every one of these solves what to write down. None of them really solves what to keep. The most precise version of this came from someone running it in production. Their take: detecting that a failure happened is mostly doable automatically, you can catch tool errors, failing tests, timeouts, reverted patches, even tasks that end without verification (treating missing verification as its own failure signal, which I thought was sharp, otherwise you only ever log the loud crashes). But they explicitly would not trust automation to infer the actual lesson. What the failure meant, and whether it should stick, still needs a human or a forced explicit write. That split is the whole thing, I think. Detection is tractable. Consolidation is not. How does the system decide what is actually true vs just frequently retrieved, and what survives once it is written? Everyone is using a heuristic for that ("prove it twice," recency, manual rules, a summarization pass), and every heuristic breaks at a predictable edge. Building in this space, which is why I asked. For people running agents in production: where does your system stop trusting automation and start needing a human in the loop? Is that line moving for anyone, or is it stuck where it is?