Last month a founder in our network asked me to look at how they were using Claude across their team of 22 people. They had the enterprise plan. They had enthusiastic people. They had budget. And every single output looked like it could have been written by anyone, about any company, in any industry.
The problem wasn’t the tool. It wasn’t the prompts. It was that their AI knew absolutely nothing about their business.
Every conversation started from zero. Every time someone on the team opened Claude, they were talking to a stranger. No memory of how this company makes decisions. No understanding of their terminology. No awareness of what they’d tried before and why it failed. The AI was fast, articulate, and completely generic.
This is where most organisations are right now. And there’s a term for the fix that’s starting to gain serious traction: context engineering.
The shift from prompt engineering to context engineering
For the past two years, the advice has been “get better at prompting.” Write clearer instructions. Be more specific. Learn the tricks. That advice wasn’t wrong, but it was incomplete. It was like telling someone to communicate better with their new hire while never actually onboarding them.
What’s changing in 2026 is the recognition that the quality of AI output is determined less by how you ask and more by what the AI already knows before you ask. Anthropic has named this directly. The organisations getting real value from AI are the ones that have built a structured knowledge layer their AI can draw on.
This isn’t a technical concept. It’s an organisational one. And once you see it, you can’t unsee it.
What a context layer actually is
Think about what you give a new hire in their first month. The company handbook. The org chart. The way decisions get made. The terminology that means something specific internally but sounds generic externally. The processes that exist in people’s heads but have never been written down.
A context layer is all of that, structured so AI can use it.
Not a dump of documents. Not a link to your Google Drive. A deliberately organised collection of how your company works, what it values, how it makes decisions, and what conventions it follows.
At The Delta, ours lives in a GitHub repository. Markdown files, version controlled, organised by domain. How we evaluate ventures. How our network operates. Our terminology. Our tone of voice. Our decision frameworks. Everything an AI system would need to know to be useful to any team member, without that team member having to explain the company from scratch every time.
The first time we tested it, the difference was immediate. Outputs went from “plausible but generic” to “this sounds like it was written by someone who works here.” That shift happened in a single session, just by giving the AI access to structured context.
Why your wiki isn’t the same thing
Most companies already have some version of their knowledge documented. Notion pages. Confluence spaces. Google Docs folders. So the instinct is: great, we’ll just point AI at what we already have.
It doesn’t work that way.
A wiki built for humans is designed to be navigated. People search, click around, read the bits they need. The structure assumes a human brain doing the filtering.
AI needs something different. It needs information that is consistent in format, specific in language, and structured so that relevant context can be pulled in automatically. Human wikis are full of contradictions, outdated pages, informal language, and implicit knowledge that makes perfect sense to a person with context but is meaningless to a machine.
The gap between “we have documentation” and “we have documentation AI can use” is bigger than most teams expect. Closing it is the actual work.
Five ways to build it
There’s no single right approach, but I see five options playing out across the companies we work with. They range from low-effort to genuinely powerful, and the right choice depends on where you are right now.
Option one: structured Google Drive or Notion. Lowest effort. You reorganise what you already have into a consistent format, tag it properly, and connect it to your AI tool via an integration. It’s better than nothing, but the AI-readability ceiling is low. Good enough to start. Not good enough to stay.
Option two: a dedicated wiki with structured tagging. More deliberate. You build a knowledge base specifically designed to serve both humans and AI, with consistent formatting, clear categories, and a maintenance rhythm. This works well for teams that already have strong documentation habits.
Option three: a markdown repository. This is what we use at The Delta itself. Plain text files in a structured folder hierarchy, stored in GitHub. High AI-readability because the format is clean and consistent. Version controlled so you can see what changed and when. The downside is that it requires some comfort with developer tools, or at least someone on the team who can set it up. For us, it works because our team is technical enough to live in GitHub and we need the auditability that comes with pull requests and branch-based workflows. Every change to our context layer is reviewed and tracked.
Option four: a graph-based knowledge base. This is what we’ve been rolling out with ventures in our ecosystem, and it’s a meaningful step up from flat files. We use Obsidian, which stores everything as markdown but adds something critical: linked relationships between notes.
Here’s why that matters. A flat knowledge base tells AI that you have a venture evaluation process and that you have a list of portfolio companies. A graph-based one tells AI that this specific evaluation process was used on this specific company, which is connected to this partner, who operates in this market. The relationships are the context. They’re what lets AI reason about your business the way a senior team member would, not just retrieving information but understanding how things connect.
Obsidian is particularly good for this because the files are still plain markdown, so AI can read them natively. But the backlinks and tags create a relationship layer on top that turns isolated documents into a connected map of how your organisation actually works. When AI can traverse those connections, the quality of output jumps noticeably. It stops giving you answers that are technically correct but miss the bigger picture.
The trade-off is that building a well-linked vault takes more upfront thinking than dumping files into folders. You need to be intentional about what links to what. But once it’s in place, it compounds faster than any flat structure because every new note automatically enriches the context around everything it connects to. For less technical teams, this is often the strongest option because the tooling is visual and the learning curve is gentler than GitHub.
Option five: an MCP server. The most powerful option, and the one that changes the game entirely. MCP (Model Context Protocol) lets you build a direct connection between your AI tools and your internal systems. Your AI doesn’t just read static files. It can query live data, access current information, and pull context dynamically.
But here’s what makes MCP different from the other options: it’s not just about feeding context in. It’s about letting all your AI tools interact with your knowledge layer. Your AI can read from it, write to it, search it, and act on it. It becomes a living system that your AI agents work with, not just a reference library they consult. This requires a technical resource to build, but the result is AI that always has current, relevant context without anyone manually updating documents.
For most organisations starting out, the honest advice is: just start getting your company’s knowledge into some form of structured markdown. Don’t overthink the tooling. Pick whatever your team will actually use and maintain. The format matters less than the act of doing it. The moment your company’s knowledge exists in a clean, structured, machine-readable form, every AI tool you use gets dramatically more powerful. That’s the shift. Options one and two get you moving. Options three through five get you serious. Option six is where you go when you’re ready to build AI systems that genuinely operate on behalf of your team.
The insight nobody expects
Here’s what surprised us at The Delta. The most valuable thing about building our context layer wasn’t the AI improvement. It was the process itself.
When you sit down to codify how your company actually works, you discover how much exists only in people’s heads. Processes that three people describe differently. Terminology that means one thing to the ops team and something else to the commercial team. Decision frameworks that everyone thinks they follow but nobody has ever written down.
The act of building a context layer forces clarity. It surfaces disagreements you didn’t know existed. It reveals the gap between how you think your company operates and how it actually does.
We found three separate conflicting definitions for how we evaluate ventures. Three. Each one made sense to the person using it. None of them were documented. The AI project forced us to pick one and write it down. That alone was worth the exercise.
Context decay is the thing nobody plans for
Building the context layer is the exciting part. Maintaining it is where most teams fail.
Companies change. Teams grow. Decisions get revised. The terminology you defined in January doesn’t quite fit by June. The process you documented gets improved but the documentation stays the same.
If your context layer goes stale, your AI starts giving confident answers based on outdated information. That’s worse than having no context at all, because your team will trust it.
You need a maintenance rhythm. At The Delta, we review ours monthly. It’s not glamorous work. But it’s the difference between a context layer that compounds in value and one that quietly becomes a liability.
Where to start
If this feels like a large project, it doesn’t have to be. Here’s what I’d suggest.
Pick one domain. Not your entire company. One area. How you evaluate partnerships. How you onboard new clients. How your sales process works. Whatever is clearest in your head.
Document it in full. Write it in a structured format. Be specific. Include the criteria, the steps, the edge cases, the things you’d explain to a smart new hire on their first day.
Then test it. Give that context to Claude or whatever AI tool you’re using. Ask it to do something in that domain, once without the context and once with it. The difference in output quality will tell you everything you need to know about whether this is worth pursuing further.
I already know what the answer will be.
Written by Alexandra Matthews
Chief Operating Officer
