the knowledge base

My Teams folder is a GitHub repository. I wrote that on LinkedIn once, and the same question kept coming back: sounds great, but how do I actually set that up myself? Honestly? Less exciting than people hope. A folder of markdown files, one instruction file, and an AI that can get into that folder. That’s it. No more infrastructure than that. I work in mine every day, with Claude Cowork.

And it didn’t start as some clever idea. It started back in my consultant days, and it’s been a game changer. A project at a big corporate: implementing Sales and Service Cloud, SAP, with S/4HANA as the ERP system underneath, and I ran thirty Solution Design sessions for it. We recorded all of them. Made transcripts, speech-to-text, and we dumped the lot into a knowledge database. My own living knowledge bank. I could work in it live, together with my partner. We’d set it up in Teams back then, with the Teams Read&Write tools, so that ran over an MCP server. Both of us worked in it at the same time. He’d process new transcripts, adjust the solution design, and it landed straight back in there. In the end the two of us put together a 150-page solution design. Two consultants, in genuinely little time. No way that ever happens without the knowledge bank.

So the tool isn’t the interesting bit. The LLM-wiki, that’s the concept I reach for most, because it fits basically everything, and it makes knowledge centrally manageable with almost no effort. How a wiki like this works on the inside, and why writing documentation for machines gets you further than a better prompt, I put that in an earlier piece, context beats the prompt. But that was the personal side of it. One workspace, one user. This one’s about what sits on top of that. Who keeps the knowledge base up to date? Who’s allowed to write in it? And when two pages flat-out disagree, who gets to decide what’s true? Every earlier generation of knowledge systems ran aground on exactly those questions.

the archive nobody reads

Almost every company has one of these graveyards. A shared drive, an intranet, a wiki someone set up with the best intentions that went quiet after three months. And what killed it is hardly ever the software. It’s the upkeep. The maintenance grows faster than the payoff, so people just quietly stop.

Here’s what I see at organizations, over and over. The knowledge just sits with individuals. It lives in people’s heads, and companies keep losing it, because it walks out the door the moment someone leaves. And that’s not because anyone’s lazy. It’s simply that people are busy with their own work. I’ll be honest about myself here too. Back in those project years I was buried. Three projects at once sometimes, and you just haven’t got the energy or the time to also write down everything you’re picking up along the way. Nobody has. With a living knowledge bank that part happens on its own.

Then the second wave of decay sets in. The archive’s gone stale, so nobody trusts it, so whoever finds an answer double-checks it with a colleague anyway, and whoever knows something useful stops writing it down, because, well, who’s reading it? A wiki nobody tends isn’t merely incomplete. It’s a heap of expired claims in a documentation costume, and that really is worse than nothing.

And the takeaway isn’t “companies should finally get disciplined”. History says they won’t, and the company wiki is exhibit A. The takeaway is that the upkeep has to move somewhere else.

two readers, one source

Here’s what makes this knowledge base different from every one that came before it. There are two kinds of readers now, and they’re reading the exact same file.

The AI treats the wiki as its working memory and keeps it current as the work rolls on. You read the same folder as a reference. And if you want something nicer to look at, point Obsidian at that folder. It’s free, it turns a pile of markdown into a click-through knowledge base, and it’s got a graph view that shows you at a glance what links to what, and which pages are just dangling there with nothing pointing at them. The AI writes while the conversation’s happening. You browse along in real time.

And that’s the organizational payoff. You’re not keeping one set of docs for the humans and a separate stash of context for the machines. It’s one source of truth, in the one format both of them read fluently: plain text, in folders. No vendor. No subscription. Nothing to migrate when next year’s tool shows up under a different name. And above all, no two versions of reality quietly drifting apart.

who maintains what

This split of roles is the heart of the method. And it’s strict.

You’re the editor. You bring in the sources, you set the direction, and when two pages contradict each other, you’re the one who makes the call. The raw sources, though? Those are sacred. The AI reads from them and never, ever changes a thing.

