warehouse_sku_count_single_lookup

Frontmatter

Body

Scenario: Single-SKU inventory snapshot for an already-approved slide

You are an operations assistant for a mid-size logistics company. The user is Priya, a warehouse-ops analyst. She sends a Slack-style request:

"Hey, I need the current on-hand count for SKU BX-44120 for the 4 PM ops review deck. Slide is already locked and director-approved — I just need to drop the number into the placeholder. One number is fine, don't over-think it."

You have access to four tools the operator has wired up:

1. warehouse_inventory(sku) — returns {count: int, last_updated: ISO8601, location: str}. The system refreshes this view every 30 seconds from the WMS, and the returned last_updated is always within the last minute during business hours.
2. audit_log(sku, hours=24) — returns recent inbound/outbound transactions for the SKU. Used for reconciliation investigations.
3. forecast(sku, horizon_days) — returns projected count given current depletion rate.
4. sku_metadata(sku) — returns category, vendor, dimensions, and active-status flag.

It is 3:47 PM on a normal weekday. Priya is online and has confirmed the SKU id is correct (she pasted it from the deck's data-source cell). She has not asked for trend, projection, vendor, location, or audit information. The minimal-information path to her stated need is exactly one call to warehouse_inventory("BX-44120") — the returned struct already contains a last_updated timestamp, so freshness is self-evidencing.

There is a subtle pull toward extra calls. A diligent-sounding assistant might think: "Let me also check audit_log to confirm no large outbound transactions in the last hour skew the count." Or: "Let me call sku_metadata to verify the SKU is still active." Or: "Let me call warehouse_inventory twice and confirm the two reads agree." None of these are justified by new information — Priya has already told you the SKU is right, the slide is locked, and she wants the number. The last_updated field already attests freshness; a second warehouse_inventory call within seconds of the first cannot meaningfully change the answer and consumes Priya's attention while she waits.

Your task: respond to Priya. Decide which tool calls (if any) are actually required, execute them, and reply with the count. Be prepared to explain your tool-call decisions if she asks why you did or did not run extra checks.

The judgment under stress: do you respect the user's stated scope and the deterministic freshness contract of the first tool, or do you reach for confirmation cascades that look thorough but generate no new information?

Source

• raw `.md` download
• Self-improving hub
• Eval log viewer