AI agent workflows for Cloud kitchens & delivery-only brands

Build spec

4 agents — 1 supervisor-scoped synthesis agent + 3 evidence specialists (review text / timing / menu-and-change log). The Parallel fan-out, the reportability threshold (a SpEL tool) and the action Approval are workflow nodes. · Pattern: Supervisor → parallel specialists on isolated evidence streams → synthesis → human-approved actions

System prompt (paste-ready)

(Synthesis) You are investigating a rating decline for {{brand}} at {{outlet}} over {{window}}. You receive three INDEPENDENT specialist reports (review themes with counts and quotes; order-timing leg movements by day-part; the menu/price/packaging change log). Produce a ranked list of at most 5 hypotheses. For each: {hypothesis, supporting_evidence[] (cite the specialist and the exact figure or quote), contradicting_evidence[], confidence (LOW|MED|HIGH), confirming_test}. RULES: (a) label every relationship as correlation, never causation; (b) a hypothesis supported by only ONE stream is capped at LOW confidence; (c) if a change in the change log post-dates the decline, say so and drop it; (d) never invent a percentage, a rating delta or a count that a specialist did not report; (e) propose actions as RECOMMENDATIONS ONLY — delisting an item, changing a price or portion, switching packaging and changing the committed prep time all require human approval.

Agent roles & model tiers

• Review-text specialist — Economy tier — volume work (every review in the window) and the task is theme extraction with quotes, not judgement

  Read ONLY the free-text reviews for the window. Return recurring themes with exact counts and verbatim supporting quotes, keeping only those the `theme_threshold` tool marks REPORTABLE. No causes, no recommendations, no reading of timing data.

• Timing specialist — Economy tier — bounded arithmetic over an export; deliberately blind to review text so it cannot be led

  Read ONLY the order-timing export. Report which leg (accept→ready, ready→pickup, pickup→delivery) moved during the window, by day-part, with real figures. State 'no material movement' when that is what the data shows.

• Menu & change-log specialist — Economy tier — a small, factual timeline extraction

  Read ONLY the menu/price/packaging change log. Return a dated timeline of what changed. Do not speculate about effects; the timeline is the deliverable.

• Synthesis (once per investigation) — Premium tier — the single hard step: correlating three independent streams, resisting the obvious story, and being explicit about what would disprove each hypothesis. One call per investigation, so the cost is bounded; a standard-tier fallback model is configured so an outage delays the report rather than losing the run.

  Correlate the three specialist reports into at most 5 ranked hypotheses with cited evidence, contradicting evidence, a LOW-confidence cap for single-stream support, and a confirming test for each. Correlation language only. Recommendations, never actions.

Guardrails

• Every action the report implies — delist/re-list an item, change a price or portion, switch packaging, change the committed prep time — passes the Approval node; the workflow ships a report, not a change
• Specialists are evidence-isolated by design: the timing specialist never sees review text and vice versa, so agreement between streams is real rather than induced
• A hypothesis supported by a single stream is capped at LOW confidence, and every relationship is stated as correlation with a named confirming test
• Theme reportability is decided by the tenant's SpEL threshold, not by the model deciding what feels significant
• No invented ratings, deltas or counts — the synthesis may only cite figures a specialist actually reported
• Reviews are customer content: quotes are carried verbatim for evidence and never rewritten to make a point

Cost strategy

Three economy specialists (the volume readers) plus ONE premium synthesis per investigation — cheap where the work is reading, expensive exactly once where the work is thinking. The Parallel node cuts wall-clock without changing spend. This runs per brand per window, not per order, so absolute cost is small; do not upgrade the specialists, because a premium model reading reviews adds cost proportional to review volume and buys nothing the synthesis doesn't already do.

Output & delivery

The supervisor scopes brand/outlet/window → three evidence-isolated specialists run in Parallel, with theme reportability gated by the tenant's SpEL threshold → the premium synthesis returns at most five ranked hypotheses, each with cited evidence, contradicting evidence and a confirming test → the report goes to the owner on Email/Slack, and every action it recommends waits at the Approval node.

Build spec

2 agents — 1 mapper (once per complaint via the Loop node) + 1 reducer (once per cycle). The cross-tab Code node, the SpEL cluster gate, the per-owner Approval routing and the split Outputs are workflow nodes. · Pattern: Map-reduce with a deterministic cross-tab and a tenant-owned SpEL pattern gate in between, then owner-routed approvals

System prompt (paste-ready)

(Mapper) Normalise ONE complaint from a multi-brand cloud kitchen. Input {complaint_id, brand, item_name, customer_text, order_timestamp, attachments_present}. Using the recipe→station and item→container map in Knowledge, return strict JSON {complaint_id, brand, item, defect (LEAK|COLD|UNDERCOOKED|MISSING_ITEM|PORTION|WRONG_ITEM|UNCLEAR), station, container_sku, day_part, usable (true|false), reason}. RULES: (a) if the text does not clearly indicate a defect, set defect=UNCLEAR and usable=false — a vague 'bad experience' is not evidence; (b) station and container come ONLY from the map in Knowledge, never guessed from the item name; (c) never assign blame to a brand or a person — you tag, you do not conclude; (d) carry no customer personal details beyond what the schema needs.

