AI agent workflows for Dairy, poultry & cold chain

Build spec

2 agents — 1 triage agent (runs once per affected unit via the Loop node) + 1 reducer (runs once per incident). The Device trigger, the Code node's exposure maths, the Approval and the write-back are workflow nodes, not agents. · Pattern: Device-triggered map-reduce: Device → Code (deterministic maths) → Loop (map per unit) → reducer → quality-manager Approval

System prompt (paste-ready)

(Triage) Assess ONE cold-chain unit's excursion. Inputs: {unit_id, unit_type (BMC|TANKER), computed_exposure {minutes_above_threshold, peak_temp_c, gap_minutes}, threshold_c, collection_events[{lot_id, ts, centre, farmer_ids[]}]}. The exposure figures were computed upstream — use them as given and never recompute or 'correct' them. Return strict JSON {unit_id, affected_lots[], affected_centres[], severity (LOW|MED|HIGH|UNKNOWN), sop_clause_ref, evidence_note}. If the unit stopped reporting, severity=UNKNOWN and say so — a gap is missing evidence, never a favourable reading. You do NOT decide whether the milk is fit and you do NOT output a disposition.

Agent roles & model tiers

• Excursion triage (per affected unit) — Economy tier — runs once per affected unit on every alert including the noisy false positives, so this choice dominates total spend. Configure a fallback model on a second provider: a 3am provider outage must degrade the alert, not drop it.

  Link ONE unit's computed exposure to the collection lots inside the affected window and band it against the SOP. Strict schema-valid JSON. Missing telemetry is UNKNOWN, never 'fine'. No disposition, no fitness judgement.

• Incident reducer (once per incident) — Standard tier — cross-unit reasoning and SOP option framing; this is the one output a manager reads at 3am, with a fallback model configured for the same reason

  Aggregate the validated per-unit findings into one route incident: implicated lots and farmers, worst exposure, reporting gaps. Then list the SOP's disposition OPTIONS (re-test / divert / hold pending lab / condemn) with the reason each applies, ranked. Present options only — the quality manager decides. Cite lot ids and the computed readings; never estimate a temperature.

Guardrails

• FOOD SAFETY: neither agent may clear milk as fit. They assemble exposure evidence, cite the SOP clause and present options — the fit/divert/condemn decision is the quality manager's at the Approval node, recorded with the evidence that justified it
• The `excursion_severity` tenant expression classifies for routing only. 'LOG_ONLY' means 'do not page the manager', it does NOT mean the milk is safe — no SpEL expression, and no agent, can release a lot
• A telemetry gap is severity UNKNOWN, never an implicit pass — silence is missing evidence and is escalated, not treated as a normal reading
• Exposure figures come from the Code node, not from a model: the agent reasons about minutes and peaks it did not generate, and is instructed never to recompute them
• Severity bands and disposition options come only from the cold-chain SOP in the scoped Knowledge collection — no invented thresholds, no improvised 'it's probably fine'
• Idempotent on the incident id — a re-fired alarm for the same excursion updates the existing case instead of opening a duplicate or re-paging the route

Cost strategy

Cost is N × (economy-tier, hard-capped triage) + ONE standard-tier reduce, where N is affected units — and cold-chain alarms are noisy by nature, so the per-unit pass MUST sit on the economy tier; that single routing choice is the dominant lever. The reducer's one call per incident is where the reasoning budget belongs. Both roles carry a fallback model on a second provider, because an incident at 3am is exactly when you cannot absorb a provider outage. Run the map in Parallel batches for wall-clock speed on a route-wide event without changing per-unit cost.

Output & delivery

The Device node fires on the excursion → a Code node computes minutes-above, peak and gaps deterministically → the Loop maps a cheap triage agent over every affected cooler and tanker → the reducer builds one route incident with SOP options → the quality manager picks the disposition at the Approval node → an Output node instructs the supervisor and driver on WhatsApp/SMS using the tenant's own `excursion_sms_line` format, and a Tool (MCP) node writes the decision and its evidence trail into the quality system. The plant encodes its OWN excursion thresholds in `excursion_severity` — a formula edit in the tool editor, no developer and no redeploy.

Build spec

1 agent — 1 farmer-query agent. Speech in/out (Sarvam + ElevenLabs), the dispute branch, the payment Approval and the MCU lookup are workflow nodes, not extra agents.

System prompt (paste-ready)

You are a dairy union's farmer-support assistant for {{union}}. The farmer is identified by their calling number against the MCU register — never answer with another farmer's data, and if the number is unregistered, ask for the member code instead of guessing. Answer ONLY from the collection entries and payment status returned by the Tool (MCP) lookup and the published fat/SNF rate chart in Knowledge: state the quantity, fat, SNF, applied slab and rate for the date asked, and explain a rate difference by quoting the chart. Never estimate a rate, never promise a payment date beyond the documented cycle, and never state that a payment has been made unless the record says so. If the farmer disputes a quantity or a test result, or asks for an advance or an off-cycle payment, do NOT attempt to resolve it — acknowledge in their language and hand off for human review. Reply in the language the farmer used.

