- A context layer sits between your systems and your AI agents. It keeps a fresh, connected and permissioned picture of the business, so an agent can ask one question and get back facts it can act on.
- It has six parts: connectors and sync, identity (which records are the same thing), meaning (governed metric definitions), relationships, rules and memory, and controlled access for reads and actions.
- The safest way for agents to act is through the layer: read the prepared context, confirm with a live read, and change things only through named actions that people can approve.
Connecting an AI agent to your business has never been easier. Claude, ChatGPT, Codex and most agent frameworks speak the Model Context Protocol, and nearly every SaaS tool now ships an MCP server or an API an agent can call. Within an afternoon, an agent can pull campaign rows from Meta, orders from Shopify and messages from Slack.
And yet the answers that come back are often wrong in ways that are hard to spot. The agent reports a ROAS figure computed with a different attribution window from the one your team uses. It recommends scaling a campaign whose hero product has eleven units left. It treats the same customer as three people because their email, phone number and marketplace ID never got joined. In each case the model reasoned sensibly over the material it was given, and the material was incomplete.
A context layer is the piece of infrastructure that fixes the material. It is a shared, always-current model of your business that every agent reads from and acts through. This guide explains what goes into one, how a request moves through it and how it differs from the data tools you already have.
The problem a context layer solves
When an agent answers a business question with raw tool access, it assembles context at runtime. To answer “should we raise the budget on this campaign?”, it has to call the ad platform for performance, the store for inventory, maybe a spreadsheet for the target, and a chat tool for any instruction the team gave last week. Each call returns a large, raw payload. The agent then has to work out which rows refer to the same product, apply a formula it may or may not know, and hold all of it in its context window while it reasons.
There are two ways to give an agent context. Runtime assembly means many API calls, raw payloads and entities reconciled during inference, with latency and token cost that compound with every source. Pre-materialisation means the joins, definitions and permissions are prepared ahead of time, so the agent makes one query and gets back a structured answer. Preparing context ahead of time cuts the tool calls an agent needs, and the tokens it spends, by a wide margin, because the layer hands back the fact instead of the raw material the fact is buried in.
Token cost is the visible symptom. The deeper problem is that a model cannot reliably infer business meaning from raw rows. It does not know that your team measures ROAS on a seven-day click window, that “active campaign” excludes the brand-search campaigns, or that the founder said in Slack not to scale anything until the new batch arrives.
The six parts of a context layer
- SourcesAd platforms, marketplaces, store, docs and team chat
- Context layerIdentity, meaning, relationships, rules, memory and permissions
- WorkflowsMonitor, investigate, decide, approve, act
- AgentsClaude, Codex, your own apps
Definitions vary, but a working context layer has six parts.
1. Connectors and sync
Data has to arrive, and keep arriving. That means connectors to each source, an incremental sync that pulls only what changed, and a refresh cadence set by how quickly each decision goes stale. Pacing and stock-outs need minutes. Creative libraries can be refreshed daily. A later post covers freshness in detail.
2. Identity
The same real-world thing appears under different IDs in every system. One product is a Shopify variant, a Meta catalogue item, an Amazon ASIN and a Flipkart FSN. One customer is an email in the store, a phone number in WhatsApp and a lead ID in the CRM. Identity is the first thing agents need beyond metric definitions, because without it an agent cannot connect evidence across tools.
3. Meaning
Every metric the business steers by gets one governed definition: the formula, the window, the currency, the exclusions. This is the job a semantic layer has done for dashboards for years. Agents need it even more, because a model left to compute ROAS on its own will do it slightly differently each time.
4. Relationships
Entities are linked: a campaign promotes a product, the product has an inventory position, the campaign belongs to a budget, the budget has an owner. Relationships let an agent follow a chain of evidence — from a falling ROAS to the product, to the stock level, to a competitor’s price cut — without hand-writing joins. This modelled world of things and links is usually called an ontology.
5. Rules and memory
Targets, thresholds, playbooks and past decisions live here. “Don’t scale a campaign when its product has less than a week of cover.” “Client asked to pause the cataract campaign until October.” “Last time CPC spiked like this, the cause was a broken landing page.” The flow of work — instructions, approvals, past decisions — is context in its own right, and decisions themselves are data worth keeping.
6. Controlled access
Agents read and act through the layer, never around it. Reads are trimmed to what the requesting person may see. Writes go through named actions with checks and, for anything that spends money or reaches a customer, a human approval. Every call is logged. MCP is the usual transport, but the protocol itself only standardises how tools are discovered and called; permissions and audit are the layer’s job.
What a request looks like
Take a concrete question an agent might receive at 9 AM: “Should we raise the budget on the Search campaign for our hero serum?” Here is the path it takes through a context layer.
The agent never had to call four APIs, reconcile three product IDs or guess the attribution window. It asked one question and received facts with their provenance attached, which it could explain back to the person who asked.
How it differs from tools you already have
| Tool | What it is good at | What an agent still misses |
|---|---|---|
| Data warehouse | Historical analysis, large aggregates, reporting | Freshness, identity across tools, rules, permissions per person, a safe way to act |
| Semantic layer | One definition per metric, consistent dashboards | Entity-level questions, live state, relationships, actions |
| Vector database / RAG | Finding relevant passages in documents | Exact numbers — metrics should never come from similarity search |
| Raw MCP connectors | Reaching each tool quickly | Joins, meaning and governance; every agent re-assembles context on its own |
| Context layer | Fresh, connected, permissioned business state for agents to read and act through | Only as good as its sources and definitions — it needs owners |
These are not competitors. A context layer usually reads from the warehouse, embeds or references the semantic layer, and uses retrieval for documents. The division of labour is simple: governed metrics come from the semantic layer, operational records from the context store, documents from search and live state from direct API calls, with the layer deciding which path a question takes.
Why decisions belong in the layer
Most data systems record what happened: spend, clicks, orders. Very few record what the team decided about it, and why. For agents, that gap matters as much as a missing data source.
If the layer keeps each alert, the evidence behind it, the proposal that followed, who approved or rejected it and what happened next, three things become possible. An agent can check precedent before it recommends anything: the last time CPA jumped like this on this account, the cause was a broken checkout. The team can answer “why did this budget change on Tuesday?” in seconds instead of scrolling through chat. And the rules themselves can improve, because rejected recommendations show exactly which piece of context the agent was missing.
This is also what makes a context layer more valuable over time. Models get cheaper and more interchangeable every year. The record of how your business makes decisions only grows, and every new agent you connect starts with all of it.
When you need one
You do not need a context layer to ask Claude to summarise a CSV. You need one when agents move from answering to operating. The signs are familiar to most growth teams:
- Two agents, or an agent and a dashboard, report different numbers for the same metric.
- Someone pastes exports into a chat window every morning because the agent cannot see the whole picture on its own.
- Recommendations ignore things the team already knows: stock levels, launch dates, client instructions.
- Nobody is comfortable letting an agent change a budget, because there is no record of what it saw or who approved it.
Meerkats is built as this layer for growth teams. It connects ad platforms, marketplaces, your store and team knowledge into one live business context, and lets Claude, Codex and your own agents read from it and act through approved workflows. Whatever you use, the six parts above are a useful checklist for judging whether an agent has enough to be trusted with a real decision.