2 ready-to-build workflows

AI agent workflows for Mining, metals & natural resources

Turn sensor telemetry into work orders and near-miss reports into a logged, reviewed safety record — while a person always signs off on stopping a machine or closing an incident.

Each recipe below is expressed only in VegaDūta's real workflow building blocks — Trigger, Agent, Knowledge, Condition, Approval, Output, Tool (MCP), Voice, Device, Loop, Code and Parallel — so it maps 1:1 to something you can assemble in the Workflow designer. Consequential actions always pass a human Approval step.

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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)
  • WhatsApp
  • 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 agent1 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.

2. Near-miss & safety-incident reporting with mandatory review

Near-misses get reported verbally at shift-change or on a paper form that sits in a tray — so they're logged inconsistently, categorized differently every time, and the EHS team reconstructs the record days later, if at all.

Trigger: WhatsApp / Voice (worker reports a near-miss or incident)

How the workflow runs

  1. Trigger

    A worker reports it. A WhatsApp or inbound Voice trigger lets a worker report a near-miss or incident in their own language, from the field, the moment it happens.

  2. Agent

    Structure the report. An Agent node turns the free-text or spoken report into a structured record (what, where, when, asset/area, hazard type, people involved) without changing the worker's account.

  3. Knowledge

    Classify against the safety taxonomy. A Knowledge node grounds the hazard type and provisional severity in the site's own safety taxonomy/rulebook, so categories are consistent run to run.

  4. Condition

    Fast-track the serious ones. A Condition node routes anything with an injury or a high provisional severity onto an immediate-escalation path rather than the routine queue.

  5. Approval

    Safety officer signs off — mandatory. An Approval node holds every incident for a qualified safety officer to review, correct the classification and close it. This human sign-off is the non-negotiable control; nothing is filed as reviewed without it.

  6. Tool (MCP)

    Log to the EHS system + confirm. On sign-off, a Tool (MCP) node writes the record to the EHS/incident system and the reporter gets a confirmation with the reference number.

Channels & connectors

  • WhatsApp
  • Voice / Call
  • Sarvam (22+ Indian languages)
  • Knowledge base
  • Tool (MCP → EHS)
  • Approval / HITL

Outcome

Every near-miss is captured the moment it happens, categorized against one consistent taxonomy, and closed only after a safety officer has reviewed it — instead of being lost between the field and the paper tray.

Why it helps

Reporting friction is what suppresses near-miss data; letting a worker report in their own language from the field, then forcing a qualified human review before close, is what makes the record both complete and trustworthy — the sign-off is mandatory by design because closing a safety incident is a consequential decision.

Build spec

1 agent1 report-structuring agent; the taxonomy grounding, severity fast-track, safety sign-off and EHS write are workflow nodes.

System prompt (paste-ready)

You are a safety-incident intake assistant on a mine site. Turn a worker's free-text or transcribed spoken report into strict JSON {reported_at, location, asset_or_area, hazard_type, description, people_involved, injury: boolean, provisional_severity} in the site's own terms. Preserve the worker's account faithfully — never downplay, embellish or resolve it, and never assign blame. Classify hazard_type and provisional_severity ONLY against the site safety taxonomy in Knowledge. You do NOT determine the final severity or close the incident — a qualified safety officer reviews and signs off; your output is a draft for that review.

MCP connectors

  • EHS / incident-management system — via a Tool (MCP) node (no first-party connector)
  • WhatsApp / Voice — reporting channel
  • Voice reports transcribed + replies voiced via ElevenLabs / Sarvam (Indian languages)

Built-in tools

  • knowledge_search (site safety taxonomy + severity rubric)
  • http_request (create EHS incident record)

Guardrails

  • No incident is closed or filed-as-reviewed without the safety officer Approval — the agent only drafts a structured record; a qualified human classifies and signs off
  • Hazard type and provisional severity come only from the site taxonomy in Knowledge — never an invented category, never a severity the rubric doesn't support
  • The worker's account is preserved verbatim in the record — the agent never edits away, minimizes or reinterprets what was reported

Cost strategy

Structuring one report and classifying it against a fixed taxonomy is a light, bounded task, so the intake agent runs on the economy/standard tier — there's no need for a premium reasoning model to transcribe and categorize a single incident. Voice reports add a transcription/synthesis step (ElevenLabs/Sarvam) only on the calls that actually come in, so cost tracks real reporting volume.

Output & delivery

The worker's WhatsApp/voice report → the agent drafts a structured record classified against the site taxonomy → the Condition node fast-tracks injuries/high-severity → the safety officer reviews and signs off at the Approval node → a Tool node writes it to the EHS system and the reporter gets a confirmation reference; the draft, the officer's edits and the final record are all logged.

Related industries

Build one of these in minutes

The sandbox gives you a live agent workspace — no account, no card. Or head back to the full catalogue and compare patterns across every industry.

See how VegaDūta compares to n8n, Dify and BotpressWhy VegaDūta's architectureEstimate your WhatsApp API costs