Decisions die in chat threads. Make them searchable instead.

Short answer: The most valuable thing your team produces (the reasoning behind a decision, and the options it rejected) happens in a thread and then scrolls away. Six weeks later somebody asks the same question and the AI has no idea it was ever settled. The fix is not to record everything. In Crew Orbit you select the messages that mattered, the AI drafts a note, and a human edits and confirms it before it becomes a searchable, citable document in the knowledge library, linked back to the conversation it came from. Nothing is captured unless a person approves it, which is exactly why the notes stay worth retrieving.

Your most valuable writing is your least durable writing

Think about where an architectural decision actually gets made. Not in the ADR. The ADR, if it exists, is a tidy summary written afterwards by whoever lost the argument least. The decision gets made across forty messages in a room, over two days, with a diagram somebody pasted, three objections, a benchmark result, and a final "ok let's do B but we revisit if latency regresses".

That thread contains something no document in your repository contains: the rejected options and why they were rejected. It is the difference between knowing that you use a queue here and knowing that you tried the synchronous version first and it fell over at 400 requests per second. The first fact stops one mistake. The second stops the whole class of mistake, including the confident refactor somebody proposes next spring.

And it is the least durable artefact your team owns. It is not in search results that anyone thinks to run. It is not in the repository. It is unreachable to any AI you point at your codebase. In practice it survives only in the heads of the people who were in the room, which means it leaves when they do.

The visible symptom is the re-litigation cycle: the same question raised in a new thread, argued from scratch, sometimes reaching the opposite conclusion because whoever remembered the benchmark has moved teams. Every organization over about fifteen engineers is paying this tax, usually without measuring it.

Why the fix is not "index everything"

The tempting solution is total capture: connect the AI to every room, index every message, and let retrieval sort it out. This fails for two independent reasons, and it is worth being precise about both because they pull in different directions.

It destroys the signal. A knowledge base of every message is mostly scheduling, mostly "on it", mostly links that expired. Retrieval quality is a function of what fraction of the corpus deserves to be retrieved. A conversation archive has an extremely low ratio, and it drags every genuinely good document down with it. Now the top matches for "why do we use a queue here" include four people saying "queue?" in unrelated threads. Teams that index everything typically stop trusting the AI's answers within a month, and they are right to.

It changes what the room is for. A room people know is being permanently indexed becomes a room where people are careful. That is fatal to the exact thing you were trying to capture: half-formed objections, the tentative "am I wrong that…", the honest "I have no idea". Ambient recording is not a neutral observer. It makes the conversation worse, and then indexes the worse conversation.

So the design constraint is not "capture more". It is: capture the small fraction that deserves to be permanent, with a human deciding which fraction, in a way that does not change how people talk.

How selective memory works

In Crew Orbit, promoting a conversation into knowledge is a deliberate, four-step act with a person in the middle of it:

• Select the messages that matter. Not the thread. The messages. The three that contain the decision and the reason, not the twenty around them.
• The AI drafts a note. A draft dialog shows the selected messages beside an editable note, so you are reviewing a summary against its source rather than trusting it.
• A human edits and confirms. This is the step that makes the whole feature work. The draft is a starting point. You fix what it got wrong, add the thing that was obvious to everyone present and therefore never said aloud, and choose the visibility. Nothing is saved without somebody approving it.
• It becomes a real document. After confirmation you get a persistent confirmation with a View in Knowledge link, not a toast that vanishes before you can act on it, and the note runs the same ingest pipeline as any uploaded file until it reports as searchable.

Visibility follows where you saved from, into the library you are already authorized for. A workspace room or workspace Ask session saves at workspace visibility. A project or work-item conversation saves to that project. There is no private knowledge visibility, because a note only one person can retrieve is not institutional memory.

Human-curated, not surveillance

It is worth stating the design position plainly, because it is both the honest description of the product and the argument for it: nothing is auto-indexed. Crew Orbit does not silently ingest your rooms. A person picks what deserves to be remembered.

This looks like a limitation and reads like a feature request ("can it just capture decisions automatically?"), and the answer is that automatic capture would make the library worse, not bigger. The curation step is the quality filter. A library of two hundred human-approved notes answers questions better than a library of two hundred thousand messages, and the team trusts it, and nobody had to be told their conversations are being recorded.

There is also a governance dimension that matters if you have a works council, a DPO, or simply employees with reasonable expectations. "We index selected messages when a person chooses to, and here is the record of who saved what" is a much easier conversation than "we index everything and rely on retrieval permissions". The same instinct runs through the rest of the platform. See governing AI changes before the pen test asks.

Traceable back to the conversation behind it

A summary without a source is a rumour with formatting. Every saved note keeps a link to where it came from (the originating room or the originating Ask session), and that link is part of the document, not a note in the body somebody has to maintain.

This matters at the moment of maximum doubt. Someone retrieves the note in a cited answer, reads "we chose B because the synchronous path degraded above 400 rps", and thinks: that does not sound right, or that was probably before the caching work. They open the origin link and read the actual exchange, including the caveats the summary compressed. The note stops being an assertion and becomes an entry point.

