LLM wiki. AI company brain. knowledge base. Context OS. Obsidian-vault style markdown graph. All of these ideas and concepts are ways of talking about the same core thing:
How do I build an internal knowledge system, and processes for it, that works for both my people and their agents?
I’ve spent just under a year designing, deploying and iterating on company context operating systems, primarily for GTM teams.
I’ve seen how powerful these systems can be, doing everything from accelerating content production by 5x all the way to helping onboard new hires faster.
I’ve also seen where they break, where they confuse new users and where they are just not the right tool for the job.
I’ve found two core questions and one big idea are the best way to organize these learnings. Before we get into it, Let me put this into context.
Context mattered before AI. Shared context, stories and meaning-making are what allows us to work together.
Our ability to tell stories is one of the biggest differences between human beings and any other animal on the planet. One of the other differences is in our intuition.
You can use your intuition to fill in the gaps and hold multiple potential outcomes in your head.
AI cannot do this. Agents are a tool, bounded and hard capped by the context you provide. Every piece of work you do with AI is now capped by the quality of your context.
This is why you need to start treating your company knowledge like mission-critical code, with explicit processes.
Your context is now mission critical to every AI workflow you use it in.
AI is only as good as the context you provide it.
“What is the best way to organize my context?”
Break it down into packages scoped per team and domain. An explicit knowledge dependency system.
Context should be treated like mission-critical code. With an explicit lifecycle of Owners, Reviews, Versions and Releases
“Owners review versions of knowledge to cut releases”
Some context you build ahead of when you use it. This is buildtime context and it is where you apply the lifecycle the most.
Other context you fetch when you need it, usually from a system of record like your CRM or a product database. This is runtime context, and the core thing here is unified auth to unblock your team so they can get the context they need directly in their agents.
“How do I keep my context accurate and up to date?”
Context has a shelf-life
Context will become out of date over time.
That’s why you version it and have a release cycle, so you can see how it changes and evolves over time.
Context copied drifts like any other copy of a copy in the universe.
You need to proofread the copies at copy time to prevent copy errors from compounding.
Know someone who is struggling with context engineering in their org? Send them this (its free :)
Before I dive into those questions in full, I need to introduce a distinction. It helps us understand what types of context we are working with:
Buildtime context vs Runtime context.
Runtime and Buildtime. What does that mean?
In software when something is build time, you build it before you need it. To deploy an app to a hosting platform you gotta build it. Literally:
npm run build And that’s your app assembled.
Runtime is the opposite. You get it when you need it. As your app is running. So runtime context is context you get on the fly as you need it.
An example of this is having Claude go talk to your CRM, review the numbers and synthesize it into a report on your pipeline.
Usually it is an agent fetching structured/tabular (stored in a database) and synthesizing it into plain English context.
Buildtime is your collective wisdom about who you are, what you do, and why. Here’s a framework on how to think about the two:
So the approach we use to create and maintain buildtime context is very different from how you handle runtime context.
You should think of buildtime context as more as a distinct operational workflow while runtime is closer to “how and to what ends should we get an AI-first internal Google working.”
When do I split things up? How do I organize for best performance? What happens when my context changes?”
A context graph, LLM wiki, context OS. Whatever you call it, a standard around markdown + yaml has emerged for creating an internal knowledge base and SKILLS
As these systems grow, they start to become harder to work with.
Search takes longer and is less accurate (bigger body of work to search across)
Some parts get out of date faster than others. Some slower. How do you account for these different rates of change?
How do you even see this happening?
TL:DR Best current approach: Break it down, formalize what is already working, and automate the overhead.
Try spinning out context into sub-folders and repositories earlier than you think and then test the difference in how well your agent performs.
If you’re already trying to figure out collaboration with multiple people you need a process. The most basic is this:
“Owners review versions that get cut into releases”
Owners: every package has a name on it
Reviews: someone reads it before the company depends on it
Versions and releases: “ready for everyone” is a decision, not a save button
I borrowed this from software engineering development lifecycles. Mission-critical code has a lifecycle to it because of how important it is.
Now context is mission critical itself, and will only become more important the more AI workstreams you stand up.
Runtime is closer to being immediately a “solved problem” since for most use cases the systems of record provide connectors for your agents.
What I’ve found is the huge unlock is making sure there is a unified permissioning and authentication layer.
Team members shouldn’t have to beg to get access to tools they already use inside of their agents.
Because if team members feel like the authorized way of getting mission critical context into their agents doesn’t work, you will very quickly get two things:
Shadow AI (shadow IT’s ugly probabilistic cousin): People using personal AI accounts and copy pasting into them. Not good.
Using the wrong context system to solve their problem: One time I had a client sales team member ask how many opportunities had happened that week and the agent, since it did not have proper CRM access, confidently responded by counting call transcripts and got it entirely wrong.
There are a variety of ways to go about this, and most of this is a boring conversation about what your org needs in regard to security/authentication which will vary from org to org.
My general recommendation is to have your engineers, or a consultant like me, design the auth system that rolls up all your tools into a single permission grant.
This roll up lets your team get the context each of them should have access to just by logging in with their company account.
Context has a shelf-life. The same way your beliefs evolve and change as you learn, your context will change over time - since it is a reflection of such belief.
Ultimately context is kinda like a story, a moving timelapse made up of a series of snapshots.
Your team members and their agent need to be able to see how the story has changed over time if they are to use it for anything.
The better you can tell your story the more quickly others can understand it and take action on it.
The consumers of your context (aka story need to be able to depend on it) - it needs to be the canon version of the story not a WIP that you’re just riffing on.
This is even more important for agent consumption of context, since your AI is only as good as the context you give it.
When a gap emerges between what you know to be true and what your context says, you’ve got context decay.
The best fix is the versioning process from above: package context by how often it needs review, and cut releases on that cadence.
There is a second type of context behavior that is mechanical, structurally guaranteed to happen. Context drift.
Context drift is what happens when you make a copy of a copy. Between each copy mistakes build up.
A simple analogy to use here is Telephone. You know the game where you stand in a line with your friends and try to whisper a word from one end to the other?
The word may start as “red pufferfish” but by the very end of line the person said they heard “bed covering and dish”
red -> bed
puffer -> cover --> covering
fish -> dish Here’s another way to visualize it:
It is easy for things to get lost in translation, and in copying. But biology has already given us a solution to this problem. Check the copy as you copy it.
Right now, there are hundreds of billions of cells copying themselves in your body. As you read this. The overwhelming majority of them do so without error. This is because during the DNA copying process, your body proofreads the DNA.
It does not retroactively check the copy, since that would mean copying errors are inherited and compounded down through cell generations.
It proofreads during the copying process.
You will never have a perfect copy, so accept good enough for us to ship. Technically this looks like:
Start with 2x more thought out and specific context than you think. You need unreasonable clarity at the source since that is the highest leverage point you will ever get.
Versioning still helps here. One version of your positioning doc is a snapshot. The chain of snapshots is the story which you can use to iterate and make changes more specifically since the agent can see the chain as well.
Enforce citations and trace the citation chain. Every doc and claim must cite its source. Then you can use simple script to walk through all the chains all the way back to the source claim. This is dumb but reliable backbone.
Use agents to check other agent’s work. Verify adversarially. Do the source and full chain actually say what you think it says? Meaning is different from the existence of an unbroken citation chain.
AI really just amplifies whatever you give it. A clear goal and roadmap YOU understand can be amplified into completed execution using AI but a blurry half complete vision amplifies into slop.
If you can do all of the above well, you should have a dependable knowledge infrastructure and the in-house know-how to run it - enabling faster shipping across every domain.
Collective wisdom made installable.
I’ve decided I will no longer let myself negotiate on when to publish or what to publish. Here’s my new schedule:
Weekly Free:
context engineering office hours every Thurs or Friday. Link for this week here.
one deep dive post (this one)
one interactive tool or deck (this is what I prep for office hours, if you can’t make it you can still find it here)
Daily Free:
Context Engineering Intelligence Brief
Context Engineering Intelligence Context Graph accessible via API/MCP
Weekly Paid:
Full office hours recording
Private Context Library
my internal context engineering graph and my production SKILL.mds
Office hours Context Graph accessible via API/MCP
vetted high signal context sharing marketplace
Early Access to test new AI and context engineering tooling
Notice the paid stuff? Yeah that isn’t really launched yet :) but if you are interested in getting purchasing as a beta tester send me a message.
Thanks for reading! I appreciate you being here.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.