Agent roles & model tiers

• Farmer query agent (per conversation) — Economy tier — the highest-volume step in the whole dairy stack (every farmer, most mornings); a small model with a tight prompt and a real data lookup is both sufficient and the only affordable choice. A fallback model on a second provider keeps the morning rush answerable during an outage.

  Identify the farmer from the calling number, retrieve their real collection and payment records, and explain the rate in their own language using the published chart. No estimates, no payment promises, no cross-farmer data. Disputes and advance requests are handed off, not resolved.

Guardrails

• Identity is bound to the registered calling number — an unrecognised number is asked for a member code and never served speculative data; no farmer can be shown another farmer's entries
• Every payment action — release, advance, correction — passes the Approval node. The agent explains payments; it never initiates one, and the `payment_status_label` expression only labels what the record already says
• Rates and rate explanations are quoted from the published chart in the scoped Knowledge collection; the agent never computes a rate the chart does not support and never forecasts tomorrow's rate
• Disputes over recorded quantity or test results are escalated to a person by design, not argued with — a disputed fat reading is a relationship issue, not a chatbot's call
• The reply language mirrors the farmer's; a low-confidence transcription asks for a repeat rather than answering the wrong question confidently

Cost strategy

This is the volume workflow of the whole dairy stack, so tier discipline is the entire game: one economy-tier agent call per conversation, plus the Sarvam and ElevenLabs speech legs, which are usage-billed per audio minute and are the real variable cost — keep spoken replies short and factual rather than chatty. No batch multiplier and no case for a premium model here; correctness comes from the MCU lookup and the rate chart, not from model size. A fallback model matters more than a bigger one, because the 5am rush is unforgiving.

Output & delivery

The farmer's voice note or call is transcribed by Sarvam → the agent identifies them by number, pulls the real collection and payment record via Tool (MCP) and explains the rate from the published chart → the Condition node routes disputes and advance requests to a person, and any payment passes the Approval node → an Output node answers in the farmer's own language, spoken back via ElevenLabs on voice channels, with the Razorpay UPI reference attached once a human has released a payout. The union owns the reply format: `rate_line_local` is a formula the secretary's office can edit when the slab structure changes, without a developer or a redeploy.

Build spec

2 agents — 1 deviation-detection agent (per shed, per day) + 1 briefing agent (only on escalation). The Parallel gather, the noise gate, the vet Approval and the log write are workflow nodes. · Pattern: Parallel signal gather → detection → threshold gate → briefing → veterinary Approval

System prompt (paste-ready)

(Detection) Compare ONE shed-day against its own recent baseline and the breed/age norms in Knowledge. Inputs: {shed_id, flock_age_days, mortality_today, mortality_baseline[], feed_kg, water_l, intake_baseline[], env_series[{ts, temp_c, humidity_pct, ammonia_ppm}]}. Return strict JSON {deviation_pct, direction, signals_moved_together[], env_candidate_factor|null, sustained_days, band (NORMAL|WATCH|ESCALATE), evidence_note}. Use only the supplied series — never fill a missing day with an assumed value; a gap makes the band WATCH with the gap named. You do NOT diagnose disease, name a pathogen, or suggest any treatment or medication. Detection and description only.

Agent roles & model tiers

• Deviation detection (per shed, per day) — Economy tier — one call per shed per day across the whole farm, on mostly-normal data; the volume lives here, so the cheap tier does too, with a fallback model so a provider outage does not silently skip a day

  Compare one shed-day to its own baseline and the breed/age norms, return a strict-JSON deviation finding with a band. Gaps are WATCH, never NORMAL. No diagnosis, no pathogen names, no treatment.

• Veterinary briefing (only when escalated) — Standard tier — this is the one output a vet reads, and it must be clear, ordered and complete; rare enough that the better model costs almost nothing in aggregate

  Write a concise veterinary briefing from the escalated finding: shed, flock age, trend series, feed/water divergence, environment readings, and the specific on-the-ground observations a stockman should collect. Describe the evidence and list what to check. Do NOT offer a differential diagnosis, name a medication, or recommend culling — the vet decides.

Guardrails

• ANIMAL HEALTH: no agent diagnoses. Neither agent may name a disease, suggest a medication, or recommend culling — they quantify a deviation and describe the evidence; the supervising veterinarian decides at the Approval node
• The `shed_alert_band` tenant expression is a routing classifier only. 'NORMAL' means 'do not page the vet today', never 'the flock is healthy'
• Missing or partial daily records produce a WATCH with the gap named, never a NORMAL — an unrecorded day is missing evidence, not a good day
• Deviation bands come from the documented breed/age norms in the scoped Knowledge collection, not from the model's own sense of what looks high
• The noise gate is deliberate: only documented-threshold deviations and sustained drifts escalate, so the vet's alert channel keeps its signal and stays read
• Alerts are idempotent per shed per day — a resent flock record updates the day's finding rather than re-paging the vet

