How we're organizing our company's knowledge so AI can actually use it

Many companies are not good at organizing institutional knowledge. Take a simple example: the competition in your market. Your product team looks at it through features and user experience. Your marketing team looks at the same competitors through campaigns and messaging. Your exec team, BD group, partnerships, and finance all have their own analyses running. If you're like me, you have a sneaking suspicion there's a lot of waste in all of this.

Are they using the same competitor list? Would they all agree on who the biggest competitor is? Are they counting only direct competitors, or anything competing for your customer's dollars? At most companies, the honest answer is that nobody knows, because much of this work is being done in silos. Organizing institutional knowledge, and maintaining it, is hard. More to the point, it is seldom anyone's priority.

In the age of AI, the stakes go to another level. Here's why.

First, the nature of the work is changing. People are moving from asking AI a question and pasting the answer into whatever they're actually working on, to handing over the whole job and getting back something finished. That's been true in our engineering team for a while, and we're starting to see it in content, design, marketing, data science, and product. In a back-and-forth chat, you are the context. Hand over the whole job and AI has to find the context itself. For that to work, institutional knowledge has to be organized at the company, team, and project level, and reachable quickly and cheaply.

Second, AI multiplies whatever context you give it. Every team can now produce more without adding people. But if each one is working from its own version of the truth, you aren't just scaling output, you're scaling the inconsistency underneath it. A marketing team working from its own private view of the competition used to produce a deck a quarter. Now it produces at volume, all day, and so does every other team. The efficiency gain magnifies the impact of context that's inconsistent or, worse, inaccurate.

Third, context is the advantage you actually own. Your competitors use the same models you do. Any edge you think you're buying with a better tool, they can buy too. What they can't buy is what your AI knows about you, your customers, your history, and the decisions you've already made. That's your context, your company DNA, and it's the real asset.

This piece is about how we're getting our institutional knowledge into one place, the trade-off we made, and where we're heading. Of course, like most companies right now, we're flying the plane as we build it.

What we're building is one place that holds the knowledge we want shared across the company and teams, readable by both people and AI. We call it the Commons, and it is very much under construction. Some of it is real and in use today. A lot of it is still in planning.

The gap we're trying to close looks like this.

What belongs in the Commons is either the stuff nobody writes down because everybody already knows it (except AI), or the stuff everybody thinks they know but everybody might explain differently. At the company level, that means things unique to you:

There are also team commons. This is a deeper level of institutional knowledge that needs to be shared across people working in a team or project but may not necessarily need to be known by other teams.

Company vs. Team/Project

One half is curated at the company level. This is what all groups and all employees working with AI would need to have as context. It holds what's broadly relevant across the company, and every section is meant to have a named owner who is responsible for what's in it.

The other half belongs to individual teams and is deliberately looser. Team norms, working notes, drafts worth keeping around.

One thing we've learned is that organizing it this way is easy, but the ownership part (including ongoing updates) requires organization and investment of people's time. That is roughly where we are today. Deciding the structure took weeks. Filling it is taking a lot longer.

Indexing

Indexing is no longer just the domain of databases. Every folder in our Commons has an index.md file whose only job is to explain the folder - what's in it, how to navigate it, and how much to "trust" it. That last part matters more than it sounds. A rough draft and a decision the leadership team signed off on shouldn't carry the same weight, and if you don't say so, AI could treat them the same.

Our first instinct was to use what we already had. We live in Notion (previously Confluence). Just add some information, improve structure, point AI at it, and be done. We eventually chose a different direction. Here's why.

Another group in our org suggested moving our "one version of the truth" out of Notion and into plain text files since that might be more efficient for AI use. So we tested it. We took over 800 documents that already live in Notion and copied them into plain text files. Then we asked AI the same questions twice, once with Notion as the context and once with the files.

Speed was nice, but completeness (or incompleteness, rather) is what changed our minds. On the broad question, when AI used the Notion search, it missed documents it should have found. When we asked why, it explained that reading every page meant hundreds of separate fetches, expensive in time and cost, so it had filtered by title and read only a handful in detail. Not good.

So now the Commons is plain text files in a code repository, self-hosted on Gitea. Git is what engineers have used for years to manage files that keep changing. Every edit we make is recorded. You can see who changed what, and anything can be rolled back.

We started by moving Notion docs over to the repository, and now we're adding and editing directly in it.

Side note: None of this means Notion is a bad product or you shouldn't use it for your organization's version of the Commons. For most organizations it's the right answer. What made files work for us is that we already had engineers and repositories, so the cost-benefit trade-off of using Git organization-wide vs. using Notion made sense. Many organizations will not have the expertise or infrastructure ready to go that we did.

So here is what we gave up. Files in Gitea are worse for people working on a document together, at least as it feels to people today. Notion has comments, threads, suggestions, and someone editing alongside you. A repository has versions of some of that, but not in a form most business users would recognize. We decided that speed and completeness for AI mattered more, and we made that call with our eyes open.

What's unresolved is what collaboration looks like in this setup, and where it needs supplementing. Some of it we'll solve by getting better at using AI with the Commons itself, but no doubt we'll still need other tools like a wiki, Google Docs, or Microsoft 365 for document collaboration.

There's also a reason to think the upkeep cost shrinks from here. As more of the work moves into AI, more of the updating gets done by AI rather than by a person remembering to do it. A finished analysis gets written back. A decision gets recorded where it was made. That is a lot easier against files than against a wiki: writing a file is an ordinary thing for AI to do, while updating pages through an API runs into the same slow, many-calls problem that showed up in our test. The choice we made for speed and completeness may turn out to be the thing that keeps the Commons current.

Fair question. A colleague of mine wrote that "our data isn't ready for AI" is the new "we'll do it next quarter", and he's right.

The test is whether it blocks anything. Nobody here waited on the Commons to start using AI. We'd been at it for years first, and we started writing things down because the gap had become obvious, not because we were getting ready.

Start small and start with real work. If your first version needs a quarter and a steering committee, you're building the wrong thing.

This one is easy to get wrong in the enthusiasm. The Commons is for knowledge you want shared broadly, which makes it the wrong home for sensitive material. Finance, HR, and exec material stays in its own access-controlled place, and those teams publish only what they want everyone to have. Set the access rules before you put anything in, not after. Nothing should go wide by accident.

What we have today is a place people and AI read from. What we want is a place the work itself runs through.

Picture a product manager with a new idea. AI searches everything we've learned from users, finds the two times we tried something adjacent, pulls what we already know about the competitors who have done it, and drafts the spec against our own standards. A designer picks up that spec and the comps go back in. Engineering builds from it. The analysis of whether it actually worked gets written back to the same place. Every step reads from the shared context and adds to it.

The Commons isn't our end goal. It's what makes the next stage of AI transformation possible. The more of our real work that moves onto AI platforms, the more the Commons is worth, and the more that work produces knowledge which flows back into it. Neither piece works without the other, which is why we're pushing on both at the same time.