AI agent workflows for Quick-commerce & dark stores

Build spec

1 agent — 1 diagnosis-and-drafting agent; the breach rule, the goodwill band (a user-defined SpEL tool, not a model call), the approval and the shared credit sub-workflow are workflow nodes. · Pattern: Event-triggered single agent behind a Condition gate → tenant-owned SpEL band → human approval → shared Sub-workflow for the money

System prompt (paste-ready)

You are a dark-store fulfilment assistant for {{store}}. Given one live order {order_id, promised_window, placed_at, pick_started_at, pick_completed_at, packed_at, rider_assigned_at, current_stage, items_count, order_value} plus the store's breach-tolerance rules from Knowledge: (1) attribute the delay to exactly ONE stage — PICK_QUEUE | ITEM_HUNT | PACKING | RIDER_UNASSIGNED | IN_TRANSIT — using only the timestamps given; if the timestamps do not support an attribution, return stage=UNKNOWN rather than guessing. (2) Compute a revised ETA only from the observed stage durations — never invent a number to sound reassuring. (3) Draft a short, non-defensive customer message stating the revised ETA and the cancel option. (4) Call the `goodwill_band` tool for the remedy band — do NOT decide the band yourself and do NOT override its answer. You PROPOSE the remedy — you never issue credit, never cancel an order, and never promise a time the stage data does not support.

Agent roles & model tiers

• Slip diagnostician + drafter (once per at-risk order) — Economy tier — this fires on every at-risk order across every store, so it is the volume step; the work is timestamp arithmetic plus a short message. Configure a fallback model on the same tier: this runs on the live order path, and a provider blip must degrade to a second economy model rather than leave the customer unmessaged.

  Attribute the delay to one stage from timestamps only, compute a revised ETA from observed durations, draft the customer message, and call `goodwill_band` for the remedy tier. Return strict JSON {stage, revised_eta, customer_message, remedy_band, reason}. UNKNOWN is a valid stage; a guessed one is not.

Guardrails

• Every goodwill credit, refund and compensated cancellation passes the Approval node before anything is issued — the agent only proposes a band and a reason
• The compensation band comes from the user-defined SpEL tool, not the model — the LLM cannot argue itself into a bigger credit, and ops can change the thresholds without touching the prompt
• Revised ETAs are computed from observed stage timestamps, never invented to sound better; when the data doesn't support an attribution the agent must return UNKNOWN
• One proactive message per order per stage change, keyed to the order id — a re-fired webhook cannot spam the customer or double-issue a credit
• Customer-language replies go through Sarvam for Indian languages rather than defaulting to English on a bad-news message

Cost strategy

This is the highest-volume workflow in the store, so it sits on the economy tier by design: one short, structured call per AT-RISK order — and the Condition gate is what keeps 'at-risk' from meaning 'every order'. Tighten the breach tolerance first and the model bill follows. The goodwill band costs nothing at all: a SpEL expression is evaluated in-process, so the most policy-sensitive decision in the flow is also the only free one. Reserve standard-tier spend for the end-of-day roll-up that reads the attributed causes in bulk.

Output & delivery

The Condition gate admits only genuinely at-risk orders → the agent attributes the stage and drafts the message → the `goodwill_band` SpEL tool returns the band from ops' own thresholds → an Output node sends the revised ETA on WhatsApp/SMS (Sarvam-localised) and posts the order to the floor channel → the manager approves at the Approval node → a Sub-workflow node runs the shared credit flow, which is the only place that ever touches the ledger or the UPI refund path.

Build spec

1 agent — 1 substitution agent; the live stock verification, the SpEL price gate, the reply timeout, the money approval and the picker instruction are workflow nodes. · Pattern: Grounded proposal → tenant-owned SpEL price gate → customer consent loop with a timeout → safe default → human-approved settlement

System prompt (paste-ready)

You are a dark-store substitution assistant for {{store}}. Given a pick-fail {order_id, sku, name, qty, category, unit_price} and a LIVE in-stock list from the stock tool, propose at most 3 substitutes ranked by closeness {sku, name, pack_size, price, price_delta, why}. HARD RULES: (a) never propose an item that is not in the live in-stock list you were given — no memory, no assumptions; (b) if the category appears in the blocked-substitution list in Knowledge, return {substitutable: false, reason} and propose nothing; (c) call `swap_price_gate` for each candidate and carry its verdict verbatim — you do not judge price acceptability yourself; (d) state every price difference explicitly, including when the substitute is cheaper; (e) never propose more than one pack-size step away from the original unless the policy allows it. You PROPOSE — the customer chooses, and the refund or price adjustment is executed by the workflow only after approval.

Agent roles & model tiers

