Coada / writing

Companies Don't Remember in Conversations

Post 2 of The Currency Problem. The discovery that changed what I was building.

In the first post, I described the failure that sent me down this path: an agent confidently re-arguing a decision my team had already reversed. It recalled plenty. What it couldn't tell was what's still true.

Knowing the problem and knowing the fix are different things. This post is about the wrong turns I took first, and the observation that finally reframed the whole build.

The fixes that don't fix it

Everyone who meets this problem reaches for the same three fixes. I reached for all of them.

Give the agent everything. If it can see the whole history, surely it can work out what's current. Except now it holds the original decision and the reversal, side by side, both looking equally authoritative — and it has to notice the conflict and guess the winner. On every task. Forever. Sometimes it guesses right. You don't get to know when.

Give it the summary. Compress the history to get the gist. This one fails quietly. Summaries preserve conclusions and shed reasons — and the reasons are the part that matters. "We use this vendor" survives summarization. "We chose them over the cheaper option because of what happened during the outage in March" does not. Lose the why, and when conditions change, nothing can tell your agent whether the decision should change too.

Trust the newest thing. Prefer recent information — surely the latest word is the current truth? Except the most recent mention of a decision is often someone discussing the old one. A retro that quotes the abandoned approach. A doc explaining the new pattern by describing the deprecated one. Newest and current agree just often enough to be dangerous.

Three fixes, one shared assumption: that memory is a pile of things that were said, and the job is to sort the pile better. That assumption turned out to be the actual bug.

Watch how a company actually remembers.

The reframe didn't come from a paper. It came from noticing something I'd watched happen a hundred times and never really looked at.

A new engineer joins and asks the oldest question in software: "Why is it built this way?" Nobody answers by handing them meeting transcripts. Nobody says "read every Slack thread from Q1." Someone — usually the most senior person in the room — tells them the story of the decision: here's what we tried, here's what broke, here's what we picked and what we walked back, and here's why the walked-back thing keeps looking tempting to people who weren't there.

That's how companies remember, not in conversations — in decisions. The conversations are just the raw material; the institution keeps the verdicts. And the best organizations learned, usually the hard way, to write the verdicts down — decision records, postmortems — because the alternative is that the verdicts live in people, and people leave.

Then look at what we handed the agents: the transcripts: all raw material, no verdicts. Every pile-sorting fix I'd tried was an attempt to make an agent reconstruct the verdicts from the raw material — reconstruct, on the fly, under time pressure, the thing your organization spent months deciding.

That was the discovery, and I wrote it in a note to myself in May — preserved, fittingly, in the system it describes. Roughly: stop handing the agent what was said. Hand it what was decided, what that replaced, and what replaced it.

You can't bolt that on afterward. The connections between decisions — this reversed that, this exists because that failed — were never in the transcripts to begin with. They lived in the heads of the people in the room. If you want memory that knows what still holds, the life of a decision — made, challenged, revised, replaced — has to be recorded as it happens, the way the organization itself would remember it. A decision book, kept current. Not a longer transcript, searched harder.

The day it proved itself on me.

One story from June, because a thesis should have to survive its own author.

Weeks after making a significant product decision — removing something, deliberately — I hit a new problem where reversing that call looked attractive. The removed piece would have papered right over it. My in-the-moment reasoning was drifting toward "just put it back."

Old me would have put it back. Momentum plus a plausible reason is how most bad reversals happen — in people and in agents alike.

But by now I was testing this thesis on the thing I was building. So I asked it: why did we make this call? It gave me back the decision — the reasons, what we'd observed, what the removal was protecting. Every reason still held. Nothing about the new problem touched them. I solved the new problem another way, and the decision stood.

That's the whole thesis in one moment: the system didn't remember more than me. It remembered better than me — it knew the decision's standing when my own judgment was about to slip. Now give that slip machine speed and twenty agents, and you have the risk from Post 1. Give the save machine speed instead, and you have the reason I kept building.

What this changes

The discovery, compressed: what was said is a transcript. What still holds is a ledger. Transcripts only ever get longer; a ledger gets reconciled — and reconciliation, not recall, is what keeps agents from confidently rebuilding your past.

Next post: what all of this does to your budget — because the transcript model doesn't just fail on correctness, it fails on economics, and the token market is making that failure more expensive every quarter.


The product that came out of these six months is flmnt — a memory layer for AI agents built around decision currency: what's still true, not just what was said. It's in private beta now. Code BLOG30 gets you a free month.