Your team relearns the same lesson every eighteen months

There's a specific kind of meeting I've now sat in enough times to recognise from the first two minutes.

A metric has moved. A team is assembling hypotheses. Someone senior says, with genuine uncertainty: "I feel like we looked at this before."

They did. Roughly eighteen months ago, a different combination of people diagnosed it properly, fixed it, and measured the result. Then two of them left, one moved teams, the Slack channel was archived in a workspace cleanup, and the finding survives only as an intuition in one person's head that they can't quite substantiate.

So the work happens again. Same investigation, same three weeks, same conclusion — arrived at with less confidence than the first time, because now nobody's sure whether they're remembering a real finding or a plausible story.

Why the standard answers don't work

The usual response is documentation. It fails predictably, for reasons worth naming precisely.

Documentation is written at the moment of lowest motivation. The problem is solved. The team is relieved and moving on. Writing it up is the least urgent thing on anyone's list, and it competes with the next fire.

It's stored where nobody will look. Notion pages, Google Docs, a Confluence space someone set up in 2023. Retrieval requires knowing the artifact exists, which requires remembering the thing you're trying to look up.

It rots without notice. A finding true in 2024 may be false in 2026 — the product changed, the market moved, the payment provider changed their retry defaults. Documentation has no expiry and no revalidation, so old findings and current ones look identical.

It records the narrative, not the measurement. This is the one that matters most. Write-ups say "we ran a win-back campaign and recovered $180K." They almost never say "campaign lift measured against a 10% holdout was 4.2 points; attribution reported 11 points."

The second version is the one worth keeping. The first is a story about a number that may not have been real.

Causal finding that last point is structural rather than observational. If what you store is an attributed figure, you have stored a model output, and re-reading it later tells you what your model said, not what happened. Only a holdout-measured result carries information about the world.

What memory has to store

Four things, and dropping any one of them makes the rest much less useful.

The problem, scoped. Not "churn was up." The specific cohort, the specific metric, the specific window.

The evidence, with its weight. Whether the conclusion was a causal finding with a dated event and comparison group, or a strong association, or a hypothesis someone acted on because the downside was small. Eighteen months later this is the difference between "we know this" and "we believed this."

The decision and who made it. Including the objections that were raised and how they were answered. The objection that turned out to be right is the most valuable thing in the record.

The measured outcome — holdout, not attribution. What actually moved, relative to a control group. If the intervention was unmeasurable, that's what gets stored, honestly.

Revalidation is the part everyone skips

A memory system that only accumulates is a system that becomes wrong slowly and confidently.

We re-check validated learnings quarterly against current data. A finding that held in Q1 may not hold in Q4 — your customer mix shifted, your payment provider changed their defaults, your product changed the flow the finding was about.

Three possible outcomes, and all three are stored:

• Still holds. Confidence increases. It's been true across multiple periods.
• No longer holds. It's marked superseded, with the date and what changed. Not deleted — a finding that used to be true and stopped is itself a finding.
• No longer testable. The conditions don't exist any more, or the data required is unavailable. Marked as such rather than quietly assumed.

Deleting superseded findings is a mistake. When someone asks "did we try this," the answer "yes, in 2025, it worked; we retested in 2026 and it no longer does, because we changed the billing date" is far more useful than silence — and far more useful than the stale finding presented as current.

Where memory is used

The reason this isn't just an archive is that it's an input.

When an agent investigates a signal, it reads memory first. So the Room opens with prior context already in it:

A similar second-order decay was diagnosed in March 2025 and traced to a checkout change. Fix was a revert; measured lift against holdout was 8.1 points over 60 days. Revalidated October 2026: still holds. Note an objection raised at the time about seasonal confounding, answered by comparing against the prior year's same window.

That paragraph collapses three weeks of rediscovery into something a team reads before their first meeting. It doesn't tell them the answer — the current situation may be different — but it tells them what's already known and what was already checked.

Strong association teams with more accumulated memory reach a diagnosis faster on recurring problem classes. We're labelling this strong association rather than causal because teams accumulate memory by using the product longer, and longer-tenured teams differ in other ways we can't fully control for.

What it costs

Rooms have to close properly. Memory is built from resolved Rooms, so a team that leaves Rooms drifting builds nothing. That's a discipline cost, and it's real.

Revalidation consumes compute and occasionally attention. Some revalidations are ambiguous and need a human to decide whether a finding still holds.

Memory can anchor you. This is the risk I take most seriously. A team that reads "we tried this in 2025 and it didn't work" may not try a variant that would work now under different conditions. We mitigate it by storing the conditions alongside the finding, so the reader can judge whether they still apply — but I don't think mitigation is the same as elimination, and a sufficiently deferential team could absolutely get stuck.

It's slow to become valuable. Month one, memory is empty. Month eighteen, it's a moat. That's a hard thing to demo and an easy thing for a competitor to promise.

When you don't need this

Honestly: if your team is small, stable, and working on a narrow problem set, the memory is in people's heads and it works fine. Three people who've been together four years have excellent recall of what they've tried.

It becomes necessary at the point where the people who solved a problem are no longer the people who encounter it next. That's a function of headcount, turnover, and how many distinct problem types your business has — not of company size directly.

The tell is the meeting I opened with. If someone in your organization has said "I feel like we looked at this before" in the last quarter, you're past the point.

What we can't tell you yet

We can't tell you how much memory is enough to matter. We suspect there's a threshold below which it's noise and above which it changes behaviour, and we don't know where it sits — it probably depends on how repetitive your problem set is.

We also can't fully solve the anchoring risk. Storing conditions alongside findings helps a reader judge relevance, but a team inclined to defer to the record will defer to it. If we learn that memory is making teams less exploratory rather than more efficient, that's a serious problem with the design and I'd want to hear about it early.