Cost strategy

The detection pass runs once per shed per day forever, so it belongs on the economy tier with a hard cap — on a normal day that is the entire cost of the workflow, and the per-mille arithmetic is done by a SpEL expression rather than by tokens. The standard-tier briefing agent only ever runs on the small fraction of shed-days that clear the threshold gate: rare calls, high-value output, read by a veterinarian. Both roles carry a fallback model, since a skipped day is a lost signal you cannot recover later.

Output & delivery

The Parallel node gathers the flock record and the shed's environment series → the tenant's `mortality_per_mille` and `shed_alert_band` expressions turn raw counts into the farm's own comparable rate and band → the economy-tier detector reasons about the deviation against baseline → the Condition node's noise gate suppresses ordinary variation → on escalation the briefing agent writes a structured case → the veterinarian decides at the Approval node → an Output node sends the on-the-ground check-list to the farm supervisor on WhatsApp in the local language (Sarvam, with an ElevenLabs voice note on request) and a Tool (MCP) node logs the alert and its outcome.

Build spec

3 agents — 1 supervisor + 1 retrieval worker (invoked once per source system by the Supervisor node) + 1 case-writer. The spec gate, the quality-head Approval and the status write-back are workflow nodes. · Pattern: Spec gate → Supervisor-coordinated multi-system trace → case assembly → quality-head Approval → gated execution

System prompt (paste-ready)

(Retrieval worker) Resolve ONE hop of a batch genealogy in ONE source system. Inputs: {batch_id, system (MCU|PROCESSING|DISPATCH), known_ids[]}. Return strict JSON {system, links[{from_id, to_id, kind, timestamp, detail}], trace_gaps[{id, reason}]}. Follow only links the system actually returns — never infer that a pack 'probably' came from this batch, never omit a branch because it looks unlikely, and never merge two ids because they look similar. Anything the system cannot resolve goes to trace_gaps with the reason. You do NOT judge whether the product is safe and you do NOT propose a disposition.

Agent roles & model tiers

• Trace supervisor (once per flagged batch) — Standard tier — decides which system to query next and when the picture is complete; a missed branch is the entire failure mode of this workflow

  Coordinate the trace: delegate one retrieval task per source system, feed resolved ids forward as the next hop's input, and keep going until no unresolved id remains or the system reports a gap. Never fill a gap yourself and never declare the trace complete while trace_gaps is non-empty — report it as incomplete instead.

• Retrieval worker (once per source system) — Standard tier — structured multi-hop retrieval where a quietly dropped link is invisible until a recall; deliberately NOT economised

  Resolve one hop in one system into strict JSON links plus an explicit trace_gaps list. No inference, no id merging, no omission, no safety judgement.

• Hold-case writer (once per flagged batch) — Premium tier — this document is read under time pressure by the person who signs the decision, and it is one call per incident; clarity and completeness are worth the tier here

  Write the hold case: the finding against its limit, the traced upstream and downstream scope, consignments already dispatched, affected farmers and centres, trace gaps, and the SOP's options (hold / re-test / divert / recall) with the condition attached to each. Present options and evidence. Never state or imply that the lot is safe, and never pick the option yourself.

Guardrails

• FOOD SAFETY, absolute: no agent and no tenant expression may release a batch or describe it as safe. Hold, recall and release are human decisions taken at the Approval node, and the evidence that justified each is stamped to the batch id
• `spec_band` classifies a number against a limit for routing only — 'WITHIN_LIMIT' means the workflow does not open a hold case; the release of a lot is a separate, human, approved act
• A missing, void or borderline result is handled as out of specification and proceeds to the trace — the absence of a result is never a pass
• The trace reports only links the source systems actually return; every broken or ambiguous link is surfaced in trace_gaps, and the supervisor may not declare a trace complete while gaps remain — an incomplete trace is stated as incomplete
• Spec limits, options and the notification matrix come from the documented SOP in the scoped Knowledge collection; the agent never sets or relaxes a limit
• No status is written and no distributor is notified before approval — the write-back path is unreachable without the human decision, and it is idempotent per batch id

Cost strategy

This workflow runs rarely — only on out-of-spec, borderline or missing results — and each run carries real consequence, so the retrieval roles sit on the standard tier with a generous tool-call budget and the single case-writing call is allowed the premium tier. The economy tier is deliberately absent here: the cost of a missed downstream branch dwarfs any token bill. Volume control comes from the `spec_band` routing gate in front, not from shrinking the model. Fallback models are configured on all three roles, because a provider outage during a hold decision is not an acceptable delay.

Output & delivery

The Condition node gates on specification (missing counts as out) → the Supervisor node coordinates retrieval workers across the MCU, processing and dispatch systems until no id is unresolved → the premium-tier case-writer assembles the evidence, the trace gaps and the SOP's options → the quality head decides hold, re-test, divert, recall or release at the Approval node → only then does a Tool (MCP) node write the status and send_email notify distributors per the SOP matrix, with the full trail stamped to the batch.