Last week we named the gap. 88% of organizations have adopted AI. 6% say it’s delivering real value. The difference isn’t the model. It’s what the model knows about how your organization actually works.

We called this the Organizational Context Layer, the shared knowledge infrastructure your team’s AI runs on. Without it, your AI investment is depreciating. Every conversation starts from zero. Every new hire rebuilds the same context. Every agent you deploy is flying blind.

This week: the first architecture decision. You’ve probably already built a context layer that works for you. The question is how to make it work for your team.

It’s harder than it sounds. Not for technical reasons. For political ones.

The Multiplayer Problem

Individual context is easy. You write down how you work, what you’re trying to accomplish, what you care about. One person, one source of truth. The AI learns your patterns and gets better over time.

Team context is a different problem entirely.

The moment you share context across a team, you have a merge problem. Not in the technical sense, though that’s real too, but in the organizational sense. Two people’s understanding of what a project is trying to accomplish might be genuinely incompatible. Not wrong, exactly. Just different. And when you encode one person’s understanding as the team’s canonical context, you’ve made a political decision whether you meant to or not.

AI knowledge work is more like Git than Google Docs. In Google Docs, five people can edit simultaneously and the worst outcome is a mess you can clean up. In a context layer, conflicts aren’t cosmetic. They’re semantic. You can’t merge two contradictory beliefs about what the team is trying to do. Someone has to decide.

Before you solve the technical question of how to share context, you need to answer the organizational question: who has the authority to declare something the team’s truth?

Most teams skip this. They go straight to tooling and then wonder why adoption stalls. The tooling isn’t the problem. The governance is.

Three Tiers of Shared Context

Not every team needs the same architecture. We identify at least three tiers, and most teams will use a combination of all these. They’re not mutually exclusive. Start where your team is and layer up.

Tier 1: Shared AI Workspaces

No technical setup required. Claude Team Projects, shared prompt libraries, a documented set of system instructions everyone uses. This is a massive upgrade over “everyone has their own ChatGPT history.” The context isn’t persistent across tools, but it’s consistent across people.

Here’s what this actually looks like. Say you run a six-person marketing team. Today each person has their own chat history, their own way of asking for a first draft, their own private set of tricks for getting the tone right. So you create one Claude Team Project. Into it goes the brand voice guide, the positioning doc everyone keeps arguing about, a short file explaining what the team is actually trying to accomplish this quarter, and the four prompts that reliably work. Nobody writes code. Nobody files a ticket. Now all six people are producing drafts that sound like they came from the same organization, because for the first time they’re all starting from the same page.

Best for. Teams that have no shared AI context at all, which is most teams. It’s also the right call for non-technical groups, and for any org that wants to test whether shared context actually changes anything before committing budget and headcount to infrastructure. If you can’t articulate what your team’s AI should know, Tier 1 is where you find out. The exercise of writing the workspace instructions is most of the value; the tooling is almost incidental.

Technical lift. Near zero, and that’s the entire argument for it. No integration, no configuration, no engineer required, no security review. The real cost isn’t technical at all. It’s the two or three hours someone has to spend deciding what goes in the workspace and writing it down clearly. That person needs enough authority that their decisions stick, which is the first small taste of the governance problem you’ll meet properly in Tier 3.

Control. Low, and you should be clear-eyed about what that means. You can’t query this context programmatically. You can’t version it or see who changed what. You can’t point an agent at it. When it drifts out of date, nothing tells you. You find out because the outputs quietly get worse. It’s a document that happens to live where the AI can read it, and that’s the ceiling.

Limitation. The context lives in the tool, not in your organization. If you switch vendors, or the vendor changes how projects work, or the team decides to standardize on something else, you start over. You’re also capped at what fits in a project’s instructions, and this doesn’t scale to the full body of what your org knows. Tier 1 makes your team consistent across people. It does not make your context persistent across tools. Those are different problems, and only one of them is solved here.

Tier 2: Connected Tools via MCP

Wire your AI into where your team already works. Your Notion wiki, your Google Docs, your internal knowledge base becomes a live knowledge source that any AI tool can read from. No more copy-pasting context into every conversation. The AI can look things up.

A concrete version. A consulting team keeps everything in Notion: client pages, project briefs, the running strategy doc, meeting notes going back two years. Before MCP, using any of that with AI meant someone opening the right page, copying the relevant part, and pasting it into a chat, every single time. After MCP, the AI queries Notion directly. Ask it to draft a status update for a client and it looks up that client’s page, reads the last three meeting notes, and writes from what’s actually there. The knowledge didn’t move. The AI just learned how to reach it.

You don’t have to wire this up yourself, either. A whole category of platforms now exists to do it for you. Dust and Cassidy both connect to the tools your team already lives in (Notion, Slack, Drive, Confluence, GitHub, dozens more) and let people build agents on top of that shared knowledge without writing code. Dust describes its product as multiplayer AI, which is the same problem this newsletter opened with, arriving from the vendor side.