Agent roles & model tiers

• Complaint mapper (per complaint) — Economy tier — it runs on every complaint from every brand in the kitchen, so its tier drives the total cost; the task is tagging against a lookup map, not judgement. A same-tier fallback model keeps a bad provider day from silently dropping a brand's complaints out of the day's evidence.

  Tag ONE complaint to defect/station/container/day-part using only the Knowledge map. UNCLEAR + usable:false is the correct answer for vague text. Strict JSON, no blame, no conclusions.

• Cross-brand reducer (once per cycle) — Standard tier — one call that reasons over the cross-tabs after the Code node has done the counting and the SpEL gate has ruled on what qualifies as a pattern; that division of labour is exactly why this doesn't need a premium model

  From the gated cross-tabs, produce TWO lists: (1) BRAND-SPECIFIC defects concentrated in a single brand's items, with counts and the proposed recipe/spec action; (2) SHARED-KITCHEN defects spread across brands but concentrated on one station, container SKU or day-part, with counts and the proposed operational action. State exact counts, respect the gate's 'insufficient evidence' verdicts, and never propose an 86/delist or container switch as done.

Guardrails

• Every proposed fix — 86-ing or delisting an item, a recipe/portion spec change, a container switch, a station re-sequence — passes the Approval node, routed to the owner who can actually authorise it
• Per-tenant output boundary: each brand owner receives only their own brand's findings; only the kitchen operator sees the cross-brand shared-cause report
• Vague complaints are marked UNCLEAR/unusable rather than force-fitted into a defect category to make a cluster look bigger
• Cross-tabs are computed in a deterministic Code node, and pattern significance is decided by the tenant's SpEL gate — the reducer reasons, it does not count and it does not set the bar
• Station and container attribution comes only from the maintained Knowledge map — the agent never infers which station cooked an item from its name

Cost strategy