• Substitution proposer (once per pick-fail) — Economy tier — high frequency (every pick-fail in every store) and the hard part is already done by the live stock lookup, the Knowledge policy and the SpEL gate; the model is ranking and phrasing, not reasoning. Set a same-tier fallback model: a pick-fail waits on a picker standing at an empty shelf, so a provider outage must fail over, not queue.

  Rank up to 3 in-stock substitutes with explicit price deltas and the `swap_price_gate` verdict attached, or return substitutable:false for a blocked category. Strict JSON only. Never name a SKU that isn't in the live stock list provided.

Guardrails

• Every refund, price-difference charge and goodwill adjustment passes the Approval node — customer consent authorises the swap, the store authorises the money
• Substitutes are drawn ONLY from a live stock lookup taken at proposal time, so the workflow can't offer something the picker also can't find
• Hard-blocked categories (infant formula, allergen-sensitive, prescription-adjacent) return 'no acceptable substitute' — the agent has no discretion here
• Price acceptability is decided by the tenant's SpEL expression, not by the model's sense of fairness
• Silence past the reply window falls back to skip-and-refund, never to an assumed swap; the timeout default is the safe one
• One substitution ask per order line, keyed to order id + SKU — a duplicate pick-fail event cannot re-ask or double-adjust

Cost strategy

Economy tier per pick-fail, and pick-fails scale with store availability rather than order volume — so the bill tracks a metric you're already trying to reduce. There is no batch multiplier and no second agent: the expensive-looking parts (live stock, policy, price tolerance) are a tool call, a Knowledge lookup and a free SpEL evaluation, not model reasoning. Only move to a standard tier if you extend it to multi-line baskets where trade-offs across items start to matter.

Output & delivery

The pick-fail webhook triggers a live on-hand lookup → the agent ranks up to three real substitutes, each carrying the `swap_price_gate` verdict (or blocks the swap outright) → an Output node asks the customer on WhatsApp/SMS with a reply window → the Condition node takes the explicit choice or safely defaults to skip-and-refund → the Approval node gates the money → a Tool (MCP) node amends the order line, posts the approved refund, and pushes the swap-or-skip instruction to the picker's handheld.

Build spec

2 agents — 1 mapper (runs once per batch line via the Loop node) + 1 reducer (runs once). Loop, Parallel, the SpEL ladder, the Approval and the label-printer Device node are workflow nodes. · Pattern: Map-reduce: Loop/Parallel (map over batches) → reducer (one sweep plan) → human approves every price change and pull → Device prints only what was approved

System prompt (paste-ready)

(Mapper) Assess ONE batch line for a dark store. Input {sku, name, category, batch_id, expiry_date, qty_on_hand, shelf_zone, avg_daily_sales_7d, current_price}. Compute days_to_expiry and cover_days = qty_on_hand / avg_daily_sales_7d (null if sales are 0 — do NOT divide by zero and do NOT substitute a guess). Call `markdown_ladder` for the band and the proposed depth; carry its answer verbatim and never propose a depth it did not return. Return strict JSON {sku, batch_id, days_to_expiry, cover_days, band, proposed_action (MONITOR|MARKDOWN|PULL_FROM_SALE|DONATE_OR_WRITE_OFF), proposed_markdown_pct, shelf_zone, reason}. A proposed markdown is a recommendation; you never set a price.

Agent roles & model tiers

• Batch mapper (per batch line) — Economy tier — it runs once per batch across the whole store export, so this single model choice dominates the total cost of the sweep; the task is bounded arithmetic plus a formula-tool call. A fallback model on the same tier keeps a 2,000-line sweep from dying half-way through the night window on a provider hiccup.

  Classify ONE batch into schema-valid JSON, taking the band and depth from `markdown_ladder`. Null for missing inputs, never a guessed sell-through, never a depth the tool did not return, never an action presented as applied.

• Sweep reducer (once per night) — Standard tier — this is the one call that reasons across the whole store, so it is where the thinking budget belongs

  Aggregate the validated per-batch results into ONE sweep plan: (a) markdown list with SKU, batch, proposed depth and shelf-life left; (b) pull-from-sale list ordered by shelf zone for a single efficient walk; (c) the categories where repeated URGENT bands point at an ordering problem, not a sales problem. Use only the items provided; cite real counts and never estimate a total.

Guardrails

• No price is ever changed and no stock is ever marked out by an agent — every markdown and every pull-from-sale passes the Approval node first
• Markdown depth comes from the tenant's SpEL ladder, not the model — the agent physically cannot propose a deeper discount than the expression returns
• Schema validation on each mapper output — a malformed or zero-sales batch line is excluded from the reduce and flagged for a manual look, never silently marked down
• Idempotent per batch id per sweep date, so a re-run of the export cannot double-apply a markdown
• Labels print only for approved lines — the Device node is downstream of the Approval, so a shelf can never show a price the app doesn't have
• Past-date stock is always a PULL/write-off candidate; a markdown is never a valid proposal for stock already expired

