Your agents are disposable workers. What they learn shouldn't be.

Almost every agent session starts from zero. You re-explain the codebase, the conventions, the decisions you already made last week. Ten minutes of onboarding before any real work happens.

The common fix is to micromanage it up front: cram the architecture into a `AGENT.md`, write a `.cursorrules` for edge cases, package procedures into rigid skills. Before long you are maintaining brittle rulebooks the agent re-reads every time, eating your context window. And the strange part is, you get better results by deleting most of it.

The mistake is treating the agent itself as the asset. Agents are meant to be ephemeral; their wisdom is not: the decision you made and why, the approach you tried, the gotcha that cost you a day. Controlling that with static files and skills suppresses the agent's reasoning. Recall does the opposite: instead of front-loading everything, it pulls the relevant history just in time and lets the agent's own intuition take over. And that history belongs on your own machine where the embeddings run locally, so semantic recall never leaves the box.

The most surprising thing I found building this is that recall isn't really about speed. It stops agents from redoing solved work and re-litigating settled decisions, so the compounding value shows up as judgment.

In this talk, you will learn when to hard-code context and when to recall it, the design choices that keep a recall layer from rotting into a junk drawer of stale facts, and what I learned using it across my own projects, including why the best agent on your team is the one you can delete tomorrow.