2 ready-to-build workflows

AI agent workflows for Telecom towers & passive infrastructure

Turn site telemetry — mains outage, DG fuel, battery — into a triaged, approval-gated field dispatch, and keep landlord rent & site-access coordination off the phone.

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. Site outage / low DG-fuel alert → triaged, approved field dispatch

A site drops to diesel-generator power and the fuel is running low, or mains fails at an unmanned tower. Today the NOC spots it late on a dashboard, calls around to find a technician, and every dispatch is a chargeable visit approved over WhatsApp with no trail.

Trigger: Webhook (NOC/OSS alarm) or Device Control (site telemetry)

How the workflow runs

  1. Trigger

    Site alarm fires. A Webhook trigger receives the NOC/OSS alarm (mains-fail, DG-on, low-battery). NOC/OSS platforms have no first-party connector — the alarm comes in via Webhook.

  2. Device

    Read live site telemetry. A Device Control node polls the site's power/fuel/battery telemetry (RMS/IoT) to confirm the real state — mains status, DG-fuel level, battery voltage — so the decision is grounded in the hardware, not a stale dashboard row.

  3. Agent

    Triage severity + draft the dispatch. An Agent node classifies the fault (transient blip vs. genuine fuel/mains outage risking downtime), estimates urgency, and drafts the work order — nearest eligible vendor, SLA window, and the chargeable-visit cost line.

  4. Condition

    Only escalate real outages. A Condition node stops on transient/auto-recovered events (log only) and continues only when telemetry confirms a genuine outage or fuel-out risk.

  5. Approval

    Ops approves the chargeable dispatch. An Approval node holds the work order until a human approves — a field visit is billable vendor spend, so it never auto-dispatches. This is the core control.

  6. Output

    Dispatch + confirm. On approval, a Tool (MCP) node raises the work order in the CMMS and an Output node sends the technician the site details on WhatsApp/SMS; the NOC gets the same summary.

Channels & connectors

  • Webhook (NOC/OSS)
  • Device Control (site RMS/IoT)
  • Tool (MCP → CMMS)
  • WhatsApp
  • SMS
  • Approval / HITL

Outcome

A confirmed outage becomes a triaged, costed work order in front of an approver within minutes of the alarm — and the technician is briefed the moment it's approved, with the whole chain logged.

Why it helps

Grounding the call in live telemetry (not a lagging dashboard) plus an approval gate turns 'call around and hope' into a fast, auditable dispatch — the value is detection-to-dispatch speed and a spend trail, not an autonomous dispatch bot.

Build spec

1 agent — 1 triage/dispatch agent. The Device read, Condition, Approval and CMMS Tool node are workflow steps, not extra agents.

System prompt (paste-ready)

You are a passive-infrastructure NOC triage agent. Given a site alarm plus live telemetry {site_id, mains_status, dg_running, dg_fuel_pct, battery_voltage, alarm_type, timestamp}, classify severity as TRANSIENT (auto-recovered / momentary), MONITOR (degraded but stable), or DISPATCH (mains-fail with low fuel/battery risking downtime). When DISPATCH, draft a work order {site_id, fault_summary, suggested_vendor, sla_window, chargeable: true, est_cost_note}. Use only the telemetry provided — never assume a fuel level or invent a site's state. Never mark a dispatch approved; you only propose it for a human. Reply as strict JSON.

MCP connectors

  • NOC/OSS alarm source — inbound via Webhook trigger
  • CMMS / work-order system — via a Tool (MCP) node (no first-party connector)
  • Site RMS/IoT telemetry — via the Device Control node
  • WhatsApp / SMS — technician + NOC notification channel

Built-in tools

  • knowledge_search (site master: access notes, vendor SLA, DG capacity)
  • http_request (nearest-vendor / rota lookup)

Guardrails

  • Every chargeable field dispatch passes the Approval node — the agent proposes vendor spend, a human authorises it before any work order is raised
  • Severity is grounded in the Device Control telemetry read — a transient/auto-recovered alarm is logged only, never escalated to a paid visit
  • Scope-locked to the alarming site: the CMMS Tool node and telemetry read are keyed to that site_id, and each alarm is idempotent so a re-fired alarm never double-dispatches

Cost strategy

The triage agent runs on an economy/standard tier — this is classification over a small telemetry payload, not deep reasoning, so it needs no premium model. Telemetry is read once per confirmed alarm via the Device node; transient alarms are filtered at the Condition node before the agent ever drafts a costly dispatch. The real cost lever is the Approval gate keeping billable visits from firing on noise — model spend here is negligible next to a wasted truck-roll.

