Skip to content
← Writing

If it only lives in chat, it does not exist

5 min read Product building
If it only lives in chat, it does not exist

You’re looking for the evaluation. You know it happened — someone spent real time comparing three approaches, weighing tradeoffs, and arriving at a recommendation. The work got done. You were probably in the room for part of it.

But now you need the result, and it’s not on the project page. It’s not in the decision log. It’s not in the doc that’s supposed to hold current truth for this workstream.

It’s in a chat thread from nine days ago, buried under forty messages about a different topic.

So you do the thing everyone does. You scroll. You search keywords. You find fragments — a paragraph here, a follow-up clarification there, a “yeah let’s go with option B” that might have been the final call or might have been a provisional take before someone raised a concern you can’t find. Twenty minutes later you’ve reconstructed something that feels close enough. Maybe it is. Maybe it isn’t. You’ll find out when someone else reconstructs a different version from the same thread.

This is the part where most people shrug and say “we should document things better.” And then nothing changes, because “document things better” isn’t a practice. It’s a wish.

The thing chat does too well

Chat is genuinely useful as a working surface. Two people hashing something out in a thread can reach a better conclusion faster than a meeting, a shared doc, or an async review cycle. I’m not arguing against chat. I use it constantly — with people and with AI.

The problem isn’t that chat is bad at producing good work. It’s too good at producing work that feels complete. The conversation resolves. The decision lands. Everyone walks away with the sense that the thing has been handled.

But “handled” and “captured” aren’t the same state. The conclusion lives in someone’s memory and in a scrollback buffer that nobody will ever intentionally revisit. The system — whatever shared surface your team actually operates from — still doesn’t know what was decided.

Information decay funnel from just-decided to weeks later

This is where AI makes things worse

I want to be precise about this, because the instinct is to blame AI for creating the problem. It doesn’t. Teams have been losing decisions in Slack threads since Slack existed, and in email chains before that, and in hallway conversations before that.

What AI does is increase the volume and polish of ephemeral output.

A conversation with an AI collaborator can produce a thorough evaluation, a well-structured recommendation, a complete draft — all inside the chat window. The output looks like a finished artifact. It reads like something you’d put in a doc. The quality of the temporary output makes it even easier to mistake the conversation for the record.

I’ve caught myself doing this. A working session produces a clear result — an evaluation, a spec, a framework — and because the result is sitting right there, fully formed, the instinct is to move on to the next thing. The work feels done. Except it’s done in a place that resets, expires, or gets buried. The project page still shows whatever was true before the session started.

The more capable the model, the more dangerous this gets. Better output, higher polish, wider gap between “this feels finished” and “this is actually captured.”

What has to survive

Not everything in a conversation deserves a permanent home. Most of it is scaffolding — exploratory thinking, dead ends, the back-and-forth that got you to the conclusion. Scaffolding is supposed to be temporary.

But some outputs aren’t scaffolding. They’re load-bearing.

Decisions are load-bearing. If someone made a call — we’re going with approach B, we’re dropping this feature, we’re targeting this market — that decision needs to exist somewhere the next person can find it without archaeology.

Evaluations are load-bearing. If you compared options and reached a conclusion, the conclusion and the reasoning should live where the project lives. Not because documentation is virtuous, but because without it, someone will redo the evaluation from scratch. I’ve watched this happen three times on the same question in the same quarter.

Specs are load-bearing. Current truth is load-bearing. The artifact that says “here is what we’re building and why” can’t live exclusively in the conversation that produced it.

The filter is simple: if the next collaborator — human or AI — would need this to do their job, and they can’t find it where they’d naturally look, the work isn’t finished.

Write-back is completion, not cleanup

Here’s where teams consistently get this wrong. They treat moving a result from chat to its permanent home as an administrative task. Cleanup. Something you do when you have time, which means you don’t do it.

It’s not cleanup. It’s the last step of the actual work.

A decision that only lives in chat is a decision that hasn’t been made yet — not in any way the system can act on. An evaluation that only lives in a thread is an evaluation that will be repeated. A spec that only lives in a conversation is a spec that will drift into three different interpretations by next week.

The write-back is what converts a useful conversation into organizational knowledge. Without it, the conversation helped the people who were there and no one else. For teams that work across time zones, rotate collaborators, or use AI agents that start fresh each session, “the people who were there” is an increasingly small fraction of who needs to know.

The question that ends the session

I don’t think the answer is “document everything.” That produces its own kind of theater — pages of meeting notes nobody reads, decision logs maintained for compliance rather than utility. Documentation for its own sake is almost as useless as no documentation.

The answer is one question, asked consistently: what from this session needs to survive, and where does it live now?

If the answer is still “in the chat,” you’re not done. The conversation was productive. The work isn’t finished. Move the load-bearing pieces to wherever your team expects to find them, and then you’re done.

Doesn’t matter if it takes two minutes. Those two minutes are the difference between a team that builds on prior work and a team that keeps rediscovering its own conclusions.

Get in Touch

I'm always open to conversations about design, product, and leadership.