It also gives you a cheap freshness check. When a note looks stale, the conversation behind it usually tells you whether the decision was revisited. And if it was, that revisit is itself a thing worth saving.

Same lifecycle as every other document

A saved note is not a special second-class object. It lands in the knowledge library alongside uploaded files, pasted text, fetched URLs, and synced repository documentation, and it behaves the same way:

• Searchable: it runs the same ingest pipeline and reports plainly when it is searchable, in the same library you browse with folders and tags.
• Citable: when it grounds an answer, it appears as an openable citation like any other source. This is the same citation machinery described in why your AI should cite its sources.
• Filterable: the library filters by source kind, so you can look at memory notes specifically when you want to review what your team has decided to remember.
• Deletable: deleting the note removes it from search and never touches the conversation it came from. That is the important guarantee. The messages stay where they were. Curation is reversible, and reversing it is not destructive.

That last property is what makes people willing to save things in the first place. If promoting a thread felt permanent and consequential, nobody would do it. Because it is a document you can delete, saving is low-stakes.

Works from human rooms and from AI sessions

Decisions do not only happen between people. A long Ask Crew Orbit session where somebody worked out how three services actually interact is exactly as valuable as a room thread, and often more concentrated. The reasoning has already been organized once.

Save to knowledge works from both: collaboration rooms and Ask sessions, with the same draft-edit-confirm flow and the same origin linking. Saving from an Ask session has a pleasing property: the AI's answer, once corrected by a human, becomes grounding for the next answer. Rather than re-deriving the same explanation for the next person who asks, it retrieves the version your team already checked.

The caps are real, and small on purpose

Two limits are worth knowing before you plan around this feature. A single note is built from at most 20 selected messages, with an aggregate size cap of 32 KiB for summarization.

We mention them because real limits are more useful than vague reassurance, and because knowing them changes how you use the feature. You cannot promote a 300-message thread wholesale, and you should not want to: if a decision genuinely needs 300 messages of context, what you have is several decisions, and they will each be more retrievable as their own note. The cap nudges you toward the granularity that actually retrieves well.

A few other honest boundaries. Ingest and search need an OpenAI credential from your workspace credential store for embeddings. Without it, knowledge reports as unavailable rather than degrading quietly. Document and chunk counts are subject to plan quotas. And the whole knowledge subsystem sits behind a single kill-switch, which is deliberate: if something needs to be turned off, it turns off in one place.

What a saved decision should contain

Because a human edits the draft, quality is a habit rather than a feature. The notes that earn their place tend to share a shape:

• The decision, in one sentence, at the top. Retrieval matches on text. A note that buries the conclusion in paragraph four retrieves worse than one that states it first.
• What was rejected, and why. The single highest-value part, and the part an AI draft most often drops because it was implicit in the thread.
• The condition for revisiting. "Revisit if latency regresses" is the sentence that turns a decision into a decision with a shelf life.
• The nouns somebody will search for. Service names, the actual technology, the customer or project the constraint came from. Write the words a colleague would type, not the words that felt elegant.

None of that is enforced. It is just what separates a note that answers a question in November from one that gets retrieved and then ignored.

The compounding argument

Most tooling is worth roughly the same on day 400 as on day 40. This is not: the library only grows, and every note added is a question the AI can answer from your own history instead of from generic training data.

Here is the practical version, in the order you notice it. Within weeks, the questions a new joiner asks in their first fortnight start having answers, because someone saved the explanation the last new joiner needed. Within a few months, "why do we do it this way" begins to return your own reasoning with a link to the argument. Within a year, the departure of a senior engineer stops being a knowledge event. The decisions they made are documents, not memories.

That is also, bluntly, the retention argument for the platform, and it is worth being transparent about: a team with two years of curated institutional memory has something it did not have before and will not casually throw away. It is a real switching cost because it is real value, built one approved note at a time.

What this does not do

Two limits that come up immediately, both worth stating rather than discovering:

It does not read your Slack. Crew Orbit's Slack integration exists for collaboration commands (binding a channel to a project, invoking the AI, creating work from a thread), and knowledge retrieval is deliberately not enabled on it. Save to knowledge works from Crew Orbit collaboration rooms and Ask sessions. If your architectural arguments happen entirely in Slack today, the honest sequence is that the conversation has to move to a room in the platform before it can be promoted, and you should weigh that as real adoption friction rather than assume a connector solves it.

It does not capture anything on its own. This is the design position described above, and it is not a roadmap gap we are working around. If your requirement is "a system that remembers decisions without anyone doing anything", this is not that system, and we would argue that system does not produce a library worth retrieving from.

Stop re-deciding things you already decided

If your team's real reasoning is scrolling away in threads while your AI answers from generic training data, the gap is institutional memory and it is fixable one approved note at a time. Start at crew-orbit.com.

Related reading: how to review AI-generated code without a black box and cross-functional review without code archaeology.