The context layer
How data, meaning, state, goals, memory and team knowledge give agents the understanding you have.
An AI agent with access to your data still doesn’t know your business. It can read a campaign’s ROAS; it doesn’t know the campaign is advertising a product that went out of stock on Tuesday, that you are deliberately buying growth at a lower ROAS on the new range this month, that the promo ended yesterday, or that ROAS on this account is measured on a 7-day click window and compared to a target of 3.5. Give it that once, in a prompt, and it is stale by the next morning.
The context layer is Meerkats’s answer. It is everything an agent needs in order to understand a situation the way you would, kept current as the business changes, and served to every agent, report and rule from one place. It has six parts: data, meaning, state, goals, memory and team knowledge.
Data#
Everything starts with the synced tables. Each connection lands in Data Hub › Bronze Layer as raw platform data, one table per object: campaigns, ad sets, ads, creatives, keywords, orders, customers, products, listings, settlements. Two details matter.
- Entity streams see everything. A platform’s reports only show entities that had traffic. Meerkats also syncs the management objects themselves, so a paused campaign, an unused audience or a negative keyword list is known even though it never appears in a report.
- Every sync is a snapshot with a date. Objects are stored as of each sync, so a budget or a price has a history, and a change can be dated even where the platform offers no change log.
Data Hub › Gold Layer holds the modelled tables built from bronze: creatives, placements, demographics, geo, hourly, cross-platform spend, product revenue, the order ledger, customer cohorts. CDP Analytics holds identities: the people behind sessions, clicks and orders, stitched across sources.
Meaning#
Raw tables don’t say what a number means or how two things relate. Two layers add that.
Metrics defined once#
The semantic layer defines every metric once: its measures, formula, dimensions and attribution basis. Agents request metrics from it rather than computing them, every value carries its source, and platform-specific names (Purchase ROAS, Conv. value / cost, ROI, ACOS) map to one canonical metric underneath.
How things relate#
The relationship graph links entities across platforms, so an agent can walk from a symptom to its cause without you pre-joining anything.
| Relationship | Why it matters |
|---|---|
| Ad performance → campaign → ad set → ad → creative | A row of spend is tied to the thing that spent it, down to the creative and its UTMs. |
| Campaign → product | Which products an ad promotes: catalog items on Meta, Merchant Center items on Google, FSNs on Flipkart, ASINs on Amazon. |
| Product → stock and price | Each product's current stock per location and its price history, so an agent can see that the campaign losing conversion is advertising a product that sold out on Tuesday. |
| Order → customer → cohort | Every order to the customer who placed it, and the customer to the month they were acquired, their first product and the discount they came in on. |
| Order → line items → product | Revenue per product, per day, from the order ledger. |
| Click → identity → order | Click IDs and UTMs on the order, matched to the session and the click. The spine corrected ROAS runs on. |
| Spend across platforms | One table of spend per workspace, platform, campaign and day, so blended metrics have a single denominator. |
| Your product ↔ a rival's listing | Matched pairs from competitor tracking, with a confidence level on the match. |
Investigations follow fixed drill paths through this graph: on Flipkart, blended → campaign → keyword, search term, placement or product → the product funnel → card, page, offer, fulfilment or buy box. On Meta, campaign → ad set → ad → placement, demographic, geo or hour. On Shopify, revenue → orders → line items → product. An agent that explains a drop names the path it took.
State#
State is what is true right now, and how it got there. Monday’s healthy inventory and Wednesday’s stockout are different situations, and the same ROAS number means different things in each. Meerkats keeps three kinds of state.
- Current state: the latest snapshot of every object, refreshed on your plan’s schedule, plus live reads from the platform when an agent is about to act.
- History: every earlier snapshot, so trends, baselines and “what changed since” are answerable.
- Change events: who changed what, when.
| Platform | Where change history comes from |
|---|---|
| Meta | Full activity log from the platform: who changed what, old and new value, when. |
| Google Ads | Change history from the platform, which Google keeps for about 30 days. Meerkats ingests it continuously so nothing is lost. |
| Amazon Ads | History API with about 90 days of retention; ingested continuously. |
| Flipkart | No change-history API. Meerkats derives changes by comparing each sync's snapshot with the previous one, and labels them as derived. |
| Shopify | Inventory movements and price changes from product snapshots; order and refund events as they happen. |
What happens when state is missing or stale#
Agents never present stale data as current, and never skip a gap silently.
- Stale: the value is shown with its sync time and a staleness label, and a refresh is triggered.
- Missing: the gap is named in the output (“returns data isn’t synced, so I can’t check RTO”) and logged.
- Not in the warehouse yet: before concluding something doesn’t exist, the agent checks the platform live. Absence from a sync is not non-existence.
- Platform just connected: instead of running a full analysis over an empty table, the agent reports sync status and says what becomes possible once data lands.
Goals and conventions#
Numbers only become judgements against a frame: what you are trying to achieve, what you protect, how your account is set up. Each workspace stores this once, and every agent reads it.
| What | Examples |
|---|---|
| Identity | Brand, business model (own store, marketplace mix, services), currency, time zone |
| Goal frame | Target ROAS or CAC, growth vs efficiency mode this month, budget caps, entities that are protected from automated change |
| Business footprint | The cities and regions you actually sell to, with volumes; COD share; courier setup. Used to sanity-check geo targeting |
| Commerce priors | AOV, which fee lines are actual vs rate card, hero products, seasonality calendar |
| Conventions | Campaign naming, structure (one campaign per product line, split by geo), learning phases and freeze windows |
| Platform accounts | Which ad accounts, stores and seller accounts belong to this workspace |
| Competitive set | The rival listings you track, paired with your own products |
A goal frame is proposed by Meerkats from your data and confirmed by you. If no frame exists, analysis runs on workspace defaults and says so; the question is asked only at the moment a change would cost money, and the answer is saved as the standing frame. Meerkats never asks for the same frame twice.
Memory#
Memory is what the context layer learns from running. It compounds: every run makes the next one better grounded.
- Account knowledge per platform: baselines, winners, placement and geo weights, what a normal week looks like. Measured on your account, with the window and date.
- Decisions and outcomes: every proposal, who approved or rejected it, the change made, and whether the metric moved as predicted. Rejected plans record the reason, so the same proposal doesn’t come back.
- Predicted versus actual: a ledger of every forecast an agent made and what happened, per action type. This is what earns an automation the right to act on its own.
- Known failure modes: patterns that caused a bad outcome before, checked before a similar plan is proposed.
Forecasts always cite their prior (“from your 90-day retargeting CPA”). When there is no prior yet, the agent says no account prior and gives wide bands instead of borrowing another account’s baseline.
Team knowledge#
The decisions your team writes down are context too. Connect Slack channels, Gmail labels and upload documents: SOPs, playbooks, price lists, client instructions. Agents read them, cite them, and follow them when proposing changes. A message in #growth saying “we’re buying growth at 2x on the new range this month” reaches the agent before it flags the dip.
How an agent uses the context layer#
- A request arrives: a scheduled check, a rule firing, or a question in the chat.
- Meerkats classifies it (report, investigate, audit, act, or a monitor) and the platforms, entities and grain involved. If the intent is ambiguous, it asks one question with ranked options and a recommended default. Never more than one.
- It resolves the goal frame for the workspace.
- It loads only the context the task needs: the metrics, relationships, state, conventions and memory those stages name. A Flipkart budget check doesn’t load Meta creative knowledge.
- Every value it resolves is stamped with its source. Thresholds, feasibility and rankings are computed by deterministic helpers; the model requests them and renders the result.
- The output names what it assumed (“last 30 days, all platforms”) and what it couldn’t check.
Every agent message ends by saying what happens next and who owns it: the agent acts, you decide (always with a recommended default), or the system waits for something named. No run ends in silence.
What you control#
- Confirm or edit the goal frame when Meerkats proposes it.
- Upload the documents and connect the channels where your rules live.
- Mark entities as protected, set caps, and declare learning phases.
- Approve and reject proposals. Each decision teaches the memory.
- Ask the agent “What do you know about this account?” and it lists the context it holds, with sources.
To inspect the raw material, open Data Hub. To see what fed a number, open About these numbers on Cockpit. To see what a run used, open it in Agents run history.