Resources
A plain explanation of the category: what an operating memory is, how it differs from search and from a wiki, and what it actually takes to answer a question about your own company with evidence attached.
roughly 8 minutes · written for founders and engineering leaders
An operating memory is a connected record of what an organization said, decided and did — kept current automatically, and answerable in plain language with the evidence attached.
Operating, because it is about running the company day to day rather than archiving it: what changed since Friday, what is stuck, who owns the thing nobody has picked up. Memory, because the information is not new. Every fact it holds was already produced by someone on the team. It was simply never held anywhere the whole team could reach.
The word people usually reach for instead is “knowledge base”, and it is the wrong one. A knowledge base is written on purpose, by a person, about how things are supposed to work. An operating memory is derived from what happened, whether or not anyone thought to write it down.
Drop any one of the three and the thing stops working. Connected but stale is an archive. Current but scattered is a search index. Connected and current but unevidenced is a chatbot with opinions about your company.
These are the three things it gets mistaken for, and the difference in each case is worth being precise about.
Search matches words against documents and hands you ten results. It is excellent when you know what you are looking for and it exists in one place. It cannot tell you that a decision made in March was quietly reversed in a thread in June, because that is not a document — it is a relationship between two of them.
A wiki is accurate on the day it is written and decays from then on. It records intent, maintained by whoever has the discipline to maintain it, which in a busy company is nobody past week three. An operating memory is derived from work that is happening anyway, so keeping it current costs no one any discipline.
This is the closest relative, and the difference is provenance. A chatbot retrieves some text and writes a fluent paragraph. An operating memory keeps the link from every claim back to its source, and refuses when it has none — so you can tell the difference between a fact and a well-phrased guess.
In practice there are three ways, and most companies are doing the first two.
The third option sounds obvious and is the hardest, because four unglamorous things have to be true before it works. Identity has to be resolved: the person who is @sam in chat and s-okoye on a commit is one human being. Subjects have to be resolved: a channel, a repository and a document are all talking about the same project under three different names.
Then most of the input has to be discarded. The overwhelming majority of messages carry no operational meaning at all, and a system that treats every line as signal produces noise proportional to how chatty the team is. Finally, provenance has to survive all of it — because the moment a derived fact loses its source, it becomes a rumour with good posture.
A founder's real question, incidentally, is almost never “what is the status of project X”. It is “what changed since I last looked, and which of those things needs me”. Any system that can only answer the first question will still leave you reading everything.
The obvious answer is a decision log, and the reason almost nobody has a useful one is that decisions do not arrive announced. They happen in the middle of a thread, at minute forty of a call, in a review comment that ends with “fine, let's do it that way”. By the time anyone recognises it as a decision worth logging, the moment has passed and the context is three days back in the scroll.
So a decision record that depends on someone choosing to write it down will always be missing the decisions that mattered most, which are the fast ones. The workable approach is to derive them from the conversation, which means capturing four things about each: what was decided, who decided it, when, and what it changed.
Execution is the easier half — pull requests, commits, deploys, review comments are already structured and already timestamped. Connecting the two halves is a matter of matching subject, time window and the people involved: the decision to change an approach on Tuesday, and the branch that started reflecting it on Thursday.
What makes this worth doing is not the tidy record. It is the disagreements it exposes. A decision with no execution behind it is a plan nobody started. Execution with no decision behind it is work nobody agreed to. Both are cheap to fix in the week they happen, and expensive to discover a quarter later.
“With evidence” is a system property, not a prompt. Four things have to hold, and the fourth is the one most products skip.
When a fact is extracted from a message, the identifier of that message is stored with it, in the same write. Asking a model afterwards which source a claim came from produces a plausible answer and no guarantee — you have added a citation, not a proof.
Whatever is fetched to answer a question has to arrive with its origins intact, so the answer can name them. If the retrieval layer flattens everything into an undifferentiated block of context, the citation is lost before the model ever sees it.
The model's job is to read the retrieved evidence and report it, not to fill gaps from what it learned during training. General world knowledge is exactly the failure mode here: it is fluent, confident, and about a company that is not yours.
The hard one. When the retrieved evidence does not anchor to the subject of the question, the correct output is a refusal that says what is missing. A system with no refusal path has one behaviour for facts and guesses alike, and you cannot tell which one you just got.
It is not a task manager. Nothing about remembering what happened tells you what to do next, and a memory that starts assigning work has quietly become a different product with a different failure mode.
It is not an autonomous agent. Reading is a low-risk operation; writing into the systems a company runs on is not, and the second does not follow from the first just because the same model could do both.
It is not a substitute for judgment. It can tell you a decision was made, when, and what happened afterwards. Whether it was the right decision is a question about your business, and no amount of evidence retrieval answers it.
And it should not be introduced as monitoring. It reads the work — the channels and repositories a team agreed to connect — and a team that finds out about it afterwards is right to be annoyed. Whoever adopts one should say plainly what is connected, and to whom the answers are visible.
OSAgent is an operating memory for your company. It connects what your team said, what your team decided, and what your team actually did — so you know what changed, what's stuck, and why. Every important answer has a trail.
It reads Slack, GitHub, Discord, documents and meeting transcripts, reading them without modifying your work. When it cannot cite an answer it says so. And it does not decide anything: OSAgent doesn't run your company, it gives you the context to run it.
A connected, continuously updated record of what a company said, decided and did, which can answer questions in plain language and show the sources behind each answer. It is derived from the tools a team already works in — chat, code hosting, documents, meeting transcripts — rather than written by hand.
Search finds documents that match your words and leaves the interpretation to you. An operating memory answers the question about the situation — what changed, who owns it, why it stalled — and shows which messages and documents support that answer. Search returns a reading list; a memory returns a position you can check.
Only if provenance is kept from the beginning. Each extracted fact has to be stored together with the message, pull request or document it came from, at the moment it is written. Citations cannot be reliably added afterwards, because by then the link between the claim and its origin no longer exists.
By resolving the same person across both systems, then linking a conversation to the pull requests, commits and deploys that followed it on the same subject. Once both halves live in one record you can compare them — and when the decision and the execution disagree, that contradiction is usually the most useful thing anyone will read that week.
Refuse, and say what is missing. A language model asked a question will nearly always produce fluent text, so returning nothing is a behaviour that has to be designed in deliberately. A system that cannot refuse cannot be trusted when it does answer, because you have no way to tell the two cases apart.
No. A tracker records intent — what somebody said they would do, and the status they last remembered to set. An operating memory records what actually happened across the tools where the work took place. They answer different questions, and the interesting signal is usually the gap between them.
The concept is easier to judge against your own week than in the abstract. We connect a source with you and you ask it something you already know.
no self-serve signup · workspaces are set up with you
