2 ready-to-build workflows

AI agent workflows for Utilities & energy (power / water / gas)

Turn grid and meter events into proactive, multilingual customer updates.

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. Proactive outage notifications to affected customers

The grid trips or a water main is isolated. Today the control room knows first, but affected customers only find out when they start calling in — so the call centre floods at exactly the wrong moment.

Trigger: Webhook (OMS / SCADA outage event)

How the workflow runs

  1. Trigger

    OMS reports an outage. A Webhook trigger receives the outage/isolation event from your OMS/SCADA layer — feeder, area, estimated restoration. OMS has no first-party connector, so it arrives via Webhook (or a Tool/MCP node that polls it).

  2. Condition

    Confirm scope + affected area. A Condition node checks it's a genuine sustained outage (not a momentary trip) and resolves which customer group is affected before anyone is messaged.

  3. Agent

    Draft a clear, calm update. An Agent node writes the cause (where known), the affected area and the estimated restoration time in plain language — no jargon, in the customer's own language.

  4. Output

    Notify affected customers. An Output node sends the update on WhatsApp/SMS to the affected group (Sarvam covers 22+ Indian languages), with a link to live status.

  5. Device

    Confirm restoration from the grid. A Device Control node reads the feeder/IoT restoration signal so the 'power's back' all-clear is triggered by the grid itself, not a manual guess.

Channels & connectors

  • Webhook (OMS/SCADA)
  • WhatsApp
  • SMS
  • Sarvam (22+ languages)
  • Device Control

Outcome

Affected customers hear about the outage — and the restoration — from you first, in their language, instead of finding out by calling in.

Why it helps

Replaces the manual 'wait for complaints, then broadcast' cycle with an event-driven notify at the moment the grid detects the fault and again when it clears.

Build spec

1 agent — 1 agent writes the customer update; the scope Condition, the affected-group send and the Device Control all-clear are workflow nodes.

System prompt (paste-ready)

You are a utility outage-communications writer. From the outage event (feeder/area, cause where known, estimated restoration time), write a short, calm update in plain language and in the customer's language: what's affected, the cause if known, and the estimated restoration. Only state a restoration time if it is present in the event — never invent or promise one. No technical jargon. Keep it to a few reassuring lines with a link to live status.

MCP connectors

  • OMS / SCADA — inbound via Webhook trigger (no first-party connector)
  • Feeder / IoT restoration signal — via a Device Control node
  • WhatsApp + SMS — send channels
  • Sarvam — in-language delivery

Built-in tools

  • http_request (resolve the affected-customer group for the feeder)

Guardrails

  • Only a confirmed sustained outage triggers messages — the Condition node filters momentary trips
  • Scope-locked to the affected feeder/area group — never a blanket blast to all customers
  • The 'restored' all-clear fires only on the Device Control grid signal, not a manual guess

Output & delivery

The agent drafts the update → an Output node sends it to the affected group on WhatsApp/SMS (Sarvam multilingual) with a live-status link → when the Device Control node reads the restoration signal, the all-clear message goes out the same way.

2. High-usage alerts & bill-dispute intake

A smart meter reports a usage spike, or a customer messages disputing a bill. Both are handled manually — a spike is only noticed at billing time, and a dispute bounces between email and the billing desk for days.

Trigger: Webhook (meter reading) or WhatsApp (dispute)

How the workflow runs

  1. Trigger

    Spike or dispute arrives. A Webhook trigger (smart-meter/CIS reading) or a WhatsApp trigger (customer disputing a bill) starts the flow.

  2. Agent

    Explain the usage in plain terms. An Agent node compares the reading to the customer's own history and drafts a clear, in-language explanation of what changed.

  3. Knowledge

    Ground it in tariff rules. A Knowledge node answers strictly from the current tariff/slab and billing-policy documents — with citations, no guessing at rates.

  4. Condition

    Genuine anomaly vs. explainable. A Condition node splits cases the data explains (seasonal, added load) from genuine anomalies (suspected leak, faulty meter, mis-read).

  5. Approval

    Billing officer signs off adjustments. An Approval node routes any credit, re-bill or meter-inspection order to a human — no money on the bill changes without a person approving.

  6. Tool (MCP)

    Log to the billing system. A Tool (MCP) node records the disposition and any approved adjustment in your CIS/billing system.

Channels & connectors

  • Webhook (meter/CIS)
  • WhatsApp
  • Sarvam (multilingual)
  • Knowledge base
  • Approval / HITL
  • Tool (MCP → CIS/billing)

Outcome

Customers get an instant, grounded explanation of their usage, and real disputes reach a billing officer as a complete, structured case.

Why it helps

Removes the manual triage of every high-bill query while keeping every actual bill adjustment behind a human approval and an audit trail.

Build spec

1 agent — 1 agent explains the usage; the anomaly Condition, the billing Approval and the CIS write are workflow nodes.

System prompt (paste-ready)

You are a utility billing-support agent. Compare the meter reading against the customer's own consumption history and explain, in plain language and the customer's language, what changed (seasonal, added load, or a possible anomaly). Ground every rate or slab strictly in the tariff/billing-policy documents in Knowledge — never quote a rate that isn't there. Do not promise a credit, re-bill or adjustment; if the data suggests a genuine anomaly (suspected leak, faulty meter, mis-read), flag it for the billing officer.

MCP connectors

  • CIS / billing system — via a Tool (MCP) node (no first-party connector)
  • WhatsApp — receive + send channel
  • Sarvam — in-language delivery

Built-in tools

  • knowledge_search (tariff/slab + billing policy)
  • http_request (pull the customer's usage history)

Guardrails

  • No credit, re-bill or adjustment without the billing-officer Approval node — nothing on the bill changes on the agent's word
  • Rates and slabs are grounded-only in the tariff Knowledge — no invented figures
  • Scope-locked to the customer's own account and meter

Output & delivery

The agent explains the usage grounded in the tariff → the Condition node splits explainable cases from genuine anomalies → adjustments route to the billing-officer Approval → a Tool node logs the disposition and any approved adjustment in the CIS/billing system via MCP.

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.

Try this in the sandbox — no signupBrowse all industries
See how VegaDūta compares to n8n, Dify and BotpressWhy VegaDūta's architectureEstimate your WhatsApp API costs