Agentic BI for Amazon: from query to execution.

What is agentic BI for Amazon?

Agentic BI for Amazon pairs an AI agent with read-only query access to normalized Amazon data, and with tools that change it. In Pulsify, the agent reads with query_data and acts with queue_mutations for Sponsored Products and listing requests, or patch_listing for listing attributes.

In plain language: your agent investigates across economics, ads and catalog in seconds, then applies the fixes you approve in the same thread.

Why do Amazon BI dashboards go stale before you open them?

Because most are fed by batch reports. A pipeline asks Amazon for a report, waits for it to build, then loads it. Amazon's own reporting FAQ says Ads impressions, clicks and spend are typically available within 24 hours, and that the numbers keep moving for 48 to 72 hours while clicks are validated.

Pulsify's report-fed views carry the same lag. Ad data reads low for about the last 14 days, and economics restate for about the last 7, while Amazon settles them. Vendor metrics land 2 days late, and search query data appears once a reporting window closes. query_data tells your agent which days to distrust.

The difference is a push layer. Pulsify subscribes every connected seller to core selling notifications such as orders, stock and listing status, and stores each one on arrival. The rest, including hourly Marketing Stream traffic and budget usage at every 5% (Amazon's data guide has the cadences), subscribe when an automation needs them.

Your agent reads those events with list_events and get_event. Automations react to them with no agent in the loop.

Can your dashboard discover patterns across separate silos?

Not without someone building the join. Margins and returns live in Seller Central, campaigns in the Ads console, search queries in Brand Analytics. Each has its own reports.

Pulsify puts them where your agent can join them. v_seller_economics holds fees, net proceeds and refunded units per SKU per day. v_ad_performance holds spend and attributed sales per campaign per day. v_search_query_performance holds Brand Analytics search queries with your ASINs' impression and click share.

Two questions that cross all three:

• Which ASINs get ad spend while their refunds climb?
• Did TACoS rise the same weeks your click share on a top search query fell?

TACoS here is ad cost over ordered_product_sales. Ad spend is tracked per campaign, so when a campaign advertises several ASINs, per-ASIN spend is a share of it. Treat it as a lead, not an invoice. Search query data needs Brand Analytics access on the selling account.

How far back can you query without filing an ETL ticket?

Amazon's report APIs only look back a limited window, and the window varies by report. Anything older exists only if someone was already storing it, which usually means a warehouse and a ticket.

Pulsify keeps your order history, daily economics and daily advertising metrics. query_data reads that history in SQL, so a year-over-year comparison is a query, not a project. How much history you get depends on when you connected. It grows every day the account is active.

Some records are short by design. Events, tool calls and hourly Marketing Stream metrics are pruned on a schedule. The retention table lists every window.

What happens when a dashboard spots a problem?

Nothing. A dashboard shows you the problem. Then you take a screenshot, log into Seller Central or the Ads console, find the campaign or listing, and click through by hand.

Your agent closes the loop. It finds the target with list_ads_entities or list_listings, checks the payload shape with get_mutation_schema, and queues the change with queue_mutations. Sponsored Products payloads are checked against Amazon's native schemas before they queue.

Queued means admitted, not accepted. The receipt on the target shows Amazon's answer when it arrives. queue_mutations is marked destructive, so clients such as Claude ask before running it.

queue_mutations has no dry run. Package the logic as an automation and run_automation dry-runs it: nothing is applied, and you see the changes it would make.

Traditional Amazon BI vs Pulsify Agentic BI

From question to action in one conversation.

You ask your agent: "Which campaigns spent over $50 with zero sales over the last 7 days?"

It writes a read-only query and runs it with query_data. Money columns are integer minor units, so $50 is 5000. The currency filter keeps currencies from mixing.

SELECT campaign_id, campaign_name, campaign_state,
       sum(cost) AS spend,
       sum(attributed_sales_7d) AS attributed_sales
FROM v_ad_performance
WHERE currency = 'USD'
  AND report_date >= current_date - 6
GROUP BY campaign_id, campaign_name, campaign_state
HAVING sum(cost) > 5000
   AND sum(attributed_sales_7d) = 0
ORDER BY sum(cost) DESC

Amazon restates the most recent 14 days or so of ad data, so a campaign with zero attributed sales is a candidate to pause, not a verdict. Your agent proposes. You approve.

Say a campaign comes back. Your agent takes its campaign_id from the result, checks the payload with get_mutation_schema, and queues the pause with queue_mutations (pseudocode):

queue_mutations({
  mutations: [
    {
      target: { type: "Campaign", id: "<campaign_id from the query>" },
      action: "update",
      payload: { state: "PAUSED" },
    },
  ],
})

Read the campaign again with list_ads_entities. Its mutations show Amazon's answer.

Don't want to ask every week? Have your agent package a rule like this as an automation. run_automation dry-runs it. Once you activate it, it runs on events with no agent in the loop. The recipes include one that pauses a campaign that spends without selling.

What do you need to try this?

An agent that speaks MCP, such as Claude, Codex or ChatGPT, and a connected Amazon account. Connect your agent adds Pulsify by URL. Connect Amazon authorizes Seller Central and Amazon Ads.

The views you can query depend on the connection:

• Seller Central: v_sales_lines, v_listings, v_listing_mutations, v_seller_economics, v_search_query_performance, v_coupon_performance, v_promotion_performance and v_catalog_items.
• Amazon Ads: v_ad_performance, v_advertised_products and v_catalog_items.
• Vendor Central: v_vendor_metrics.

v_marketplaces is reference data that every account can read. Data arrives in stages after you connect, and Amazon keeps revising recent ad reports.

What can you ask first?

Paste any of these into your agent:

• "Which SKUs lost the most net proceeds per unit over the last 8 weeks? Break the drop down by fee." Reads v_seller_economics.
• "Which ASINs have a climbing refund rate while the campaigns advertising them keep spending?" Reads v_seller_economics, v_advertised_products and v_ad_performance.
• "On my top ASIN by sales, which search queries lost the most click share in the latest weekly window compared with the one before?" Reads v_search_query_performance. Needs Brand Analytics access.

Use both.

Dashboards are the right home for executive reporting, board slides and investor decks. A fixed view that everyone reads the same way is the point.

Daily operations belong with your agent: investigating a sudden margin dip, isolating a rogue bid, pausing a bleeding ad. The question and the fix happen in the same thread.

Pulsify is an MCP server, so all it costs you is one more connector. Keep your dashboards and add Pulsify to the agent you already use.