Your Agents Aren't in 50 First Dates. They're in Memento.

AI coding agents lose context between sessions because nothing persists the decisions, constraints, and conventions that made the codebase what it is. Each session, the agent rebuilds its understanding from whatever it can scrape together — code, logs, tickets, Slack — and that picture is always partial. The fix isn’t a better briefing every morning. It’s a context engine that holds the reasoning behind your system in a durable form, so the agent reads it instead of guessing at it.

An optimist’s take: 50 First Dates#

Steve Yegge described AI agents using “50 First Dates” as the analogy - every session starts fresh, so you have to re-establish context just to get useful work done.

However, in that example, it assumes that “the system” around “the agent” can reliably reconstruct what matters.

In 50 First Dates, Drew Barrymore’s character loses her memory every night. Adam Sandler’s character responds by building a system around that constraint, a daily video, a carefully controlled environment, people who understand the situation and reinforce the same story. Each morning starts from zero, but the reset is managed. The context is curated and consistent enough that she can be brought back up to speed.

That’s the optimistic version of how agents work. They forget, but we can brief them back into usefulness.

A realist’s take: Memento#

What I’ve seen in practice looks much closer to the movie Memento.

Guy Pearce’s character can’t form new memories, so he leaves himself clues, Polaroids, notes, tattoos. Unfortunately, those clues are incomplete and sometimes misleading, and he has no reliable way to tell what he can trust. He’s constantly reconstructing reality from fragments, and getting it wrong in ways that compound over time.

That’s much closer to how agents behave inside real systems.

They aren’t waking up to a clean, well-structured briefing. They’re pulling from code, logs, tickets, Slack threads, each with partial context and missing rationale, and trying to infer how things are supposed to work. The failure mode isn’t just forgetting, it’s confidently stitching together the wrong picture.

To put it plainly: an agent doesn’t remember between sessions because nothing durable holds its memory. The clues it leaves itself — comments, file structure, a half-relevant ticket — are the Polaroids. They survive, but the reasoning that produced them doesn’t. So the agent isn’t recalling your system. It’s re-deriving it, every time, from evidence that was never meant to explain anything.

Better prompting won’t fix it#

That difference matters because it changes how you think about the solution.

If you believe the “50 First Dates” version, you focus on improving the briefing, better prompts, more integrations, more data access. And that does help, to a point.

But if the reality is closer to “Memento,” the problem isn’t that the agent forgot. It’s that the underlying context it’s trying to reconstruct was never assembled in a coherent way to begin with. More data just means more fragments.

You can’t prompt your way out of missing reasoning. Better prompts make the agent better at reading what’s there, but the why behind your system isn’t there to read. Pointing the agent at more sources just hands it more Polaroids. The shift is from helping the agent reconstruct context to making sure that context exists in a form that can actually guide it.

Not memory, not retrieval#

That’s where a context engine fits. Not as memory, and not just as retrieval, but as a way to surface the decisions, constraints, and conventions that already exist across an organization so the agent isn’t left guessing.

A context engine surfaces the decisions, constraints, and conventions already scattered across your code, PRs, docs, and conversations, and delivers them as decision-grade context — the reasoning the agent needs to act correctly, assembled before it starts work. It’s not the agent’s memory and it’s not a search box. It’s the difference between handing the agent a stack of Polaroids and handing it a system that already knows why the code looks the way it does.

Once you see it that way, the goal isn’t to make agents better at starting from zero. It’s to stop putting them in that position in the first place.

A few questions that come up#

Why don’t AI coding agents remember context between sessions?

Nothing durable holds the memory. Each session, the agent rebuilds its understanding from whatever artifacts it can scrape together — code, logs, tickets, Slack — and those artifacts carry the result of past decisions but not the reasoning behind them. So the agent isn’t recalling your system; it’s re-deriving it from incomplete clues every time.

Why does my agent keep making the same mistakes?

Because the reason the mistake is a mistake was never written down where the agent can read it. The refactor rationale, the rejected approach, the rate-limit rule — they live in incidents, reverted PRs, and people’s heads, not in the code. The agent sees the artifact, not the decision, so it confidently repeats what the team already learned to avoid.

Will better prompts or more data fix it?

Only up to a point. Better prompts help the agent read what’s there, but the missing piece is reasoning that isn’t there to read. Adding more sources just gives it more fragments to stitch together. You can’t prompt your way out of context that was never assembled coherently in the first place.

What is a context engine?

A context engine surfaces the decisions, constraints, and conventions that already exist across your organization and delivers them as decision-grade context — assembled before the agent starts work. It isn’t the agent’s memory and it isn’t retrieval. It’s the layer that makes sure the why behind your system exists in a form the agent can actually use.