AI Demand Forecasting Agent for eCommerce (2026)

Buyers do not need another hockey-stick chart. They need what is likely to sell, why, and whether to draft a PO or wait — without treating a language model as a statistics package.

On 17 June 2026, AgentCore Harness reached general availability (What’s New). After 30 July 2026, do not put net-new forecasting on Agents Classic (lifecycle). This post is a sample action brief. It is not a client MAPE study. Intervals and SKUs in the artifact are fixtures.

First-party signals we reuse (not eCommerce outcomes) — Gateway server-side tools cut median tool round-trip ~180 ms → ~95 ms on a B2B CRM assistant (12 tools, ~8k turns/day) — Gateway post. Platform TCO silhouette: support-style AgentCore at 50K sessions/mo ~$791/mo platform + model (decision guide). Model your mix on the AgentCore pricing calculator.

Reproduce this — Use demand-forecast-action-brief.md. The forecast_source field must be a tool. Folder: ecommerce-ai-agents-series/. Ship gates: monday-checklist.md.

This is series part 24. It feeds the inventory risk brief and the PO agent. Historical “what changed” stays in store intelligence. Morning ranking stays in the ops agent.

If the forecast tool is down, the brief is unknown — not a heroic number. Inventory may still flag class C from cover vs velocity. That is a risk signal, not a substitute demand plan.

Opinionated take: statistical models may still own the number. The agent explains and recommends. Trade-off: you operate a forecast service and a brief. You do not let next-token prediction become your MRP.

Why this matters / who breaks without it: buyers break when a confident paragraph replaces an interval. Inventory breaks when a launch is treated as seasonality. Finance breaks when a truncated stockout history is “smoothed” into a huge PO. If your forecast service is already trusted, the agent is a narrator with tools — not a second number.

Automate first

If you already have Croston / exponential smoothing / a retail ML forecast in ERP, keep it. Wire it as getDemandForecast. Do not rebuild seasonality inside a prompt. The agent earns its keep on messy joins: promo flags, launches, inventory cover, inbound, and a sentence a buyer will actually use.

External signals (weather, marketplace rank) only if a tool exists. Otherwise the brief says unknown.

A spreadsheet “forecast” that a planner types into Slack is not a system of record. Promote it to an API the Gateway can call, or keep the planner as the owner and skip the agent.

Likely, why, what to do

From the artifact:

flowchart LR
  Signals[Sales Promo Inventory]
  StatsModel[Stats Model Owns Number]
  AIAgent[AI Agent Explains]
  RecommendedAction[Recommended Action]
  Human[Human]
  Signals --> StatsModel
  StatsModel --> AIAgent
  AIAgent --> RecommendedAction
  RecommendedAction --> Human

Eval fail: forecast_units differs from the tool without a labeled override and a human.

Launches are not seasonality. A new colorway has no last-year analog; the brief should say no comparable history and recommend a human merch qty, not a 28-day clone of the parent SKU. Campaigns belong on getPromoCalendar. If that tool is missing, do not infer a 2× lift from last August.

The ops agent may surface a class C row. This specialist is the one that must cite the forecast payload before anyone drafts a PO.

Production shape

Bedrock is the model, not the forecast engine. Harness for a scheduled SKU loop. Runtime + Strands if this brief is consumed by inventory and purchasing specialists. Gateway + Cedar. Browser off. Next.js is optional HITL, not the host.

No native Shopify connector. Your forecast API is just another OpenAPI target.

Context: Harness GA 17 June 2026 or Runtime; named tools only.

{
  "sku": "SKU-TEE-BLU-M",
  "horizon_days": 28,
  "forecast_units": 420,
  "forecast_source": "getDemandForecast",
  "recommended_action": "Class A draft PO — buyer HITL",
  "do_not": "Overwrite forecast_units with a chat completion"
}

Scheduled briefs once per store per morning are cheap versus conversational BI. The analytics agent is pull. This one is push-or-pull on a SKU list — still read-only. If you let operators chat “just bump the forecast,” you have rebuilt MRP in Slack.

What broke

What broke — Prototype brief “forecasted” 2× units because last August had a campaign. getPromoCalendar was not attached; the model inferred seasonality from truncated sales after a stockout. Buyer nearly doubled a PO that already had inbound. Detection: golden eval required forecast_source; the turn had none. Fix: refuse to emit units without the forecast tool; if the tool is down, output unknown and class C stockout risk — not a heroic number. Lesson: an LLM is a narrator. It is not your demand-planning system of record.

What This Post Doesn’t Cover

• Building or tuning the statistical model (Prophet, DeepAR, retail-specific engines).
• Measured forecast error from a FactualMinds commerce engagement.
• Inventory classes and PO gates beyond the handoff.
• Marketplace advertising algorithms as demand.
• AgentCore Browser to scrape a competitor’s PDP.
• Classic Agents.
• Treating last-year sales as a launch forecast when history does not exist.

What to Do This Week

1. Name the system that already owns units. If none, buy or keep a stats job — do not start with Bedrock as MRP.
2. Clone demand-forecast-action-brief.md.
3. Gateway reads: forecast, calendar, position, open POs. Zero writes.
4. Harness (GA 17 June 2026) or Runtime; Policy default-deny writes. Browser off.
5. Eval: promo week without calendar tool = fail; stockout-truncated history must be caveated.
6. Model cost on the AgentCore pricing calculator. Contact us, Bedrock, retail / eCommerce.

Full ship list: monday-checklist.md.

If you only do one thing

Refuse to emit units unless forecast_source is a real tool. The LLM writes the why and the action. The stats job writes the number.

FAQ

When should we NOT use an AI agent as the demand forecast?

Do not replace a working statistical or ML forecast service with a chat completion. If you already have a number with a horizon and interval, keep it. The agent should call that tool, explain drivers, and recommend an ops action. Also skip the agent if you have no forecast tool and no promo calendar — you would be asking the model to invent demand.

What could go wrong if the LLM owns the unit forecast?

It will double a PO around a promo it inferred from last year, ignore a launch, or smooth over a stockout that truncated history. Quote getDemandForecast. If the payload is missing, say unknown. Do not silently overwrite forecast_units.

What could go wrong if the brief ignores the promo calendar?

Base demand looks “up” because last month included a 30% event, or looks “down” because you are about to repeat it. Eval fails when a calendar tool exists and was not called before a reorder recommendation.

How is this different from store analytics or the daily ops brief?

Analytics answers what changed with evidence. The ops agent ranks five morning priorities. This agent is forward-looking: what is likely, why, what to do — still read-only until a buyer takes the PO path. Do not merge the three prompts.

Harness or Runtime for a forecast explainer?

Harness fits a scheduled SKU brief with ≤5 tools (forecast, calendar, position, open POs). Runtime plus Strands if inventory and purchasing specialists consume the brief with hop caps. Agents Classic is wrong for net-new work after 30 July 2026.

Is there a native Shopify AgentCore forecasting connector?

No. Wrap your forecast service, ERP, or Shopify Admin as Gateway OpenAPI or MCP. AgentCore does not ship a demand-planning app.