Your AI coding agent forgets every decision overnight. Here's the fix.

On a Monday, your agent does the right thing. You tell it the team settled the auth rename weeks ago: POST /login became /session, the old route is dead, don't call it. The agent nods, in its way, and builds against /session. Clean PR, merged, done.

On Tuesday, a different session starts. Maybe a different engineer, maybe you with a fresh context window. The agent reads the code, finds a stale client still importing the old path, and helpfully "fixes" the inconsistency by calling /login again. Nobody is in the room to say no. The decision that took your team a meeting, a Slack thread, and a small argument to settle gets unmade in eleven seconds by a tool that was never told it existed.

This is not a model quality problem. The agent did exactly what a competent person would do with no memory of the meeting. That is the whole issue: it has no memory of the meeting.

The blank desk every morning

An AI coding agent's memory is its context window, and the context window ends with the session. Whatever was decided in yesterday's conversation, last week's pairing session, or the Slack thread where the pricing rule changed simply does not exist for today's run. Agent memory, as most tools implement it, is per-person and per-session: useful for one developer's continuity, silent about everyone else's.

Humans route around this constantly and invisibly. You overhear things in standup. You absorb conventions from code review. You know not to touch the billing module on a Friday because of an incident nobody wrote down. An agent attends no standup and reads no room. As we've written before, the hallway is load-bearing, and the agent is never in it. It only knows what's in front of it: the code, plus whatever context someone remembered to paste in.

Scale that to a team. Five engineers, each pointing agents at one codebase, each agent blank every morning. One agent renames a route; another keeps calling the old one. A third re-opens a database choice the team settled in March, because nothing in its window says March happened. The engineers spend their days as human memory sticks, shuttling context between sessions. That is the part nobody budgeted for.

Re-deciding is the expensive part

The costs of this are real, and they are not limited to developers.

The direct cost is rework: code written against yesterday's forgotten constraint has to be found, reverted, and written again. The subtler cost is decision drift: the product slowly stops matching what the team agreed, one well-meaning session at a time, and nobody can say when it happened. When the pricing logic changes shape, or a cut feature quietly comes back, that's not an engineering nuisance. It's a product problem that lands on a lead's desk and a PM's roadmap.

There's a measurement angle worth sitting with. In METR's 2025 study of experienced open-source developers, developers using AI tools took 19% longer to complete their tasks, even though they believed they were faster. The study has its own scope and caveats, but the direction should worry anyone managing a team: agent time saved on typing can be handed back, with interest, in review, correction, and rework. Context is where a lot of that give-back happens.

The demand for a fix is showing up in public. A feature request for shared team memory in Claude Code, filed in March 2026, calls individual-only memory "the single biggest efficiency bottleneck for teams adopting Claude Code seriously." The scenarios in that thread are the ones every team recognizes: sprint handoffs where context dies at the boundary, domain experts re-explaining their subsystem to a colleague's agent, investigations that start from zero because the findings are trapped in someone else's session.

The usual fixes don't survive a sprint

Teams do try to solve this, and the attempts share a failure shape.

The first attempt is the rules file: AGENTS.md, cursor rules, a copilot-instructions.md. These help for stable conventions, and we've written about what they can and can't carry. They can't hold the why behind each call, they drift stale the moment the codebase moves, and updating them is a chore everyone skips at exactly the moment it matters, which is when the decision changes. A rules file is a snapshot. Decisions are a stream.

The second attempt is the wiki or the decision log, and the practice is genuinely valuable; we keep a field guide to doing it well. But a log that agents don't read before acting is documentation for humans, and the humans are not the ones writing most of the new code anymore. The read side is where these systems quietly fail.

The third attempt is paste-it-in-yourself: carry the context into each session by hand. This works for one disciplined person and collapses at team scale, because it makes every engineer the integration layer between the team's memory and every agent session. That's a full-time job nobody hired for.

The common thread: each fix treats memory as a place to write things down. The actual requirement is a system that writes things down and puts them back in front of the agent at the moment they're about to matter.

What real decision memory looks like

Decision memory is a persistent record of the calls a team makes: the verdict, the reasoning, and the rejected alternatives, kept as shared context that every agent gets briefed on before it acts. Four properties separate it from a wiki with better intentions.

It's captured at the moment of the call. When a decision lands, in a PR discussion, a review comment, or a planning conversation, it gets recorded once, with its why. Not migrated later, not reconstructed in a retro. A decision nobody captures at the time is a decision the next six sessions will re-litigate.

It's ranked by blast radius. Teams make hundreds of small calls and a few big ones, and they don't deserve equal airtime in an agent's context window. The auth rename matters to almost everything; the chart-library choice matters to one dashboard. Memory that can't tell the difference either floods the agent with noise or, worse, buries the one decision that was about to be broken.

It briefs before code gets written. The record only earns its keep on the read side: before an agent touches the billing module, it should already know the pricing rule, the constraint behind it, and the alternative the team rejected. Briefing is what turns a log into memory.

It remembers what replaced what. When a decision is reversed, the old entry stays, marked as replaced by the new one, with the reason. A record you can silently rewrite is a record you can't trust, and an agent that can't see the history will happily resurrect the thing you killed.

Notice that none of this is developer-only. The decisions that hurt most when forgotten are often product decisions: why pricing changed, why a feature was cut, what was promised to a customer. The record serves everyone who builds with agents, and keeping the team aligned on it is a company problem, not an IDE setting.

Where Lockstep fits

This is the problem we built Lockstep to solve. Lockstep keeps your team's decisions as a persistent record: captured when they're made, approved by their owner in one click, ranked by what they affect, and briefed to any MCP-compatible agent through get_product_context before it writes code. Claude Code, Cursor, whatever your team runs next quarter. It's Apache-2.0 and self-hostable, and the point is not another place to write things down. It's that the blank desk every morning stops being blank.

The agent will keep waking up with nothing. That's how the tools work, and it's not changing soon. What can change is what's on the desk when it does.