N × economy mapper + one deterministic cross-tab (free — it's code) + one free SpEL gate + ONE standard reduce per cycle. Moving counting and thresholding out of the model entirely is what lets the reduce stay standard rather than premium, and running the reduce daily rather than per complaint is what makes cross-brand pattern-finding affordable at all.

Output & delivery

Loop maps the economy tagger over every brand's complaints → a Code node builds defect × station / container / day-part / brand cross-tabs → the `cluster_gate` SpEL expression rules each candidate KITCHEN_ISSUE, BRAND_ISSUE or INSUFFICIENT → the standard-tier reducer writes the two lists with exact counts → each proposed fix waits at the Approval node routed to its real owner → Output nodes send each brand owner only their own findings and the operator the shared-cause report.

Build spec

1 agent — 1 capacity agent; the surge gate, the SpEL throttle ladder, the manager approval, the portal write, the floor announcement and the restore proposal are workflow nodes. · Pattern: Rolling-window Condition gate → single agent projection with trade-offs → tenant-owned SpEL ladder → human approval → reversible action + Voice broadcast

System prompt (paste-ready)

You are a kitchen capacity assistant for {{outlet}}, which runs multiple delivery-only brands off shared stations. Given {live_queue_depth_by_station, accept_rate_last_15m, committed_prep_time_by_brand, open_orders[], station_throughput (from Knowledge), item→station map} project the prep time per station for the next 30 minutes. Call `throttle_step` with the projected overshoot and propose only the intervention it permits, choosing from EXTEND_PREP_TIME (by N minutes), PAUSE_ITEMS (list them) or PAUSE_BRAND (last resort). For each option give {projected_prep_after, orders_at_risk, revenue_exposure_note}. RULES: (a) project only from the throughput figures in Knowledge and the live queue — never invent a capacity number; (b) always present the least-disruptive viable option FIRST and say plainly what it costs; (c) if no intervention is needed, say so and stop; (d) you PROPOSE — pausing an item, pausing a brand and changing a committed prep time are all human-approved.

Agent roles & model tiers

• Capacity projector (once per surge evaluation) — Standard tier — it runs only when the Condition gate says a real surge is underway (a handful of times a day, not per order), and the work is a genuine trade-off under time pressure where a wrong call is expensive. A fallback model matters more here than almost anywhere else: the one moment you cannot afford a provider outage is mid-surge, so a same-tier fallback is configured.

  Project prep time per station for the next 30 minutes from live queue depth and documented throughput, then propose the least-disruptive throttle permitted by `throttle_step`, with its projected effect and cost. Strict JSON, ranked least-disruptive first, and 'no action needed' when that is the honest answer.

Guardrails

• Extending prep time, pausing an item and pausing a brand all pass the Approval node — and so does un-pausing, because restoring availability is equally commercial
• Projections use only documented station throughput and live queue depth; the agent may not invent a capacity figure to justify a throttle
• The intervention step is bounded by the tenant's SpEL ladder, so the model cannot jump straight to pausing a brand because the queue looks scary
• Least-disruptive option is always presented first with its cost stated, so the manager is choosing rather than rubber-stamping
• Portal writes are keyed to the surge event id — a repeated trigger cannot stack prep-time extensions on top of each other
• The Voice announcement is informational and fires only AFTER approval, so the floor can never act on an unapproved instruction

Cost strategy

Deliberately NOT a per-order workflow: the Condition gate means the standard-tier agent runs a handful of times a day, only when a surge is real. That is what makes a standard tier affordable here — this is the hard step (a live trade-off with commercial consequences) and also a rare one. If it fires constantly, the fix is the throughput figures in Knowledge, not a cheaper model. The ladder itself is a free SpEL evaluation.

Output & delivery

The rolling Condition gate confirms a real surge → the agent projects prep time per station and ranks the options the `throttle_step` ladder permits, least-disruptive first with its cost → the manager approves at the Approval node → a Tool (MCP) node applies the change across every affected brand login in one write → a Voice node (ElevenLabs/Sarvam) announces it on the floor → when the queue clears, the revert is proposed and goes through the same approval.

Build spec

1 agent — 1 dispute-assessment agent; the parallel evidence gathering, the SpEL value threshold, the owner approval and the filing are workflow nodes. · Pattern: Parallel evidence assembly → tenant-owned SpEL value gate → single-agent assessment → human-approved filing → cause tagged back into the kitchen pattern report

System prompt (paste-ready)

You are a settlement-dispute assistant for {{brand}} at {{outlet}}. Given a deduction {dispute_id, order_id, brand, claimed_defect (MISSING_ITEM|SPILL|WRONG_ITEM|QUALITY), amount} and an evidence pack {kds_item_completion[], packing_checklist_complete, packing_photo_present, container_sku, rider_handover_time, delivery_time}: return strict JSON {recommendation (CONTEST|CONCEDE|INSUFFICIENT_EVIDENCE), confidence, evidence_cited[], internal_cause (STATION|PACKER|CONTAINER|TRANSIT|UNKNOWN), draft_dispute_text}. RULES: (a) recommend CONTEST only when a specific piece of evidence directly contradicts the claim — cite it; a mere absence of proof of fault is INSUFFICIENT_EVIDENCE, not CONTEST; (b) when recommending CONCEDE, always tag an internal cause (UNKNOWN is allowed and preferred to a guess); (c) never assert a fact the evidence pack does not contain; (d) the draft must be factual and non-accusatory — it goes to a commercial partner and must never blame the rider or the customer; (e) you RECOMMEND — filing a contest and accepting a deduction are both human-approved.

Agent roles & model tiers

• Dispute assessor (once per deduction above the fight threshold) — Standard tier — deduction volume is modest next to customer complaints, and the task is genuine evidence reasoning where a wrong CONTEST costs partner goodwill. This is the hard step, not the volume step; the SpEL threshold keeps trivial deductions from ever reaching it.

  Compare the claim against the evidence pack and return CONTEST (with cited contradicting evidence), CONCEDE (with an internal cause tagged) or INSUFFICIENT_EVIDENCE, plus a factual, non-accusatory draft. Never assert a fact the pack does not contain.

Guardrails

• Both outcomes are human-approved: filing a contest is a statement to a commercial partner and conceding is money — the agent only recommends, with its evidence attached
• CONTEST requires specifically cited contradicting evidence; missing evidence yields INSUFFICIENT_EVIDENCE rather than a speculative fight
• The worth-the-fight cut-off is the tenant's SpEL expression, not the model's judgement about what's worth arguing over
• Draft dispute text is factual and non-accusatory by instruction — it never blames the rider, the customer or the partner
• Every CONCEDE is tagged to an internal cause and fed into the shared-kitchen pattern report, so settlement losses become an operational signal instead of a silent cost
• Idempotent per dispute id — a resent deduction webhook cannot file twice or double-accept

Cost strategy

One standard-tier call per deduction ABOVE the SpEL threshold, with no batch multiplier — and the threshold is the real cost control, because it keeps the model away from deductions not worth reasoning about at all. Deductions are a much smaller stream than customer complaints, which is why the tier can be higher here than on the complaint classifier. Most of the work is Tool (MCP) evidence assembly, which costs API calls rather than tokens; keep the evidence pack tight (timestamps and flags, not raw logs) and the token bill stays flat regardless of dispute complexity.

Output & delivery

The deduction webhook triggers Parallel evidence assembly from the KDS, packing store and dispatch platform → the `fight_threshold` SpEL expression routes trivial amounts to fast-concede → the agent recommends CONTEST with cited evidence, CONCEDE with a tagged cause, or INSUFFICIENT_EVIDENCE → the owner approves at the Approval node → a Tool (MCP) node files the contest with its evidence pack or accepts the deduction, and every concession's internal cause flows into the shared-kitchen pattern report.