And it’s worth noticing what that category’s marketing quietly concedes. Dust sells a semantic layer that synthesizes your company’s knowledge so agents understand it rather than merely retrieve it. Cassidy pitches a knowledge base that pulls your documents and tools into a single source of truth. Both are selling the gap between having your documents and having your understanding, which is a tacit admission that plugging AI into your docs was never going to be sufficient on its own. That distinction is doing enormous work in those sentences, and it’s the one worth drawing carefully.

Best for. Teams that already have a knowledge base they genuinely maintain. Emphasis on genuinely. If your wiki is current because people actually use it to do their jobs, MCP turns an asset you already paid for into an AI-readable one. If your wiki is a graveyard of half-finished pages from 2023, connecting it makes things worse, not better, because now the AI confidently cites the graveyard.

Technical lift. Moderate. MCP servers exist for most of the tools you already use, so this is configuration rather than custom code. But it’s configuration with teeth: you’re deciding what the AI can read, under whose credentials, and with what permissions. That’s a real conversation with whoever owns security, and it’s the first point where “who has access to what” stops being abstract.

Control. Medium, and meaningfully better than Tier 1. Context is queryable, it lives in your systems rather than a vendor’s, and you can point agents at it. Switch AI tools and your knowledge stays put. You reconnect rather than rebuild. That portability is the real prize here, more than the convenience.

Limitation. This is where I want to be blunt, because Tier 2 gets oversold.

The obvious problem is quality. Your AI context is exactly as good as your docs, and MCP just makes bad docs arrive faster. Garbage in, garbage out, now with a live connection.

The less obvious problem is latency. Every lookup is a round trip. The AI queries the tool, waits, gets a response, maybe queries again because the first result wasn’t quite right. What felt instant in a chat window starts to feel like waiting, and it compounds badly when an agent chains several lookups to answer one question. Retrieval isn’t free, and the cost shows up exactly where users notice it.

But the real limitation is conceptual, and it’s the one most teams miss. MCP on its own is retrieval, not context engineering. It grabs what already exists. It doesn’t decide what matters, resolve contradictions between two docs that disagree, or compress five thousand words of meeting notes into the three sentences that actually inform the decision. Connecting your wiki gives the AI access to your organization’s raw material. It does not give the AI your organization’s understanding. Those are different things, and the gap between them is precisely the work. A 300-word synthesized context file will beat a live connection to a 5,000-word document dump nearly every time, because someone did the thinking.

So MCP has a real place. Pure retrieval is genuinely useful when the source is current and the question is factual.

Tier 3: Context as Code

This is the tier that needs the most explaining, because the name sounds like a tooling choice and it isn’t.

“Context as code” means you treat what your organization knows the same way engineering treats what its software does: as versioned files, changed deliberately, reviewed before they take effect, with a permanent record of who changed what and why. The knowledge lives in a repository. It’s written in plain text, usually Markdown, so anyone can read it. And critically, it changes through a workflow rather than through someone just editing it.

If you’ve never worked in a Git repo, here’s the whole model in one paragraph, and you can ignore the vocabulary after this. Nobody edits the shared truth directly. You take a copy (a branch), make your change there, and open a pull request, a proposal that says “here’s what I think should change, and why.” Someone else reads it, argues if they disagree, and eventually it gets merged into the canonical version everyone else uses. Every change is a discrete, attributed, reversible event. If a change turns out to be wrong, you roll back to the version before it. That’s it. That’s the entire mechanism, and it’s been the backbone of how software teams manage versioning for the past two decades.

What does this look like in practice? A team running client engagements keeps a context repo with a handful of files, for example: context/goals.md (evergreen strategy), context/how-we-decide.md (how pricing and scoping calls actually get made), context/project-atlas.md (the live state of one engagement). Just examples. The shape can vary widely. When the pricing approach changes after a bad quarter, someone doesn’t just “update the doc.” They open a pull request, and it gets merged. Every agent and every workspace that reads that file now behaves differently, immediately, and there’s a permanent record of when the thinking changed and who changed it.

That brings in a few ideas worth naming, because once context is shared they stop being theoretical.

Canonical source of truth is the single place a claim officially lives. Not the most recent Slack message about it, not the version in someone’s deck. It’s the one that wins when versions conflict. Most orgs have never designated one, which is why the same question gets four confident answers.

Freshness is whether a piece of context is still true. Context rots silently. A strategy file written in January describes a company that may not exist in June, and the AI has no way to know. It will cite the stale file with exactly as much confidence as the current one. Anything shared needs a story for how it gets reviewed and retired.

Provenance is where a claim came from and who stands behind it. When AI hands you a recommendation built on your context layer, provenance is what lets you audit the reasoning back to a source and a person. Without it you get plausible answers you can’t verify, which is worse than no answer, because you’ll act on it.

