Comments on the work, not messages in the chat

Someone asks in the chat why this customer gets different payment terms. The answer was given three weeks ago, in a channel carrying several other conversations that day.

It is technically still there — search will find it, if somebody remembers the word. Practically it is gone: nobody remembers the day, the word, or the question.

So it gets asked again, and answered again, slightly differently.

Chat is a river#

A messenger sorts messages by the only dimension it has: time. New on top, old below — that is the whole filing system.

Work is not sorted by time. A job runs for weeks, a customer for years, the overtime rule for as long as the company does. A conclusion drifts from its subject with every unrelated message posted after it.

Search does not close the gap. You have to know which words were used — people write "14 days", "the longer terms" and "that exception for them" about the same thing — and you have to know there is something to look for. Whoever inherits the job knows neither, so they ask.

Mentions and threads fix delivery, not the address#

Topic channels split one river into several narrower ones. The water still flows, and the narrower the channel, the sooner a second appears for the same subject.

Threads put a conversation in a capsule, which genuinely helps — but the capsule hangs off the day it was created, as findable a month later as anything else from that week.

Mentions say who should read, not what it is about, and stop working the day the tagged person leaves.

All three solve delivery: the right message in front of the right person at the right moment. None solves addressing — so that a year on, whoever opens the job sees the conclusion without knowing to look. A comment pinned to a record solves that second problem and nothing else. Not a better chat: a record at an address that does not move.

What reconstructing context costs#

Someone new picks up a job and sees its state: status, due date, amount, owner. Not one reason behind any of it.

Two roads, both paid. The first: they ask. A few minutes of waiting and a few of somebody else's answering, once per job — the line item that weighs on onboarding a remote employee, except it never stops.

The second is cheaper today and dearer later: they do not ask. They take the obvious reason and carry on — and if the real one differed, the customer tells them.

New hires are only the most visible case: the same hits anyone back from leave, anyone inheriting a customer, and you on your own job from six months ago. Usually somebody did write the reason down — at an address nobody now connects to this job.

"We agreed on the call" is the most expensive sentence in the company#

It announces a decision and removes any way of checking it. When two people remember two versions, both remember honestly, and there is nothing to settle it with.

It works exactly once, on the people who were there. For everyone else it is an appeal to somebody's memory rather than to a record.

Somebody else pays, later. The person saying it has the whole thing in their head and feels no friction. The bill arrives a quarter on, at another desk.

Its close relative, "I did write about this in the chat", fares the same.

When to call a meeting, and what the write-up should contain, are separate questions, settled in making decisions without meetings. This piece is only about the address: the call happened, the decision was made, the reasoning even got written up — and where it lives is still open.

The record goes where its subject lives#

A decision about one job — a comment on the job.

A decision about a customer — payment terms, the contact who actually picks up, what we do not do for them — on the customer, not on one of their jobs, or only whoever opens that job sees it.

A decision about how the work is done — in the procedure, with a pointer from wherever it surfaced.

Only the third case is awkward: nobody knows in the moment whether the ruling covers one job or all. The question that sorts it: next time, here only, or everywhere?

Install the habit with one sentence at the end of every call: who writes it down, and where. One name, same day — by tomorrow all that survives is the outcome, without the reason.

One structural condition: the work needs somewhere to live. If a job is a row in a database, the comment has something to attach to and nowhere to vanish — the arrangement in running projects without a project tool.

A model needs reasons, not just outcomes#

Companies that connect a model to their own data start with questions about state: what is overdue, who owns this, what happened with that order. Those answers are good, because state lives in fields.

The second question is "why", and usually there is no answer — not because the model is weak but because the reason is not in the data. A status field holds no justification, and the conversation that produced one is attached to nothing.

A model reads the company the way a new hire does: outcomes visible, reasons inferred. But a new hire can say "I don't know", and a model gives its most plausible guess in the same tone as everything else.

A record on the job also sits unambiguously with its subject — no guessing whether the March agreement covers this job or the next — and it inherits the job's permissions, which a channel message does not. That is preparing company data for AI from the other end: order in what is written down there, the reason getting written down at all here.

Summary#

Chat is organised by time, a company by subject, and the whole problem falls out of that mismatch. Channels, threads and mentions improve delivery, not the address.

The habit is cheap: before the call ends, name who records it and where, and put the record where its subject lives — the job, the customer, the procedure. A few minutes on the day, repaid whenever somebody asks why we do it this way.

The wider context — how to arrange tools so conclusions do not scatter across six apps — is in the guide on remote work tools.