- Freshness is a property of a decision. Stock and pacing need minutes; creative libraries can wait a day. Recent conversion data must be re-pulled because platforms keep revising it.
- Identity and permissions are resolved before the agent’s question arrives. Every read is trimmed to what the requesting person may see, and every write goes through a named, approved action.
- The safe pattern for acting is “discover, then act”: search the prepared context, read the live source for the specific records, stage the change, get approval, write, log.
The first two posts in this series covered what a context layer is and how it relates to semantic layers and ontologies. This one is about the engineering underneath: how the context stays current, how it knows which records belong together, how it decides what each agent may see and do, and how an agent goes from reading to changing a real ad account without surprises.
Nothing here is exotic. Every piece exists in mature data platforms. What changes with agents is that the pieces have to work together on every single call, because an agent will act on whatever it is given, at any hour, without a human double-checking the inputs.
Freshness is set per decision
There is no single right refresh rate. Set cadence by how quickly a decision goes stale and how costly a stale answer is. An inventory agent needs near-real-time data; a planning agent can work from a daily snapshot. For growth teams, that sorts sources into three tiers.
| Tier | Examples | Cadence | Why |
|---|---|---|---|
| Near real time | Budget pacing, stock-outs, ad disapprovals, marketplace buy-box changes | Every few minutes, plus a live read before any write | A wrong answer spends money or sells what you don’t have |
| Hourly | Spend, clicks, conversions, orders | Hourly, with the last few days re-pulled | Conversions keep arriving after the click, so recent days change |
| Daily | Creative library, audiences, catalogue attributes, competitor ad libraries | Daily | Changes slowly; decisions tolerate a day’s lag |
The second row hides the most common freshness bug in marketing data. Ad platforms attribute conversions back to the day of the click, so yesterday’s numbers keep changing for days as delayed conversions arrive inside the attribution window. An incremental sync that only fetches new days will freeze yesterday at its first, incomplete value. The fix is a lookback: every sync re-pulls the last several days and replaces them. The general failure is best described as stale but confident — no error fires, the agent simply reasons over a number that is no longer true.
Ad APIs rarely offer change feeds, so most sources are polled. Databases can use change data capture, which streams changes from the transaction log within seconds. Either way, each record should carry the time it was last confirmed, so an agent can say “as of 9:40 AM” rather than presenting a stale value as current.
Identity is resolved before the question arrives
Identity is an old problem in business data: a payment-system customer ID that belongs to the same person as an email address in the support desk. Growth data has the same problem, worse. One product is a Shopify variant, a Meta catalogue item, an Amazon ASIN and a Flipkart FSN. One buyer is a click ID on an ad, a lead in the CRM, and an email and phone number on an order.
Resolving these at question time is slow and unreliable; the model has to guess that two names refer to the same thing. A context layer resolves identity ahead of time, keeps the mapping as data (usually through the SKU for products, and click IDs, emails and phones for people), and exposes one entity to the agent. When the mapping is uncertain, it says so, instead of silently merging.
- Agent accessMCP gateway: scoped tokens, tool calls logged
- Context storesOne per workspace, permissions applied before results return
- Sync & identityIncremental sync with lookback; SKU, click ID, email matched
- SourcesAd platforms, marketplaces, store, CRM
Permissions travel with every call
The rule to hold to is that an agent acts with the permissions of the person it acts for, never more. AI activity should run under the same security policies as human activity, down to row, column and cell level. Delegated identity means results are trimmed to what the signed-in user may see, and document retrieval respects the sensitivity labels already set on those documents.
Three implementation details matter.
- Filter before retrieval. Apply permissions as part of the query rather than filtering results afterwards. A record the user cannot see should never enter the agent’s context window, even briefly.
- Isolate tenants. For agencies, each client’s context lives in its own workspace. One client’s data never informs another client’s agent, and access is granted per workspace.
- Scope tokens narrowly. Give agents read-scoped access by default and authorise writes action by action: tokens carry read access, and each write is checked against the action and the fields it may touch.
Discover, then act
Reading from a prepared context is fast and cheap, but it is a snapshot. Writing to an ad account is expensive to get wrong. The answer that generalises well is a two-mode pattern: search the prepared context to find what matters, then read the live source for the specific records before changing anything.
In practice this pattern cuts the exploratory calls an agent makes to one or two per task. The bigger benefit is safety: the agent never changes a budget based on a number that was true an hour ago.
What MCP covers, and what it leaves to you
The Model Context Protocol has become the standard way for agents to discover and call tools. Claude, ChatGPT, Codex and most frameworks support it, and most context platforms now expose an MCP server, usually with a small set of read tools and an even smaller set of write tools.
MCP standardises the conversation between agent and tool. It does not join your data, define your metrics, enforce your permissions or keep an audit trail; those stay with the layer behind the server. Tool design also has a cost: loading definitions for fifty-plus tools can consume tens of thousands of tokens before the agent has done anything. A small set of well-typed tools — search entities, resolve one, traverse links, aggregate a governed metric, propose an action — usually beats one tool per API endpoint.
Audit and memory
Every run should leave a record: what triggered it, which context it read and as of when, what it proposed, who approved or rejected it and what happened in the platform. That record does two jobs. It lets a person answer “why did the budget change on Tuesday?” in seconds. And it becomes memory: an agent that can see how similar tasks went before, and what the team accepted or rejected, gets better at the task across runs.
Meerkats handles this plumbing for growth data — connections, sync, identity, per-workspace isolation, approvals and run history — so the agents you build with Claude, Codex or your own stack start from context that is current and safe to act on.