It’s been a while since our last post — this summer has been truly busy so far, in a good way, and I’m excited to share more thinking on AI at scale. Here goes the first in a series that I hope will resonate with anyone determined to make good on their AI goals in H2.
Somewhere in your company there is a person who has become genuinely excellent with AI. They have a system. They know which tasks to hand off and which to keep, they have built up a working sense of what the model does well, and they have quietly gotten faster at their job than anyone expected. You probably know who they are.
Now ask a harder question. If that person left tomorrow, what would your organization keep?
The honest answer, for most teams, is almost nothing. And that gap, between what individuals have learned and what the organization actually retains, is the single most useful thing to understand about where AI adoption stands right now.
📊 The number worth sitting with
88% of organizations have adopted AI tools. Roughly 6% report capturing significant value from them. That spread has been remarkably stable across surveys for a year and a half now, which is itself interesting. If this were a technology problem, you would expect the number to move as the technology improved. And the technology improved enormously. Every model got better this year. The gap did not close.
That stability tells you something. Whatever separates the 6% from the 88%, it is not model capability, because everyone has access to the same models. It is not tool access, because everyone bought the same licenses. Something else is going on, and most leaders I talk to can feel it without quite being able to name it.
Here is the sensation, as it usually gets described to me. We are eighteen months and real money into this. Individual people are clearly faster. Nobody can point to where the organization got better. The pilots worked, the rollout happened, and yet if you zoom out to the level of the company, the picture is oddly flat.
That is not a failure of adoption. Adoption worked. That is a failure of accumulation.
What is actually in the gap
When I go looking at what teams are doing day to day, the same three things turn up almost every time.
The first is that 77% of people manually re-upload the same context every session. They paste the brand guidelines in again. They re-explain the customer segment again. They drag in the same three documents they dragged in yesterday, because the model does not remember and the tool does not persist. This gets described as AI adoption. It is closer to AI admin. Every session begins by paying the same tax, and the tax never gets cheaper, because nothing is being built up.
The second is fragmentation. Three departments have each developed a way of working with AI, and none of them know what the others figured out. Marketing built a prompt library. The product team has a shared doc of what works. Someone in ops has a genuinely clever workflow that nobody outside ops has ever seen. These are real assets, and they are stranded. The organization paid for all three and owns none of them, in any usable sense.
The third is the one nobody likes to look at. The knowledge lives in people's heads. Not in a system, not in a file, not anywhere that survives a departure or a reorg or a role change. Every time someone leaves, the clock resets for whoever picks up their work. You are not compounding. You are re-teaching.
Put those together and the 88/6 spread stops looking mysterious. The 88% bought tools. The 6% built something underneath them.
🧠 The layer nobody bought
Here is the thing I keep coming back to, and it took me an embarrassingly long time to say it plainly.
Your AI does not know how your organization works.
It knows how the world works. It has read more than any of us. What it does not know is what "done" looks like at your company, which trade-offs you have already litigated and settled, why the thing that seems obviously correct is actually wrong here for a reason a competitor learned the hard way in 2023. It does not know your definition of a good brief, a good spec, a good customer email. It does not know which of your six databases is the one people actually trust.
That knowledge exists. It is just not written anywhere the AI can reach. It is distributed across the heads of your best people, and the only way it currently enters an AI conversation is when one of those people types it in by hand, from memory, one session at a time.
The thing that closes the gap is the thing that captures that knowledge and makes it available to every person and every agent, every time, without anyone re-typing it. I have started calling it the Organizational Context Layer, because it needs a name and "shared knowledge infrastructure your team's AI runs on" does not fit on a slide.
The name matters less than the shape. It is not a tool you buy. It is not a chatbot, it is not a wiki, and it is emphatically not a folder of PDFs. It is a maintained, structured, opinionated body of context about how your organization actually works, sitting underneath the AI tools you already have. Without it, every AI interaction starts from zero. With it, the interactions compound, because each one starts from everything the organization has already figured out.
That word, compound, is the whole argument. It is also the diagnostic.
Where teams actually are
Most conversations about AI maturity are useless because they measure the wrong axis. They ask how much AI you are using. The more revealing question is who benefits when someone gets good at it. Run your own team against this and the answer tends to arrive uncomfortably fast.
Level 1. Individual prompts, no persistence. People type into a chat window and get useful answers. The benefit accrues to the person typing, and it evaporates when they close the tab. Most companies that describe themselves as "using AI" are here, and the reason it is hard to see is that nothing looks broken. The outputs are good. People are happy. The useful diagnostic at this level is not how much anyone is using the thing, because usage will look excellent. It is whether two people asking the same question about your business get the same answer. They do not, and structurally they cannot, because the only context in the room is whatever each person happened to remember to type that morning. What gets described as a tooling rollout is closer to a few hundred people independently reconstructing an explanation of the company from memory, at slightly different levels of accuracy, every single day.
Level 2. Personal context systems. Someone builds themselves a real setup. Saved prompts, a context file, a repeatable workflow, a folder the model can be pointed at. This is a genuine step up and it is where your power users live. The benefit still accrues to exactly one human: the one who built the files. What makes level 2 genuinely deceptive is that it produces the most impressive AI results anyone in the building has seen, which is precisely why it gets mistaken for organizational maturity. The tell is where the files live. If the context that makes someone excellent sits in their personal drive, on their laptop, or in a repo only they push to, the organization does not own it, and the fact that they are generous with it in Slack does not change that arithmetic. It changes who has to ask, and how often.
The best public example of level 2 done properly is Teresa Torres, who has documented her Claude Code and Obsidian setup in unusual detail. A vault of dozens of small, focused context files. A three layer structure running from global rules down to project rules down to individual reference files. A morning command that assembles her day. The craft in it is real, and her central principle, that you feed the model small curated context rather than large documents, is something most organizations have not worked out yet. It is also, in her own framing, a personal operating system, and that word is carrying more weight than it looks like it is. The sophistication of a level 2 system is not what moves it up the ladder. The ceiling is not made of craft. It is made of scope.
Level 3. Retrieval layers. The company buys something like Glean or Cassidy and points it at the document store. Now AI can search everything you have written. This feels like the answer, and it is a real improvement, but notice what it optimizes: the retrieval system gets better at finding documents. Whether those documents contain the reasoning anyone needs is a separate question, and usually the answer is no. A five thousand word strategy deck is not context. A three hundred word synthesis of what that deck actually decided is context. Retrieval gives you the deck.
The distinction matters more than it sounds, because your documents mostly record conclusions and almost never record the reasoning that produced them. The deck says the Q3 push is mobile first. It does not say that the team spent six weeks arguing about it, that the deciding factor was a support cost curve nobody put on a slide, or that the same proposal was rejected twice before for reasons that still apply. A person who was in the room carries all of that. The retrieval system has never seen any of it, because it was never written down anywhere retrievable.
There is a second problem, which is that retrieval tends to assume more context is better, and it is not. Feeding a model a large pile of loosely relevant documents measurably degrades both speed and accuracy relative to a small curated set. So the honest test of a level 3 system is not whether it can find the document. It is whether it can answer a question whose answer lives in a decision rather than a file. Ask it why something is the way it is. Retrieval will hand you the deck, confidently, and the deck will not say.
Level 4. Agent-first context platforms. Tools like Dust let you stand up agents that carry context into discrete tasks. This is genuinely useful and it is where the more advanced teams are experimenting. The benefit accrues to the agent, task by task. It is still not organizational memory, it is task memory, and when the task ends the memory does too. The subtler issue is where the agent's context came from in the first place, which is almost always one person's understanding of how the work should go, typed in during setup and then frozen.
That is fine until you have a dozen agents, at which point you have a dozen private theories of the company running in parallel, configured by different people at different times against different assumptions. Two of them will contradict each other on something that matters, and nobody will notice, because agents do not compare notes. The individual failure mode of level 2 has not been solved here. It has been automated and given a login.
Level 5. Team-scoped context infrastructure. The context is a shared, maintained artifact. It is versioned. It has owners. When someone learns something that changes how the work should be done, they update the layer, and from that moment every person and every agent working from it is operating on the improvement. The benefit accrues to the team, which means it accrues to the company, which means it survives the departure.
Three properties do the work here, and none of them are technical. The layer has an owner, so when it goes stale it is somebody's job rather than everybody's disappointment. It has a path in, so when someone discovers that the model keeps getting the pricing logic wrong there is an obvious place for that correction to land and a person who reviews it. And it is small, because it is synthesis rather than archive.
The diagram below is our actual setup for Summer Friday & Partners: five agents, a context layer underneath them. Some agents like Writer and Delivery Agent are team-scoped - team members can interact with it via Slack. Others like Finance and Biz Dev are personally-scoped and owned by me.
The honest tell for level 5 is what happens the week after someone learns something. At every level below, the learning stays with the learner and the organization re-learns it later at full price. At level 5 it lands in the layer, and the next person to ask never knows there was a lesson.
Level 5 is where the 6% are. There is no shortcut from 1 to 5, but there is a much shorter path than most people assume, and it does not start with buying anything.
💡 The compounding question
If you take one thing from this, make it this question, because you can ask it on Monday and the answer will tell you where you actually stand.
Is our AI investment compounding, or depreciating?
A compounding investment gets more valuable every week without additional spend, because the context underneath it keeps getting richer. The team learns something, the layer absorbs it, and every future interaction inherits it. The asset grows while you sleep.
A depreciating investment requires the same effort next week that it required this week, and produces roughly the same result. You are paying a subscription for a tool that starts from zero every single morning. That is not an investment. That is a utility bill, and a surprisingly expensive one.
Most teams cannot answer the question, and I have come to think the inability to answer it is the finding. If nobody can tell you whether the thing is compounding, it is not. Compounding is visible. You can feel it. Work that took a full afternoon in January takes twenty minutes in July, not because the model got better, but because the AI now knows the fourteen things about your business that used to require explaining.
The teams in the 6% did not get there by being early, or by having better models, or by hiring differently. They got there by treating organizational knowledge as infrastructure rather than as a byproduct. Which is, when you say it out loud, just a rediscovery of something companies used to know before we all decided that knowledge management was a dirty phrase.
What is coming
This is the first of six issues, and they build. Over the series we are going to construct an Organizational Context Layer, piece by piece, in enough detail that you could stand one up yourself. Not a framework. Not a maturity model to put in a deck. An actual working system, with the specific decisions, the specific structure, and the specific failure modes I keep watching teams walk into.
Next week: what changes when context stops being a personal asset and becomes a shared one. The move from single player to multiplayer sounds simple and is not, because the moment two people are editing the same context, you inherit every problem that software teams solved with version control and most companies have never had to think about.
What are you seeing in your own team? If you have a person who has quietly gotten great at this, I would genuinely like to know whether any of what they learned has made it out of their head. Reply and tell me. The honest answers are usually the interesting ones.
Jon