Inventory Threshold Monitoring

Run a scheduled sweep of stock levels and sales velocity, and raise a reorder-proposal task whenever an item breaches its configured threshold.

When to use

• You need recurring visibility into stock-outs and slow-moving inventory without a human checking dashboards daily.
• Sales velocity has changed and reorder points need to be flagged before a stock-out hits.
• A warehouse or store location reports low counts and you need to confirm it against the source system before anyone reorders.
• You want reorder decisions proposed for human approval rather than placed automatically.

Tools

• http-get - read current stock levels, sales velocity, and reorder thresholds from the commerce or inventory platform's REST API.
• shell-execute - run local calculations (e.g. days-of-cover, velocity trend) over the data pulled from the API when the platform does not expose a pre-built report.
• schedule-task - set up the recurring sweep (for example, run every morning) so monitoring happens without a manual trigger each time.
• send-message - notify a human or another agent in-session when a breach is detected or when input is needed.
• create-task - open a reorder-proposal task for human approval whenever a threshold is breached.

Playbook

1. On each scheduled run (set up once via schedule-task), call http-get against the inventory platform, e.g. GET https://api.example-commerce.com/v1/inventory/levels, to pull current on-hand quantities for all tracked SKUs.
2. Call http-get again, e.g. GET https://api.example-commerce.com/v1/reports/sales-velocity?window=14d, to retrieve recent sales velocity per SKU.
3. Use shell-execute to compute days-of-cover per SKU (on-hand ÷ daily velocity) and compare against each SKU's configured reorder threshold.
4. For any SKU below threshold or projected to stock out within the org's lead-time window, call http-get on the specific SKU record, e.g. GET https://api.example-commerce.com/v1/inventory/items/{sku_id}, to confirm the figure is current and not a sync lag artifact.
5. If confirmed, open a create-task reorder proposal containing the SKU, current stock, velocity, days-of-cover, and a suggested reorder quantity, and route it to the human owner for approval — never place the order or write the catalog yourself.
6. If no Integration row exists for the inventory platform's host, or a call returns 401/403, stop and use send-message to alert a human, naming the service and the scopes needed.
7. Once the sweep completes, use send-message to post a short summary (SKUs checked, breaches found, tasks opened) to the relevant channel or agent.
8. If the reorder-proposal task requires a catalog write, price change, or refund above the org's configured threshold, do not execute it — the create-task approval gate is mandatory and no autonomous action should follow.

Failure modes

• The inventory platform's API paginates or rate-limits large SKU catalogs, causing partial sweeps that under-report breaches; check for pagination tokens and retry with backoff.
• Sales velocity data lags real-time sales (e.g. batch-updated overnight), producing false stock-out projections; always cross-check against a fresh on-hand read before opening a task.
• Duplicate reorder-proposal tasks get created across consecutive runs for the same SKU; check list-tasks (or equivalent open-task state) before creating a new one for a SKU already pending approval.
• Missing or expired Integration credentials silently fail calls; treat any 401/403 as a hard stop and escalate via send-message rather than guessing at values.

Done when

• The sweep has run on schedule, all tracked SKUs have been evaluated against their thresholds, and a summary has been posted via send-message.
• Every SKU found in breach has exactly one open reorder-proposal task awaiting human approval, with no autonomous reorder, price change, or refund executed.