Organizational Context Systems

This is a playbook for building team AI context systems, written for operators who want to make AI perform better for their organizations. It contains frameworks and best practices drawn from Revi Systems and leading AI Operations experts.

If you’re an operator and you’ve deployed AI tools like Claude, ChatGPT, Gemini, or even OpenClaw/Hermes across your teams, and any of these issues resonate, then you’re in the right place.

These problems are usually context problems.

What you’ll get out of this

Using this playbook, you’ll learn how to equip your AI agents with

• Complete knowledge about you and your team’s work
• Rigorous understanding of your processes and standards
• Mechanisms for continuous learning and improvement

Why you need a context system

Why this is harder for a team than for you

Working with AI inside a whole team presents challenging problems for a few reasons.

• There’s far more context than any one person can hold in their head
• New information is coming from hundreds or thousands of people and automated systems
• Whoever produced a piece of context usually isn’t the person who needs it three months later
• A lot of the information is private and can’t be shown to everyone, let alone your AI

Every context system should have information that falls into five types: declarative, procedural, historical, relational, evaluative.

Any real piece of work draws on all of them at once. To write a single outbound email, an agent needs to know who the company is, how you prospect, what you’ve already sent them, who you know there, and what a good email looks like.

Scope

If you are only building a context system for personal productivity, you could stop here. But for organizations there’s another important dimension to consider for context: scope.

Scope describes the level of operation at which a particular piece of context is relevant. There are three levels of scope that need to be taken into account: individual, team and organization.

What this looks like on your team

A quick disclaimer before we jump into things. AI knowledge bases is a very deep and constantly evolving domain. There are constantly new, sophisticated methods available for building and managing these things. The most powerful among them require some technical know-how to implement.

How a knowledge system should be architected is just as much an operational question, however, as it is a technical question. Where context lives, who can see it, and who keeps it current all shape what your team can get an agent to reliably do.

The first thing you need to understand is how an agent consumes context.

How agents find what they need

When you’re using an agent, you might not realize it but several types of context enter your session from the moment you hit “send.”

Behind the scenes, your agent is reading system prompts, searching its built-in memory, and fetching additional information from files and tools.

There’s real potential for information overload. Your AI agents might have access to dozens or even hundreds of resources with potentially useful context. If it reads all of them it will fill up its limited context window, reducing its effectiveness and costing you a lot of wasted tokens.

Luckily nearly all agents have a mechanism built in called progressive disclosure. This means that agents receive some context up front like a table of contents along with your prompt. Then as it works it will retrieve additional resources like skill instructions and project-specific memories as needed.

A well-organized context system delivers the information that your AI needs to execute its task correctly. No more, no less.

The shape of a context system

Context comes from a handful of distinct places and each one holds different types of information.

Most of it you connect rather than build. Your CRM, your Slack, the recordings of your calls, whatever the agent pulls off the web - all of it becomes context the moment an agent can read it. A smaller part you write: the knowledge base, and the instructions and skills that tell an agent how you work. The knowledge base serves people and agents at the same time, which can make it a bit awkward.

Contrary to what a lot of people think, you don’t need to put every piece of information in one place. I’ve seen a lot of teams try to move every piece of context they own into one monolithic knowledge base. While tempting to do so, this is usually a mistake.

Having one huge system has three major downsides

1. The system becomes large, complex, and difficult to maintain
2. You lose the advantages of specialized tools optimized for managing specific data
3. You create a single point of failure risk

How to organize a context system

No one has figured out a perfect organizational context system architecture. There are probably multiple architectures that are best in different types of organizations.

Still, there are a few architectural principles that every good team context system should follow.

1 general knowledge base + multiple specialized systems of record

Your systems of record - the CRM, ERP, HRIS, etc. - are already great at the jobs they do, so use them rather than building something new. Your knowledge base is for all the other important information that doesn’t live in any of them.

Every unit of context lives in exactly one place

When the same information lives in two places, the copies eventually disagree. That confuses the AI and leads to errors and it’s a headache for whoever maintains the system.

Anything shared lives in the cloud

Everyone on the team needs to be working from the same version. If one person’s agent is reading a different copy of the knowledge base, the two agents will give you different answers.

Processes stay separate from the data they run on

You need to be able to change how a process works without editing every document it touches.

If an agent can’t reach it, it doesn’t exist

Data that can’t be read and written through an API, a command line, or an MCP server isn’t part of your context system. You can always export files by hand, but needing a person in the loop every time will slow you down.

With these principles in hand, let’s talk about how each piece of the system should be structured.

1. Knowledge base

How I organize my knowledge base

This is roughly what my own team’s knowledge base looks like. I’m showing it as a basic file directory, but it could be implemented in any tool since the structure is what’s important.

I split up the directories based on what the information is about. Company knowledge in one hub, one hub per client, and a hub for the people and organizations that come up repeatedly.

Even though some of the info in here is sales related, it doesn’t duplicate my CRM. The client hubs hold research, working notes, and whatever the client sent over. Meanwhile, my CRM still holds people, company and deal records.

2. Systems of record

3. Unstructured streams

Most of what your organization knows never makes it into an organized system. It’s in Slack threads, email chains, call transcripts. This data contains the richest context in your organization but it is also the hardest to wrangle. It’s sprawling, unstructured, and growing every minute.

