The five layers of agentic context

Written by Magnus Hillestad

Agents with bad context do not work.

AI models keep getting more capable, faster, and cheaper. We are using them to solve previously unsolved math problems and they can tell you in milliseconds whether something breaks a rule based on vast knowledge about the world. In some ways they are getting so powerful that we have started to fear what they can make us capable of. In other ways we experience every day that they fail in incredibly stupid ways.

While they know a remarkable amount about the world, they know almost nothing about how your business actually works.

They don’t know that your return policy changed last week. Or what your customers ordered most of in October. They don’t know that refunds over $600 need a manager’s sign-off, that your customers in the support chat already tried the fix the agent is about to suggest, or that the last ten customers who encountered the same issue preferred a replacement to a refund. This knowledge has to come from you.

Every team who puts an agent between them and their customers should be asking: how do you prevent agents from telling your customers the wrong thing about your business?

“Just give them context,” you might answer. Which is not wrong. But what is “context”? And should you think about it when it comes to preparing your business for agents that act on behalf of your users?

Evan Armstrong made a strong case in "Context is King" that value is moving from systems of record to a context layer, because systems of record "store data, not meaning." I agree with the diagnosis. Where I'd push further is the singular.

Our answer is to stop treating context as one thing. A better model is to think of context in five layers: canon, records, process, situation, and memory.

Each context layer might have different owners, change at a different speed, need different rules, and interface differently with the rest of your tech stack.

When an agent gets something wrong, one of these layers is usually missing, stale, disconnected, or unowned. And the layer most teams seem to underestimate is the context that tells agents what your business is about. It’s the product facts, policies, messaging, and approved claims an agent relays to your customers. I call that layer canon, as in canonical. It’s what should be true about how your business works and what it stands for.

Let me walk through all five layers, then spend most of this piece on what it takes to get canon right, since it's the one that needs the most work.

The five context layers

None of these context layers are new. You probably have some processes and systems for all of them. What is new is that agents can process information way more efficiently than humans can. So getting context right or wrong can give you a lot of opportunity on one hand and a lot of risk on the other.

Canon: what do we stand behind?

Product facts, policies, documentation, approved claims, positioning, brand. This is your canonical content, the material your organization has decided and stands behind. It changes when people decide it should. It is authored, reviewed, and approved, and it's the layer the agent repeats out loud to your customers. It’s how your business exists in the market.

When it's wrong, the agent confidently tells your customer something your company doesn't stand behind. When it’s right, you free up time for your team to explore new opportunities that were previously spent on busywork and chores.

Records: what happened?

Customers, orders, SKUs, transactions, call transcripts, history. It’s what’s in your system of record. It changes constantly and is owned by the systems that produce it. It's mostly facts about what already took place. Agents with access can know more about who they are talking to.

Process: who decides, and what may the agent do?

Who owns which content, who approves a change, what an agent may do on its own, and when a person needs to be in the loop. This is how your company operates. Some of it lives in approval flows and permissions, and a lot of it lives in people's heads. When it's missing, the agent acts where it should have asked, like approving an $800 refund on its own. When it's right, you can give agents more work with confidence, because they know where their mandate ends.

Situation: what's going on right now?

Who the agent is talking to, what they have already said, what they are trying to do, and what has happened so far. This is the context of the moment. It lives for minutes or hours, then it's gone. When it's missing, every conversation starts from zero, and the agent suggests the fix the customer already tried. When it's right, the customer doesn't have to repeat themselves, and the agent can pick up where things stand.

Memory: what have we learned?

Which answers solved a problem, what customers corrected, what a returning customer prefers. This is what the agent learns across conversations. The agent writes it as it goes, and usually nobody reviews it. When it's missing, the agent repeats its mistakes, like offering a refund when a replacement works better. When it goes unreviewed, it can teach the agent habits nobody approved, like handing out discounts to end complaints. When it's reviewed, the lessons worth keeping move into canon.

These five context layers sit on top of what the model knows about the world. While you can pick models, you (most likely) don’t own them, you can’t govern what goes into them, and they are the same for your competitors as they are for you.

Why not put all context in one place?

Recently, platforms have started to brand themselves as “the company brain” and the one-stop-shop for everything agent context. This is understandable, there might be a lot of great business in becoming the control plane for agents.

The strongest case for a single context layer is simplicity. One index, one place to connect, one thing to keep in sync. If every document, ticket, transcript, and message your company produces lands in the same store, surely the agent can find what it needs?

It sounds a lot like the promise of the data lake that was popular about a decade ago. Data platforms were a useful addition to our stacks, but we never really saw the promise of everything in one place fulfilled. Many lakes turned into swamps. Data went in raw, without owners, and after a while nobody could tell which tables to trust. The reality is messier and more fragmented, and not all data is created equal.

To be fair, today’s company brains work better than this. They contain your internal wiki, connect to Slack, and other systems. They usually respect permissions and cite their sources for those who care to look. That might work well internally in a company where employees can judge the answers based on their contextual awareness. But it gets messy when you try to use it for your customer-facing agents.

So let’s face it: context will always be distributed, because the people and systems that own each layer are different, and they should be. The job is not to collect everything in one place. The job is to capture and qualify the context that matters, and route it to the agent or the person who needs it, in the moment they need it.

