Back to Essays

Why SOPs (and not tribal knowledge) is the right foundation for Agent Memory

There is a mad rush to build and improve agent memory right now. Rightfully so. Unfortunately, most approaches are heavy on prioritizing conversation logs, mining them for decision traces and treating that as foundation of the memory layer. I will be honest - generating a markdown file out of a Slack channel feels like magic. The problem though is it doesn't acutally solves the agents problem.

I know this because at CogniSwitch we shipped precisely that.

In 2019, CogniSwitch team released Ariv. Ariv means knowledge, in Sanskrit. It lived inside Slack and Teams as a bot, reading every conversation and indexing what got shared, then handing the answer back when someone asked for it. In 2019 that sounded like black magic. In 2026 it reads as the obvious thing to build.

This was before ChatGPT, before most people had touched a large language model at all. The first version of Ariv ran on the stack you would expect from that era: random forest, TF-IDF, word2vec, spaCy. The move to BERT-era transformers came later, after the first version had already proven itself internally at what was then Aikon Labs. Ariv was built to solve our own internal problem first. Because it worked, we launched it as a Slack app. There was a Product Hunt push, upvotes, the whole thing. Josh remembers landing around #3 on the board that day. A hundred, two hundred installs. The reaction, once people actually used it, was consistent: yes, this is a real problem. Finding anything in Slack, or Gmail, is a nightmare, and it still is.

Then it never really took off.

What we assumed, and what we learned

For a while the assumption was that the miss had to be about answer quality. Better retrieval, better ranking, a bigger model once bigger models existed. That wasn't it.

The real answer came out of the feedback rounds Josh ran, once the team pushed past "yes, this is a real problem" and started asking people to put money against it. The same pattern came back over and over: a Slack message carries no authority and no approval chain behind it. If somebody said something in a thread, even when it turned out to be correct, there was no way to know that without going and asking the person directly.

An SOP is different. It has a name on it and a date. When we dug deeper and asked people why the document version landed better than the conversational one, the answer was some version of: if it's a trusted document, I can use it. Almost nobody said that about a Slack thread, no matter how right the answer buried inside it happened to be.

Trust was the core problem, not retrieval.

What that forced us to rebuild

The instinct, and it is still the industry's default instinct, is to treat conversation logs and meeting transcripts as the primary substrate for enterprise memory, on the assumption that structured documents are the solved problem you will get to eventually. That is backwards.

To be clear, conversations are not useless. There is a ton of operational insight sitting in them. The realization was to stop treating them as the source of truth and start treating them as the place where SOPs drift. A knowledge cycle runs from create to retire to renew, and conversations are where you catch the deviations: the exception someone made, the workaround that shipped before the SOP caught up. That is the real signal. Its job is to update the document, rather than replace it.

Structured knowledge isn't a layer you bolt onto conversational memory after the fact. It has to come first, because it is the only layer with a name attached and a reason to be believed. This wasn't a one-time insight. The same thread ran through everything that came before Ariv. Dilip had been circling knowledge reuse since Zensar's Solution Blueprint: knowledge you can reuse has to trace back to something you can trust, or the reuse doesn't hold up.

Why Knowledge Layer for Agents starts with SOPs

A context graph's job isn't to answer a question straight out of the thread where the drift happened. It should ingest the curated, updated SOP, and treat the conversation as the tip-off that the SOP needed updating in the first place.

So if you are building the context layer for agents right now, don't prioritize conversations over SOPs. It is tempting, because conversations are already sitting there, easy to scrape and easy to embed. The order still matters. Explicit knowledge comes first: reviewed, sourced, with an owner's name on it. The tribal knowledge living in threads and DMs gets curated into that structure afterward.

Knowledge Layer for Agents is that lesson, rebuilt on the stack we have now instead of the one we had in 2019. The code is open source at github.com/CogniSwitch/KL4A, and the overview of what it does is on the Knowledge Layer for Agents page.

About the Author
Vivek Khandelwal

Vivek Khandelwal

Chief Business Officer, CoFounder @ CogniSwitch·M.Sc. Chemistry, IIT Bombay

Vivek Khandelwal is the Chief Business Officer at CogniSwitch, where he leads go-to-market strategy, enterprise partnerships, and the company's thought leadership programs. He is the author of Signal, CogniSwitch's weekly newsletter that translates the complex machinery of enterprise AI infrastructure into clear, actionable intelligence for practitioners and executives in regulated industries.