A personal-care brand built an ad intelligence layer across Flipkart and Amazon.

Built by a personal-care brand · Amazon, Flipkart and Meta · one metric catalog

Three platforms, three definitions of the same metric, three restatement windows. Reports were pasted into spreadsheets and questions were answered a day late. The brand built one intelligence layer on Meerkats: one catalog, campaigns tied to listings and stock, scheduled automations, and capped actions a person approves.

The situation

Amazon reports ACOS on its own attribution window. Flipkart reports RoAS and ROI and restates recent days. Meta reports purchase ROAS on a third window.
“Which search terms convert?” needed exports from each platform, a pivot, and someone to remember which column meant what.
An agent pointed at the raw APIs burned through its context on rows and tool definitions, and still mixed the definitions.

What they built, layer by layer

01Data & integrations

Amazon Ads and Seller Central, Flipkart Ads and product revenue, Meta Ads, the store. Synced on a schedule, with each platform’s restatement window handled.

02Semantic layer

ACOS, RoAS, ROI and purchase ROAS mapped onto definitions the brand chose. Defined once, used everywhere.

03Context layer

Campaigns tied to listings, listings to stock and price, each category to its target. Protected campaigns and change limits set as rules.

04Stateful workflows

A few automations on their own cadences: pacing, competitor prices, a search-term review across both marketplaces.

05AI agents & actions

Amazon changes through registered actions, within caps. Flipkart has no write API, so its plans arrive as a guided checklist.

06Governance & traceability

Every change is staged with its before state, expected effect, rollback and sources. A person approves. The outcome is checked afterwards.

How the search-term review runs

ScheduleEarly in the week, the automation reads search-term reports from both marketplaces, already mapped onto the brand’s definitions.
StateIt establishes what changed since the last run: new terms, terms that stopped converting, stock and price on the listings behind them.
DecisionTerms are ranked by code, not by the model, against the category targets. Each candidate change carries its source rows and freshness.
PlanOne plan: negatives to add, bids to move within the cap, and the campaigns left alone because they are protected.
ApprovalThe plan lands in the inbox with the evidence. The media buyer edits a line; everything downstream re-resolves. One approval covers the plan.
ExecuteAmazon changes apply, read back and store the previous values. The Flipkart part becomes a checklist with the exact values to enter.

The pacing automation, in outline

{
  "automation": "marketplace-pacing",
  "schedule":  "hourly",
  "scope":     { "platforms": ["amazon_ads", "flipkart_ads"], "exclude": "protected" },
  "metrics":   { "roas": "catalog:…", "pacing": "catalog:…" },
  "condition": { … },
  "plan":      ["amazon.campaign.budget.set", "flipkart.checklist"],
  "policy":    { "risk": "medium", "requires_approval": true }
}

A stateful automation is a typed contract: a trigger, a condition, the context it may read, the registered actions in its plan, and its policy. The model fills fields. Code validates, resolves and binds. A person approves what the policy says needs approval. The full contract carries more than is shown here.

Governance

Budget and bid changes are capped per change and per week. The caps apply even after approval.
Launch campaigns are protected entities. Prices and listing content are never automated.
Every number in a plan names the rows it came from and when they were synced. A value with no source does not render.

Next use case

A clinic group built its own CRM, with appointments booked automatically.

Build the next one on the same six layers.

Connect a system, define a metric, declare an automation. The first run is traceable from the start.

Build your first AI system →See use cases