I spent last evening reading a blog from the Oracle Developers team on agent memory, and one benchmark result has been stuck in my head since. They took an agent with the entire conversation in its prompt. Every single turn, verbatim, 80 turns deep. Nothing forgotten, nothing summarized. On paper, this agent should be unbeatable. It literally has all the information. Then they ran it against an agent using their new memory package, which keeps only a small retrieved context card per turn. Around 1,300 tokens instead of 13,900. The memory agent won 48 turns. The full transcript agent won 13. The one with less information won almost 4x more often. I keep coming back to this because it breaks the assumption most of us are building on: that if the context window is big enough, memory is solved. It isn't. A sprawling transcript doesn't help the model, it drowns it. Attention spread across noise is worse than a short, focused view of what actually matters. The mental model they use for this clicked for me too. Agent memory isn't one thing. It's four different access patterns. What am I doing right now (working). What do I know about this user (semantic). What happened last time (episodic). How am I supposed to behave (procedural). Same underlying state, four different questions being asked of it. Which is why bolting a vector store onto a chat history table never quite works. You're serving four access patterns with one lookup. They also scored 93.8% on LongMemEval and held token cost flat while the baseline grew linearly, but honestly the 48 vs 13 result is the part I'd want every agent builder to sit with. Full writeup is here, benchmarks and architecture included: fandf.co/4xNYQei Thanks to @OracleDevs for partnering on this. Over to you. If a smaller, curated context beats a complete one, is "just wait for bigger context windows" actually a strategy, or a trap?