
Have you ever told your AI agent something important, only to realize a few conversations later that...
Have you ever told your AI agent something important, only to realize a few conversations later that it had forgotten everything? So you tell it again. And again.
A few months ago, I was speaking with a Director at a hedge fund who described a problem that stuck with me.
“Sparsh, the problem isn’t that we can’t train an agent. The problem is that as soon as someone else on my team starts using it, everything resets to zero.”
Think about how humans work. A senior analyst doesn’t start from scratch every morning. Over years of working through difficult cases, making mistakes, and observing outcomes, they develop something much more valuable than information: judgment.
They know which signals matter, which approaches tend to fail, and when an apparently reasonable decision deserves a second look. Our agents, however, can execute thousands of tasks and still make the same mistake tomorrow. And that raises a fundamental question:
Are we building agents that remember more, or agents that actually get better?
If you’ve been working in agentic AI recently, you’ve probably heard the same answer everywhere: memory.
Give agents longer context windows. Connect vector databases. Store conversations, tool calls, execution histories, and previous decisions. The assumption seems reasonable. If the model has access to everything that happened before, shouldn’t it make better decisions?
We initially believed so too. So we started feeding our agents more context: historical cases, previous executions, retrieved documents, and accumulated knowledge. Then we ran independent evaluations.
More context wasn’t consistently producing better performance. In some configurations, performance actually deteriorated.
We tried manually refining the context, restructuring instructions, and carefully selecting what the agent could see. Some configurations that looked more complete performed worse than simpler ones. And as we started removing information, we discovered something counterintuitive:
Sometimes, the best way to make an agent smarter is to give it less to remember.
This led us to an important distinction:
Facts and learning are fundamentally different.
Facts describe the world. A customer’s contract expires next month. An API requires authentication. A particular repository contains the billing service. These belong in databases, knowledge graphs, or document stores.
Learnings, however, describe how to act. For example:
These are not merely facts. These are refined judgments derived from experience. Experience requires understanding what action was taken, its outcome, why it occurred, and whether the lesson should influence future decisions. An execution log tells you what an agent did.
An experiential memory tells it what and why to do differently next time.
A useful memory system needs a complete lifecycle:
Capture → Evaluate → Consolidate → Retrieve → Update

A strategy that worked three months ago may become dangerous after an API or policy changes.
Even accurate memories can become counterproductive if surfaced at the wrong time. That’s why we started thinking about progressive disclosure: giving an agent the minimum relevant information for its current decision, revealing additional context only when needed.
The objective isn’t maximum recall. It’s better decision-making with the right information at the right moment. Progressive disclosure works like wonders in these scenarios.
The industry is rapidly converging on memory as an essential component of agentic systems. I agree. But memory by itself isn’t the destination. The real challenge is building systems where experience compounds.
An agent executes a task, observes an outcome, extracts a lesson, validates it, and applies that lesson to a future decision. If the lesson proves useful, it becomes stronger. If it becomes outdated or harmful, the system revises or removes it.
Over time, the agent doesn’t just accumulate more information. It develops more reliable decision-making patterns. That’s the direction we’ve been building toward through Loop Engineering: treating evaluation, memory, and feedback as a continuous system rather than isolated components.
Because the goal isn’t to build an agent that remembers every mistake it has ever made.
The goal is to build an agent that doesn’t need to make the same mistake twice. A system where experience compounds.
discussTL;DR Welcome back to Dev Opportunity Radar! This is a weekly series where I share opportunities,...
devchallengeWe are so excited to announce the winners of the Hacktoberfest Open-Source AI Challenge: Touch...
googlecloudHow I designed, connected, scaled, governed, evaluated, and QLoRA fine-tuned an enterprise SecOps & FinOps agent on Google Cloud.
gemmaYes. Speculative decoding with Google's 59 MB QAT multi-token prediction (MTP) drafters speeds up Gemma 4 E4B 1.72x and E2B 1.40x on an 8 GB RTX 3050, and 1.49x and 1.18x on a 4 GB laptop GTX 1650 Ti, served by llama.cpp one request at a time, with unchanged GSM8K and BFCL scores.
nvidiaThe same Tesla T4 on the same Google Cloud VM decoded Gemma 4 E2B at 115 tokens/s at 45 °C and 107 at 77 °C. The card sits at its 70 W limit, a hotter chip draws more power at the same clock, so the clock drops. No thermal throttle fires, and no spec sheet mentions it.
oracleHow I pair-programmed with Google Antigravity powered by Gemini 4 Argon to build a zero-dependency Go TUI and OpenTelemetry/Prometheus observability stack for Oracle Databases and Linux SAN storage.
Workflows from the Neura Market marketplace related to this DeepSeek resource