1. Milestone & ETA updates with demurrage / detention alerts
A coordinator refreshes carrier and port portals all day, then emails consignees when a vessel slips or a box lands — and free time on containers quietly runs out before anyone flags the demurrage and detention risk, so charges land as a surprise.
Trigger: Webhook (carrier / port EDI milestone event)
How the workflow runs
- Trigger
Milestone event arrives. A Webhook trigger receives each tracking/EDI event (gate-in, loaded, sailed, discharged, gated-out). Carrier and port systems have no first-party connector — the EDI/tracking feed pushes in via Webhook (or a Tool/MCP node that polls their API).
- Knowledge
Load the shipment's free-time terms. A Knowledge node holds the booking's free-time / detention rules and the consignee's contacts, so the flow reasons against this shipment's actual terms — not a generic guess.
- Condition
Only act when it's material. A Condition node branches: a routine event is logged; an ETA slip, an arrival, or a container nearing the end of its free time continues to the outreach path — including a demurrage/detention warning window.
- Agent
Write the update + the warning. An Agent node turns the raw event into a plain-language update for the consignee, and — where free time is running short — a clear demurrage/detention heads-up with the last-free-day and the action needed.
- Output
Notify the consignee proactively. An Output node reaches the consignee on WhatsApp/Email/SMS before they chase you — and before the charge clock runs out.
Channels & connectors
- Webhook (carrier/port EDI)
- Knowledge base
- SMS
Outcome
Consignees hear about every milestone, ETA change and looming demurrage window from you first, in time to act — instead of chasing a coordinator or discovering a charge after the fact.
Why it helps
Replaces all-day manual portal-watching with event-driven, terms-aware alerts; the value is catching the free-time deadline before it becomes a charge, not a hands-off ops bot.
Build spec
1 agent — 1 update-writer agent; the free-time reasoning and the materiality branch are Knowledge and Condition nodes, not extra agents.
System prompt (paste-ready)
You are a freight status assistant. Given a shipment milestone event {shipment_ref, event_type, event_time, location, current_eta, last_free_day?} and the shipment's free-time terms from Knowledge, write a short, calm update for the consignee in their language. If the container is within the demurrage/detention warning window, state the last free day and the specific action needed, clearly. Never invent an ETA, a charge amount, or a last-free-day that isn't in the input or Knowledge — if a value is missing, say it's being confirmed. Do not promise a delivery date the carrier hasn't given.MCP connectors
- Carrier / port EDI + tracking — inbound via Webhook trigger (no first-party connector)
- Forwarding TMS lookup — via a Tool (MCP) node
Built-in tools
- knowledge_search (free-time / detention terms + consignee contacts)
- http_request (pull shipment detail)
Guardrails
- No invented ETAs, charges or last-free-days — the agent only relays values present in the event or Knowledge, else it defers ('being confirmed')
- Materiality gate at the Condition node — routine events are logged, not messaged, so consignees aren't spammed on every gate scan
- Idempotency on event id — a re-sent EDI event never double-notifies the consignee
Output & delivery
Milestone event → Condition filters for material changes + demurrage-window risk → the agent's update text is sent on WhatsApp/Email/SMS within seconds, keyed idempotently on the event id, with the raw event stored for audit.
