What is the difference between search and memory at work?

Search finds a string. Memory is a decision you chose to keep: who owns it, what it said, and where it still lives after the people leave. They get treated as one because both return text, and a hit on last year’s channel feels like remembering. A ranking function over messages is not the same as a small number of facts somebody was willing to sign.

This guide is for teams whose answer to “what did we decide?” is “search Slack.” You do not have to buy a new index. You do need a habit for what the company is prepared to assert. Institutional memory in enterprise AI is the company-scale version of this distinction; decisions made in direct messages is the cost side.

What is the difference between search and memory?

Search answers: which messages used these words, in rooms I can still see, on dates the retention slider still holds.

Memory answers: which facts we stand behind, who owns each one, when it took effect, and where the live copy is.

Slack and Teams store “this message contains the characters p-r-i-c-e.” They do not store “this message is the price.” The hit on “higher price” does not name the SKU, the customer, or the quote version.

Four limits show up quickly:

• Retention. A 90-day delete is a storage and privacy choice. Last year’s exception will not be in the index. “We can always search” is false on day 91.
• Permission. Private channels and DMs are not in everyone’s results. The person reconstructing the invoice often has the worst access to the room where the exception was typed.
• Export. A company-wide dump is a legal artefact, not a daily tool. Custody is a place that still holds the artefact, not a promise that search used to work.
• Ranking. Search orders by recency and popularity. The wrong “12 percent” — a joke, a different account, a draft — can sit above the right one. Ranking is not judgement.

If the archive is your memory, you have outsourced remembering to whoever typed the most searchable sentence.

Why does finding the message not reconstruct the job?

Because the first answer was a message, not a fact with an owner.

Someone asked “what is the cap on this SKU.” Someone answered in a thread. A week later another person asks again, in another channel, because they cannot see the first thread or do not trust it. A third asks the model, which summarises both and offers a blend. The second ask is not stupidity. Asking again can be cheaper than trusting a hit you cannot attribute.

Yang and colleagues, in Nature Human Behaviour (2022), analysed email, calendar, messages and calls of 61,182 US Microsoft employees. Firm-wide remote work made collaboration networks more static and siloed, with fewer bridging ties. Questions that used to travel through a person sitting between two teams now die in a channel those teams do not share. Search does not rebuild those ties. It ranks the silos.

Asana’s Anatomy of Work Index (2022), from a survey of more than 10,000 knowledge workers, put coordination at 58% of the day. Re-asking is coordination.

A sidebar that answers instantly does not fix this. It has no owner, and next month it answers differently because the thread grew. Onboarding is a factory for the same loop: a new joiner has no threads, so they ask the living, who answer from memory. The answer drifts. By the third joiner the cap is a folk number.

When someone leaves, you lose the index in their head: which thread was the real one, which “12” was a joke, who owned the exception. Their messages may stay; the meaning of “we agreed” does not. A thumbs-up from the person who owned the budget is not recoverable as a role once they are a disabled account. Negative knowledge is worse: “we tried 12 on this SKU last year and legal refused” is rarely written. Search will not return a refusal that was only a spoken warning in a huddle.

How do you make work easier to reopen later?

Write a short assertion the company will stand behind, then point chat at it.

Use an owner-and-date test on anything you call knowledge: can you name the person who owns this sentence and the date it took effect? If not, it is not memory, whatever it is indexed in. If the only copy left with the laptop, it was a conversation that ended.

A wiki that is a paste of threads is a dump of chat with a nicer URL: no owner, no date that means “in force,” and a page that grows until nobody trusts it. A wiki that is memory is a short set of assertions: the cap, the policy version, the playbook for this job. Someone owns each page. When it changes, the old version remains.

What an AI workstream is is not a wiki of everything. It is the brief and the artefacts for this outcome, visible to the roles on it. A dump tries to be everyone else’s memory and becomes no one’s. That named container is the workstream.

Remember what another team will be measured on after you leave: prices, credits, dates, scope, who was allowed to change them, and where the change landed. Do not remember the status ping, the joke, or “can you join at 3.” Short retention is correct for those.

A practical list for one function, not a programme:

• The exception, with object names the systems use.
• The signer, with a timestamp from the system, not from memory.
• The policy version that was in force that day.
• The outcome in the system of record.

If you cannot name the owner of an item, keep it out of the wiki and let it expire in chat.

What does this look like on a real team?

A revenue team is asked, twice in two weeks, what the discount cap is on SKU A-440. Search finds three hits: a joke in #social, a draft in a private channel, and last year’s exception for a different customer. Nobody can say which sentence is in force.

A useful memory for the same question is one line on a page or workstream note: cap, date, owner, link to the rate card. Chat can still debate a new exception. The page is what the second asker opens.

Offboarding that says “export their Slack” produces a zip with no owner. “Transfer the jobs they signed” produces a roster change. The zip is for counsel. The roster is for Monday.

More corpus is not automatically more memory. An index over unowned text can raise confidence without raising accuracy: a near-miss from a different customer reads as a fact. A vector store of the archive is still the archive — a neighbour in language, not a fact in force. You have bought fluency about things nobody asserted.

How do you start without a new search product?

Take the question your team asked twice last week. Write the answer in one sentence with an owner and a date. Link it from the thread. That takes longer than pasting the thread, and the extra minute is the cost of memory. The re-ask is the cost of skipping it.

Then write the refuse as well as the grant, if last year’s “no” is still load-bearing. Yang et al. observed fewer bridging ties under firm-wide remote work; the leaver was often the only bridge. The written refuse is how the next person inherits the warning.

Nimbus can hold asserted playbooks next to a workstream. You do not need that product to start. You need one fact the company is willing to be held to, sitting somewhere that is not only the index.