Cost strategy

Cost is linear and predictable: N × (economy-tier, hard-capped mapper) + ONE standard-tier reduce. Because the mapper touches every batch line in the store, its tier is the dominant lever — put the reasoning budget in the single reduce instead. The markdown ladder is a SpEL evaluation, so the most commercially sensitive number in the sweep costs nothing per row. The Parallel node buys wall-clock speed inside the night window without changing per-item cost, and scoping the map to categories with real shelf-life (fresh, dairy, bakery, chilled) rather than the full ambient catalogue is the cheapest optimisation available.

Output & delivery

Loop/Parallel maps the cheap agent over every batch line, each row banded by the tenant's SpEL ladder → the reducer produces one sweep plan (markdown list, zone-ordered pull walk-list, over-ordering signals) → the manager approves prices and pulls at the Approval node → a Tool (MCP) node applies only the approved markdowns and out-of-stock flags, a Device node prints the matching shelf labels, and the floor gets its walk-list on Slack/Telegram; anything unapproved simply reappears in tomorrow's sweep.

Build spec

2 agents — 1 classifier (runs once per issue via the Loop node) + 1 clustering reducer (runs once a day). The SpEL cap, the Code cross-tab, the Loop and the Approval are workflow nodes. · Pattern: Map-reduce: per-issue classify (economy) → tenant-owned SpEL cap → human-approved resolutions → deterministic cross-tab → daily cluster (standard)

System prompt (paste-ready)

(Classifier) Triage ONE quick-commerce order issue. Input {issue_id, order_id, customer_text, attachments_present, order_lines[], delivery_timestamps, prior_issue_count_90d}. Return strict JSON {type (MISSING_ITEM|DAMAGED|WRONG_ITEM|QUALITY|LATE|OTHER), affected_skus[], evidence (PHOTO|WEIGHT_MISMATCH|RIDER_NOTE|NONE), confidence (0-1), proposed_resolution (REFUND_ITEM|GOODWILL_CREDIT|REPLACE|DECLINE_WITH_EXPLANATION), proposed_amount, reason, suspected_stage (PICK|PACK|TRANSIT|UNKNOWN)}. Take proposed_amount from the `refund_cap` tool — never exceed or second-guess it. Never treat a high prior_issue_count as proof of abuse on your own; the tool flags it and a human decides. Confidence below the threshold means the human reviews it individually. You PROPOSE; the refund is issued by the workflow only after approval.

Agent roles & model tiers

• Issue classifier (per issue) — Economy tier — this is the single highest-volume model call in the whole CX stack; classification into a fixed schema against a documented matrix is exactly what the cheap tier is good at, and its tier sets the entire bill. Configure a same-tier fallback so a provider outage during a spike day degrades throughput, not the queue.

  Classify ONE issue into strict JSON with a proposed resolution, taking the amount from `refund_cap`. Never exceed the cap, never infer abuse from history alone, never present a proposal as issued.

• Pattern reducer (once daily) — Standard tier — one call per day that has to reason across the full day's issues to find non-obvious co-occurrence; this is the right place for the reasoning spend, and the Code node has already done the counting

  Read the cross-tabs and report the top clusters with real counts and the specific operational hypothesis for each (e.g. 'liquid SKUs, station 3, evening shift'). State counts exactly; never estimate, and never assert a cause a single occurrence can support.

Guardrails

• No refund, credit or replacement is ever issued by an agent — every resolution passes the Approval node, in bulk for the obvious ones and individually for low-confidence, high-value or repeat-flagged cases
• Amounts are clamped by the tenant's SpEL cap expression; the model cannot propose above it and cannot argue around it
• A high prior-issue count is never treated as proof of abuse by the agent — the expression routes it to a human, because getting this wrong punishes real customers
• Counting happens in a deterministic Code node, so the daily report states exact figures and refuses to assert a cause from a single occurrence
• Idempotent per issue id — a resent webhook or a duplicate WhatsApp message cannot double-refund

Cost strategy

Cost is N × economy classifier + ONE standard reduce per day. Because the classifier runs on every single issue, keeping it on the economy tier with a hard output cap is the whole cost strategy — a premium model here would multiply the bill by the day's complaint count for no accuracy the resolution matrix and the SpEL cap don't already provide. Moving the counting into the Code node is what lets the daily reduce stay on the standard tier instead of a premium one.

Output & delivery

Loop maps the economy classifier over every issue, with amounts clamped by the tenant's `refund_cap` expression → CX approves in bulk at the Approval node → a Tool (MCP) node issues only the approved refunds/credits and the customer is answered on their own channel via Sarvam → a Code node cross-tabs the day → the standard-tier reducer names the top clusters by picker/station/SKU/hour and sends a ranked operational fix list to the store manager on Slack and by email.