Output & delivery

Confirmed-outage JSON → Condition drops transients → the drafted, costed work order goes to the Approval node → on approval a Tool node raises it in the CMMS via MCP and an Output node briefs the technician on WhatsApp/SMS; alarm, telemetry snapshot, approver and dispatch are all logged for the site record.

2. Landlord rent & site-access coordination without the phone tag

A crew needs access to a rooftop/ground-based tower, or a landlord messages about overdue rent or a lease query. Today this is scattered WhatsApp threads and calls — access gets granted verbally, rent commitments get made ad hoc, and nothing is on record.

Trigger: WhatsApp (landlord / crew) or Webhook (access request)

How the workflow runs

  1. Trigger

    Landlord or crew reaches out. A WhatsApp trigger (or an access-request Webhook from the field app) starts the flow — a rent question, a lease query, or a site-access request.

  2. Agent

    Understand + ground the request. An Agent node classifies intent (access request / rent query / lease query) and answers factual questions from the site + lease record — rent due, access hours, contact — in the landlord's language.

  3. Knowledge

    Pull the lease terms. A Knowledge node grounds every rent/access answer in the current lease and site-access policy so nothing is invented or misquoted.

  4. Condition

    Route bindings vs. FYIs. A Condition node lets pure information (next rent date, access window) reply straight away, but sends anything binding — granting access, promising a payment date — down the approval path.

  5. Approval

    Site manager authorises the commitment. An Approval node holds any binding decision (a site-access grant or a rent/payment commitment) for a human — a verbal 'yes' becomes a recorded, authorised one.

  6. Output

    Confirm on WhatsApp. An Output node sends the authorised confirmation — access window + crew details, or the acknowledged rent position — to the landlord and crew.

Channels & connectors

  • WhatsApp
  • Knowledge base
  • Tool (MCP → property/lease system)
  • Approval / HITL
  • Webhook

Outcome

Landlords get an instant, grounded answer on the channel they already use, and every access grant or rent commitment is authorised by a human and recorded — no more verbal-only approvals lost in a chat thread.

Why it helps

Coordination that used to mean phone tag becomes a self-serve, always-on conversation for the factual part, with a human owning only the binding decisions — the value is fewer dropped requests and a real audit trail on access and money.

Build spec

1 agent — 1 coordination agent; the lease grounding, binding/FYI split and site-manager sign-off are workflow nodes.

System prompt (paste-ready)

You are a tower site-coordination assistant for {{company}}. Landlords and field crews message you about rent, lease terms, and site access. Classify each message as ACCESS_REQUEST, RENT_QUERY, LEASE_QUERY, or OTHER. Answer factual questions (next rent date, access hours, permitted contact) ONLY from the lease and site-access record in Knowledge, in the sender's language. Never grant site access, never confirm or promise a rent/payment date, and never agree to a lease change yourself — for anything binding, state that it needs authorisation and hand it to the approval step. Never invent a rent amount, date or access permission not present in the record.

MCP connectors

  • Property / lease-management system — via a Tool (MCP) node (no first-party connector)
  • Site-access request source (field app) — inbound via Webhook trigger
  • WhatsApp — landlord + crew channel

Built-in tools

  • knowledge_search (lease terms, rent schedule, site-access policy per site)
  • http_request (rent-ledger / access-log lookup)

Guardrails

  • Every binding decision — a site-access grant or a rent/payment commitment — passes the Approval node; the agent handles facts only, a human authorises commitments
  • Rent amounts, dates and access permissions are read from the lease record via Knowledge/Tool — the agent never invents or negotiates a figure
  • Access grants are scoped to the requesting crew + a specific window and written back to the access log, so nothing is granted verbally or off the record

Cost strategy

A single standard-tier agent covers this comfortably — it is grounded Q&A plus classification, not multi-step reasoning, so no premium model is warranted. Factual replies (the bulk of traffic) resolve on the first turn without ever reaching the approval path, and only genuine bindings incur a human step; run the agent's simple turns on its economy model via cost routing to keep the always-on channel cheap.

Output & delivery

The agent classifies + answers grounded rent/access questions on WhatsApp; the Condition node lets FYIs reply directly while routing any access grant or rent commitment to the site-manager Approval node; on authorisation a Tool node records it in the property system and an Output node confirms the window/position to landlord and crew.

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