Git gives you these as a byproduct of what it does. It actually provides accountability and traceability.

Best for. Engineering-heavy teams, obviously, since the workflow is already muscle memory. But the sharper test is whether your context is load-bearing. Borrowed from structural engineering: a load-bearing wall is one the building falls down without. Context is load-bearing when something real breaks if it’s wrong: an agent quotes a client the old rate, a pricing decision routes through outdated logic, a compliance answer cites a policy you retired last quarter. If bad context produces an awkward first draft, you don’t need Tier 3. If bad context produces a bad decision that reaches a customer, you do. Autonomous agents move you across this line faster than almost anything else, because nobody is reading the output before it acts.

Technical lift. High. Someone has to own the architecture: the file structure, the review conventions, how context gets deployed to the tools that consume it. Non-engineers need to learn enough of the workflow to contribute, and that’s a genuine ask. Realistically you need one person who cares about this and has time for it. Without that owner, the repo becomes another graveyard, just one with better version history.

Control. Maximum, and it’s the only tier that gives you real answers to the hard questions. Write access is a permission you grant, not a norm you hope holds. Disagreement happens in a pull request, in the open, and resolves in a decision with a name attached. When something goes wrong you can see exactly which change caused it and undo it. History, branching, review, rollback. These aren’t engineering luxuries. They’re how you make context accountable.

Limitation. The process overhead is real and it is not free. Every change costs a review cycle. For fast-moving or low-stakes context, that friction is worse than the drift it prevents, and teams route around it, which is how you end up with a pristine repo nobody reads and the real context back in DMs. It’s also genuinely overkill for teams without technical appetite. Don’t adopt Tier 3 to look serious.

And here’s the part most teams underestimate: the technical jump is the easy half. The organizational jump is harder. The moment you put context under review, you’ve made explicit something most orgs prefer to leave vague: who decides what’s true here. Tier 1 lets ambiguity survive because nobody’s claim is canonical. Tier 3 forces the question, because a merge is a decision and someone has to make it. That’s not a downside. It’s the point. But it means Tier 3 fails for political reasons far more often than technical ones, and if your org can’t name who owns a domain’s truth, no amount of Git will save you.

How to Choose (And Why You’ll Probably Use All Three)

The honest answer: most mature teams run all three tiers simultaneously. Tier 1 for quick team alignment and onboarding. Tier 2 for agents that need live organizational knowledge. Tier 3 for the critical context that can’t afford to drift or be ambiguous.

The question isn’t which tier to pick. It’s where to start and how to sequence. Use these to decide:

• Start with Tier 1 if: your team has no shared AI context at all. Even a shared prompt library is better than 12 people running their own ad hoc setups. Get consistent before you get sophisticated.
• Move to Tier 2 if: you already have an internal wiki or knowledge base your team actually uses. The docs are there. Connect them. MCP makes this tractable without a major engineering lift.
• Add Tier 3 if: you’re deploying autonomous agents, your context is load-bearing (wrong context = costly mistakes), or you need full audit trail and rollback. The Git model isn’t about technical sophistication. It’s about treating context with the same seriousness as code.

A practical starting sequence for most teams: Tier 1 now (this week), Tier 2 within 90 days once your wiki/docs are solid, Tier 3 when you’re running agents that make real decisions.

The worst outcome isn’t choosing the wrong tier. It’s everyone running their own ad hoc context with no shared infrastructure. That’s where drift happens, and drift is how your AI investment depreciates.

The Hard Questions to Answer First

Before you choose a tier or pick a tool, work through these with your team:

• Who has write access to the shared context layer, and who only has read access?
• Whose worldview gets encoded as canonical when there’s genuine disagreement about strategy or direction?
• How do you review and update the context layer as the team’s work evolves? Who owns that process?
• What happens when a key contributor leaves? Is their knowledge in the layer or still in their head?

These aren’t one-time questions. They’re ongoing governance. The teams that get this right treat the context layer like any other piece of critical infrastructure, with ownership, maintenance, and intentional contribution.

How You Know It’s Working

Three signals that your shared context layer is actually doing its job:

1. A new hire uses your team’s AI tools and gets 80% quality output in their first week. Not because they’re exceptional. It’s because the context is already there.
2. When someone leaves, their replacement doesn’t start from zero. The institutional knowledge didn’t walk out the door with them.
3. AI outputs get measurably better over time without retraining. The model hasn’t changed. The context layer has grown.

If none of these are true yet, the layer isn’t working, or doesn’t exist. Both are fixable.

Where to Start

This week, one exercise: pick the single most important thing your team’s AI should know that it currently doesn’t. Write it down in two paragraphs. That’s your first contribution to a shared context layer.

It doesn’t have to be in a tool yet. It just has to exist somewhere other than your head.

Until next time, stay cool out there this summer,

Jon