An agent pointed at your entire Slack workspace will struggle to make sense of what it’s seeing, and is likely to misunderstand discussions that are happening without much surrounding context.

So instead try to mine what you can by synthesizing insights out of it on a cadence. For example, every day you can have an agent review what’s accumulated since last time, match the topics discussed against your knowledge base or a relevant system of record, and update anything that changed.

4. Instructions and skills

A team AI context system uses distribution platforms such as plugin marketplaces and org-level instruction files to automatically load the same directions into every user’s AI. This is how you encode policies and best practices into everyone’s agents by default.

5. External data sources

Everything we’ve talked about so far covers the context that lives inside the walls of your organization. But there’s a lot of important information outside your company, in the news, on social media, from external data providers, and around the web.

Agents with access to these sources can supplement their knowledge with real-time data via API queries and web search. These sources provide ephemeral, just-in-time knowledge about the world.

There are two factors that make external data challenging to use in your AI context system. The first is quality. If people in your organization are using different data providers, it’s likely they’ll come up with different answers to the same question.

There’s an obvious security challenge as well. Anything you bring in from outside, whether it’s a webpage or a third party agent skill, introduces risk. A team that analyzed nearly 4,000 agent skills from OpenClaw’s public marketplace found 76 with malicious payloads and 13.4% having critical security issues.

Regardless, you should be using external data sources because they fill a gap in your system. Just make sure the sources are trusted, vetted, and shared across your org.

No single location can or should hold all of your context. There’s no right way to put the system together either - what works best depends on many factors. Going from 0 to 60 with your AI context system will take strategy and process. The decisions you have to make are operational as much as they are technical.

The most important thing you can do is define what good context looks like. Without an objective standard you’ll have no way of knowing when bad information gets in, and that will lead to AI errors downstream.

Good context is:

Ownership

Every context source needs an owner whose job is to make sure the context inside it stays high quality. Since most of the context already exists in your organization for human employees, whoever already owns a particular system is usually the right person to keep it correct.

An owner doesn’t have to verify everything themselves, just find whoever does know.

Quality

Soon every organization will have dozens of agents taking actions that both read and write to shared context systems. AI Agents produce a ton of output that could naturally turn into context for future AIs: call notes, business plans, drafts, updated database records. When the output is high quality, this kind of high velocity automation is a valuable compounding force.

But bad output - AI slop - is just as damaging in the opposite direction. Polluted context creates confusion and degrades output quality over time. Your job as keeper of the team context system is to eliminate slop from getting in.

There are 4 simple operational steps you can take towards maintaining context quality.

Freshness

Freshness is the other side of the coin. Parts of your context system that are touched less frequently can easy go out of date. Out of date context in any of your systems confuses agents and leads to misalignment, just like with people. Stale context can be even harder to catch than purely incorrect information because the agent has memory of it once being true.

Context is changing constantly. Decisions are made, metrics change, new features get shipped, issues get resolved. The only way that your agent can keep an up-to-date understanding of the state of the organization is if you build a system around it that keeps context fresh.

Given the complexity of data management within organizations, this could be an entire guide by itself. It’s worth walking through a process for how to approach data freshness in a part of your business.

Permissions and governance

Your AI context system will likely include some sensitive data, and it’s important to be aware of it and protect it.

If you’re in a highly regulated industry or handling sensitive data at volume, there’s a whole additional layer of work that this playbook doesn’t cover. But for everyone else, this will be a solid starting point.

The easiest way to get your AI connected to context sources is via built-in MCP connectors that major agent products ship. Permissions granted to the AI with these connectors follow the credential of the user who set up the integration. In your personal account, that’s no big deal. But it can create issues for a team with different access to sensitive information.

What happens when “Tom”, the team’s shared autonomous agent, needs to access the HR system? If the admin connects their account, Tom will inherit administrative permissions and anyone working with tom will get full admin access by proxy. Not good. You could solve the problem by removing any sensitive tools from Tom’s toolkit, but that’s a cumbersome fix and leaves open the risk that someone forgets and gives Tom new tools in the future.

Luckily there are better approaches. You can create an entire new user account for your agent, complete with email address and all - tomtheagent@domain.com. This lets you assign permissions to it just like you would a human employee. Alternatively, you can grant your AI programmatic access to tools via API, using a private key or other developer credential, which can have granular permissions assigned.

The pieces that make up your context system are as dependent on the shape of your organization as they are on the business strategy you’re executing. When your business is complex and always moving, building this out requires a focused process.

This is a good time to stop and assess. How complete is your AI context system already?

AI technology is evolving quickly. The hot platforms and models of today may not be the ones that endure years or even months from now. Getting locked into a specific model provider’s or software platform’s ecosystem is costly and I’d advise anyone to build on open tools, or at least tools that enable you to take your context and leave.

A true organizational context system is built around principles that enable your business to maximize the capabilities of today’s frontier AI tools. How much ROI you get from those tools is driven by your operations as much as by your technology.

Sawyer Middeleer

I’m the founder of Revi Systems, where I help companies scale their operations with AI. Over the last 10 years, I’ve built and deployed AI operating systems into leading B2B software and services organizations. As a leading expert in AI operations, I’ve driven AI transformations across sales, support, and operations at companies from venture-backed startups to multibillion-dollar enterprises.

I also write Exponential Operator, a newsletter for chiefs of staff, strategic operators, and anyone embedding AI into how their company operates.