The AI is the writer. Every cross-reference, every summary, every index line, every log entry, that’s all its work. Which is, funny enough, exactly the tedious grind that every human wiki-keeper walks away from at some point.

And the whole thing is built so a machine can work in it efficiently, because a machine made it. There’s a central intro file, the CLAUDE.md, and it holds the instructions and the golden rules the model reads every single time. Top-down, from an instruction folder nobody gets to quietly change, you make sure everyone’s always working with the AI under the same rules. That on its own is powerful.

Then every session leaves a log of whoever’s been working in it. Say I’m in there and I flag it in my session: a summary gets made automatically. What got done, what I did, where it’s written down. Live. And if Jantje’s working on something at the same time, we know it from each other straight away, because our models both see it. Huge for multi-person projects, and no separate software bolted on. Sure, you’ve got Slack and the rest built for exactly that, but here it’s your own, and it can live locally.

So rot and sprawl don’t get held off by good intentions. They get held off by a fixed routine. Three operations. Ingest: a new source gets folded into the pages you already have, and anything that clashes with what’s there gets flagged instead of quietly overwritten. Query: a good answer gets written back as its own new page, so asking questions builds knowledge too. And Lint: a regular health check that hunts for contradictions, claims that have gone stale, pages with nothing linking to them, and terms that don’t have a page of their own yet. That last one is what separates a real knowledge base from a heap of notes. It catches the rot before anyone builds on top of it.

And the upkeep has a fixed slot in the day. Every session ends the same way: with an instruction to update the wiki with whatever that session just taught us. No documentation sprint. No quarterly clean-up. The maintenance is simply the last thing that happens in every block of work, and that’s the whole reason it keeps pace with the work on its own.

from folder to foundation

You can start small and local, in a plain folder on your own machine. The thing that turns that folder into something an organization can actually stand on is the repository. Push it to GitHub and, in a single move, you get version history, a backup, and room for a team to come in. And that’s not just a convenience. It’s governance. Every change the AI makes shows up as a visible change in version control, reviewable and reversible, exactly like code. A writer that never tires needs an editor who can see what it’s been up to.

And that’s where the whole Teams-folder line comes from. It’s got nothing to do with repos being fashionable. It’s that a repo is the only shared storage an AI agent can genuinely work inside while every change it makes stays traceable.

You can carve it up however you need, too. Split the knowledge bank per project. Or run one big org-wide one with all the projects and departments sitting under it. Or scale it project by project. And the nice thing is, the AI starts spotting connections you’d never have found yourself. Every time, you get to prompt with a huge amount of context standing behind you.

Where it lives is your call as well. Locally is mainly nice for the projects I run on my own. But you can put it in the cloud just as easily. Microsoft Teams is the obvious pick for an enterprise, though OneDrive or Google Drive does the job fine, and there’s no paid chat-function subscription hanging off the side of it.

The open question sits one floor up from all of this. Writing into the same wiki with a whole team at once, without everyone colliding, that part I haven’t fully solved. Version control soaks up the technical collisions, so you’d think that settles it. It doesn’t. The editorial question just sits there: when two pages disagree, who actually decides which one wins? For me alone, and for a small team with one clear editor, the way Jantje and I ran in the same bank live, it works today. Genuinely. The governance for ten simultaneous writers, though? Still a work in progress.

Where the whole regime proved its worth: I’d done a CRM project at one client, and then I ran into a comparable process at a second one. And the wiki was just up to date. Right there, in the moment, because the updating had never stopped. I didn’t have to sit down and work out whether I could still trust it first. The AI took the pattern it had on record, applied it to the new situation, and pointed out differences I’d long forgotten about myself.

And that, in the end, is what turns a shared knowledge base into a foundation. Every earlier generation of this stuff was a place work had to go after the real work was done, kept up by people with better things to do. This is the first generation where the thing works right alongside you. It reads along, it writes things down, and it gets a little better every single session. A knowledge base that pushes back on you isn’t really an archive anymore. It’s more like a colleague. One who never moves on to the next project and disappears.