1. Route disruption → multilingual commuter advisory, controller-approved
Today: a vehicle fails on the corridor, the driver phones the depot, the depot phones the control room. The duty controller — already on two phones — types a notice into a WhatsApp broadcast group, then asks whoever is around whether they can put it into Kannada and Hindi. Someone walks a printed sheet to the terminus notice board. Commuters at the twelve stops in between find out by standing there. By the time the third language goes out the diversion has already changed, and nobody remembers to send the all-clear.
Trigger: Webhook (AVL/telematics threshold or control-room incident raise)
How the workflow runs
- Trigger
Disruption is raised. A Webhook trigger fires from the AVL/GPS telematics platform or from the control room's own incident form — route, direction, affected stops, cause, expected duration. Telematics has no first-party connector; it reaches the workflow via Webhook and is read back through a Tool (MCP) node.
- Tool (MCP)
Pull the live service picture. A Tool (MCP) node reads the affected route's current vehicle positions, headway and the published timetable so the draft is grounded in what is actually running, not in a guess.
- Code
Your own severity rule decides the channel. A user-defined SpEL tool the operations team wrote themselves — `disruption_tier` — grades the incident from the delay minutes and the number of affected stops. It is a formula, not a script: the ops team can raise the public-advisory threshold for a monsoon week without a developer or a deployment.
- Agent
Draft the advisory. An Agent node writes a short, factual commuter advisory — what is affected, from which stop to which stop, the alternative (a documented parallel route or interchange from a scoped Knowledge collection), and how long the information is valid for. It writes a draft only.
- Parallel
Translate for the corridor. A Parallel node fans the draft across the languages that corridor actually needs, using Sarvam for Indian languages, keeping the facts identical across every version.
- Approval
Controller approves before anything is published. An Approval node holds the whole bundle — English plus every translation — for the duty controller. Publishing a public advisory, and any statement about cancelling or diverting a service, is a human decision; the agent never publishes.
- Output
Push to commuter channels. On approval an Output node sends the exact approved text on WhatsApp and SMS to commuters subscribed to that route, plus Telegram for the public channel — one advisory, one approved wording, several channels.
Channels & connectors
- Webhook
- SMS / Twilio
- Telegram
- Sarvam (Indian languages)
- Tool (MCP → AVL/telematics + timetable)
- Approval / HITL
Outcome
Within minutes of an incident being raised, the duty controller has a grounded advisory in every language the corridor needs, tiered by the operator's own threshold rule, ready to approve and push — instead of typing it into a broadcast group while running the incident.
Why it helps
The mechanism is preparation, not automation: the drafting, the timetable lookup and the translation all happen before the controller looks at it, so the human spends their attention on whether the message is right rather than on producing it. The severity threshold lives in a SpEL tool the ops team owns, so 'what counts as advisory-worthy' is a setting they change for a monsoon week, not a ticket they raise. Nothing reaches a commuter that a controller has not read and approved.
Build spec
2 agents — 1 drafting agent (once per incident) + 1 translation agent invoked once per target language through the Parallel node. The AVL lookup, the severity formula, the controller approval and the channel push are workflow nodes and tools, not agents. · Pattern: Ground → tier by the operator's own SpEL rule → draft → parallel translate → human approves the whole bundle → publish
System prompt (paste-ready)
You draft commuter service advisories for {{operator}}. From an incident {route, direction, affected_stops[], cause, expected_duration} plus the live AVL/timetable data supplied to you, write a factual advisory of at most 60 words: what is affected, between which stops, the documented alternative from Knowledge, and a validity time. Use ONLY the supplied facts and the published network information in Knowledge — never invent a stop, a replacement service, a restoration time or a cause. Do NOT write reassurance, apology framing beyond one plain line, or any safety instruction. If the incident report is missing route or affected stops, return {draft: null, missing[]} instead of guessing. This is a DRAFT for the duty controller; never state that a service is cancelled or diverted as fact unless the incident record says so.Agent roles & model tiers
Advisory drafter (once per incident) — Standard tier — this is the hard step: it must stay strictly inside the supplied facts under time pressure. Configure a fallback model on a second provider, because an incident is exactly when you cannot afford the primary provider to be having an outage.
Turn the incident record plus live AVL/timetable data into a ≤60-word factual advisory with a documented alternative and a validity time. No invented stops, causes or restoration times. Draft only — never assert a cancellation the record does not contain.
Translator (once per target language, via Parallel) — Economy tier — routes Indian languages through Sarvam; runs N times per incident, so it is the cost multiplier
Translate the controller-bound draft into the target language with the facts, stop names, route numbers and times byte-identical. Do not localise a stop name that has an official published form in Knowledge. Add nothing; drop nothing.
MCP connectors
- AVL / GPS telematics — via Tool (MCP): read live vehicle positions and current headway for the affected route; incident itself arrives inbound via Webhook
- Timetable / scheduling system — via Tool (MCP): read the published trips, parallel routes and interchange points for the affected stop pair
- Passenger-subscription list — via Tool (MCP): resolve which commuters are subscribed to this route and in which language
- WhatsApp / SMS / Telegram — first-party commuter channels for the approved advisory
Built-in tools
- user-defined tool `disruption_tier` (SpEL): input.delayMinutes > 45 ? 'PUBLIC_ADVISORY' : (input.delayMinutes > 15 ? 'ROUTE_NOTICE' : 'LOG_ONLY') — the ops team's own threshold, editable for a monsoon week without a developer or a redeploy
- user-defined tool `advisory_headline` (SpEL): 'Route ' + input.route + ': ' + input.fromStop + ' → ' + input.toStop + ' affected until ' + input.validUntil — the operator's exact house format, so every language version opens identically
- knowledge_search (published network map, parallel routes, interchange rules, advisory style guide — a scoped collection, not the whole corpus)
- http_request (read live vehicle positions and the timetable for the affected route)
Guardrails
- The agent never publishes — the duty controller approves the English text AND every translation at the Approval node before a single message leaves
- No agent ever declares a service cancelled, diverted, suspended or safe to board on its own; it restates only what the incident record and timetable say, and anything beyond that is escalated to the controller
- Advisory content is grounded in the incident record, the live AVL read and the published network data in the scoped Knowledge collection — invented stops, replacement services or restoration times are prohibited by prompt and caught in review
- Severity tiering is a deterministic SpEL formula owned by the operator, not a model judgement — the model never decides how widely a message is broadcast
- Translations are fact-locked: route numbers, stop names, times and the validity window must match the approved English exactly, so approving one bundle really does approve all of it
- Idempotent per incident id — a telematics system that re-fires the same incident does not produce a second advisory blast
Cost strategy
Cost is one standard-tier draft plus L economy-tier translations per incident, where L is the number of languages that corridor actually needs — so translation, not drafting, is what scales. Keep translation on the economy tier (it is a constrained, fact-locked rewrite, not reasoning) and spend the reasoning budget on the single drafting call, which is where an error would actually reach commuters. The `disruption_tier` SpEL tool costs nothing at all and removes the cheapest-to-get-wrong decision from the model entirely. Run translations through the Parallel node for wall-clock speed; that does not change per-language cost.
Output & delivery
Webhook incident → Tool (MCP) reads live AVL and timetable → the `disruption_tier` SpEL tool grades it against the operator's own threshold → the drafting agent produces a grounded ≤60-word advisory → a Parallel node fans translation across the corridor's languages via Sarvam → the duty controller approves the entire bundle at the Approval node → an Output node pushes the exact approved wording to route subscribers on WhatsApp and SMS and to the public Telegram channel.