Routing only helps if what you route is correct. Canonical context has often found its way to a website where it’s organized by “pages” in some sort of taxonomy. But it also spans those internal documents and sources that make up what your business is. So you will need to think about where to put it and how to operate it.

Canonical context needs more than a database

Canon is the layer most developers seem to treat as a storage and retrieval problem. Put content somewhere the agent can search, and you're done.

This might be OK for small and limited applications, but once you want to scale this in an organization and have it close to the value chain of what your business is doing, you will start to feel the friction and the pain.

Most of your canon already exists. You will find it spread across your website. It’s your pricing page, product landing pages, terms of service. And behind your website there is a sales deck, battle cards, brand guidelines, support snippets, and your agent’s system prompt. But most of it was written for a human to read on the web.

An agent can read your whole website in one sitting, so any contradiction might become a potential stumbling block: best case the agent has to spend some extra tokens figuring out what mostly is correct, worst case, it repeats the wrong thing to your customer.

You will also find that reframing your content as a collection of web pages to a structured content model makes this job easier for everyone involved. Agents too. It makes it easier to have single-source-of-truth and reduce the places you have to update the same information.

Canonical context has to be run the same way you should run your website. Your web and content team probably does a lot of the necessary things already: they draft, review, approve, audit, translate, schedule releases, configure who can edit what. That’s content operations. Canon needs the same discipline, but now stretched to also cover internal sources and adding agents as another channel to cater for. And of course, they can use agents for this type of work too.

While you can express all of this as data stored in a database, you need working interfaces that let your team do these operations efficiently. And it’s beyond what’s reasonable to do in only a chat text interface.

Your content team is now a context team

A lot of what belongs in canonical context isn’t written down or put into a place where it’s accessible. It might live in a Slack thread from last year or in someone's head.

The first time you prepare a knowledge base about your business, I'd be surprised if you didn't find that your company disagrees with itself.

Building out your canonical context layer is less a technical challenge and more of a content one. Developers can't solve it alone. Content teams who have worked on documentation, support, and knowledge bases already know how to find these conflicts and call them out. Those teams have become more valuable.

You don't need to be an AI expert to do this well, but you need to be intentional. In fact, content teams are probably already familiar with this. They have treated the content that goes on your website as this type of canonical content for years already. What changed is that suddenly, this content is used to automate a bunch of decisions to accelerate productivity.

So the teams who pull it off treat the knowledge and instructions behind their agents the way they treat their website: owned, reviewed, maintained, measured, and iterated on. Developers who make that lifecycle easier are force multipliers. Agents can help here too, as long as a person signs off on what becomes canon.

Canon needs its own building block

Your records have their system. Canon needs an infrastructure. A place where it’s written, reviewed, kept current, and can be routed to where it needs to go. It doesn’t just hold your content, it also makes it possible to operate.

The clearest example I've seen came from Braze at our annual conference Everything *[NYC]. Matt Chamberlain made a Sanity Knowledge Base from Braze's public documentation, a site Sanity doesn't power, and got an MCP endpoint for it live on stage. Then he showed what they are building on top: a pipeline that watches sales calls and market changes, drafts updates to competitive battle cards and Slack summaries, links every suggestion back to the transcript it came from, and puts each change in front of a person to approve.

Braze's problem was never a lack of content. How they talk about their product lived in a hundred places, and no one person could keep it current.

Braze's setup shows how the layers work together. Records and memory come in as signals. People and agents turn the signals that matter into canon. Canon goes out to every agent that needs it.

We’re building Knowledge Bases, part of Sanity Context, as a building block for your canonical context. You give it sources: websites you own, files, and content in your Sanity datasets. It builds a map of the facts: which topics exist, how they relate, where the details live, and which sources support them. It finds contradictions between your sources and lets your team decide what to do: fix them upstream, or add a rule that applies every time the Knowledge Base is rebuilt. You get a record of those decisions along the way.

A Knowledge Base is canon compiled for an agent. It makes it easier for your team to decide what an agent should know, and faster for the agent to find it. Without it, an agent searches whatever it can reach and assembles an answer from scratch on every question. With it, the agent starts from precise facts that even a smaller, cheaper model can work with.

Precompiled knowledge is also what makes fast, cheap models useful in production. When the map is already drawn, a small model can answer correctly and quickly, and a classifier that costs almost nothing can check every answer against the Knowledge Base before it goes out. A cheap checker is only worth something if you have something correct to check against.

Knowledge Bases is served over MCP, so it works with the agent you're already building. You don't need to be a Sanity customer or move your runtime to use it. For the process layer, Workflows lets you define how content moves and who signs off, with people and agents working on the same stages under the same permissions.

Keeping agents from saying the wrong thing

So, how do you prevent an agent from telling your customers the wrong thing? And how do you get away with cheaper, faster models in production?

Not by waiting for a smarter model. You work out which of the five layers your agent needs and where each one lives. You treat canon as a set of decisions your organization owns, not a pile of documents. You keep it current and correct. And you give your team of humans and agents a place to do that work, and a way to route the result to every agent that needs it.

There's a rule of thumb underneath the five layers. The more autonomy you give an agent, the more of its context needs to be canon.

That is why we are building Sanity.