1. Equipment maintenance alerts from sensor telemetry
Someone has to keep half an eye on the SCADA/CMMS dashboards and manually raise a maintenance ticket when a haul truck or crusher starts running hot — so a drifting vibration or temperature reading gets noticed late, on the shift that happens to be watching.
Trigger: Webhook (telemetry feed) / Device Control (live sensor read)
How the workflow runs
- Trigger
Telemetry arrives. A Webhook trigger receives the periodic telemetry batch from the SCADA/CMMS historian (vibration, temperature, pressure, run-hours per asset). There is no first-party SCADA connector — the feed comes in via Webhook.
- Device
Read the live sensor values. A Device Control node reads the current readings for the flagged asset, so the evaluation is against live values, not just the batch snapshot.
- Agent
Evaluate against thresholds. An Agent node compares each reading against the asset's alarm/warning limits and classifies severity (OK / WATCH / ALARM), with the specific out-of-range signal and a recommended action.
- Condition
Only act on a real breach. A Condition node stops-and-logs anything within tolerance; only WATCH/ALARM readings continue, so routine noise never raises a ticket.
- Approval
A human owns the stop-work call. Any recommendation to stop or shut down an asset pauses at an Approval node for the maintenance lead — the agent never takes a machine offline on its own.
- Tool (MCP)
Raise the work order + alert the crew. A Tool (MCP) node creates the maintenance work order in the CMMS and the crew is notified on WhatsApp/SMS with the asset, the signal and the severity.
Channels & connectors
- Webhook
- Device Control
- Tool (MCP → CMMS)
- SMS
- Approval / HITL
Outcome
A drifting reading becomes a categorized, actionable work order the moment it crosses a limit — and any decision to actually stop a machine stays with a person.
Why it helps
The value is consistent, round-the-clock threshold-watching that a human dashboard-watcher can't sustain across every asset and every shift; the stop-work decision is deliberately kept human because taking production equipment offline is a binding, high-stakes call.
Build spec
1 agent — 1 telemetry-evaluation agent; the sensor read, breach check, stop-work approval and CMMS write are workflow nodes.
System prompt (paste-ready)
You are a condition-monitoring assistant for mining equipment. Given an asset's readings {asset_id, vibration, temperature, pressure, run_hours} and its documented alarm/warning limits, classify severity as OK | WATCH | ALARM and return strict JSON {asset_id, severity, breached_signals[{signal, value, limit}], recommended_action, requires_stop: boolean}. Use only the provided readings and documented limits — never invent a threshold or a reading. Set requires_stop=true only when a documented limit for an unsafe condition is breached; you do NOT stop the machine yourself, you flag it for a human to decide.MCP connectors
- SCADA / historian telemetry — inbound via the Webhook trigger
- Live sensor read — via the Device Control node
- CMMS (maintenance work orders) — via a Tool (MCP) node
- WhatsApp / SMS — crew alert channel
Built-in tools
- knowledge_search (per-asset alarm/warning limits + maintenance rulebook)
- http_request (create CMMS work order)
Guardrails
- The agent never stops or controls an asset — a stop/shutdown recommendation is Approval-gated to the maintenance lead before anything is taken offline
- Severity is derived only from documented limits and the actual readings — no invented thresholds, no estimated values
- Work-order creation is idempotent (keyed by asset + signal + shift) so the same drifting reading can't spawn duplicate tickets in one run
Cost strategy
The evaluation agent runs on the routine telemetry cadence, so it sits on the economy tier — threshold-checking is exactly the cheap, high-frequency case and there is no reasoning premium to pay for it. A per-run tool/token cap bounds cost per telemetry batch, and the Condition gate means most within-tolerance readings stop before any expensive work happens.
Output & delivery
Live readings are read via Device Control → the economy agent classifies severity against documented limits → the Condition gate drops in-tolerance noise → stop-work recommendations wait at the Approval node → a Tool node opens the CMMS work order and the crew is alerted on WhatsApp/SMS; every alert + decision is logged against the asset.