1 of 6

AgentX Hackathon 2026 | PS-07 Open track | Idea deck

Discom Message Gate Agent

An agent that decides which alerts and forecasts a power distribution company should act on, before it acts

Primary user: the duty team at a discom (power distribution company)

Replays public hourly data (BDG2: 18 sites, 1,578 buildings); live demo on one site. No personal data.

Pratik Panda |Sparsh Sharma

2 of 6

Who it is for, and why it needs an agent

2

  • User: The duty engineer at a discom. Two desks use it: power procurement (day-ahead purchase) and field inspection (which alert gets a visit today).
  • Problem: Every day they receive forecast updates, outage notices, meter anomaly flags and vendor AI alerts. Some are wrong or stale. Acting on a wrong one wastes a visit or distorts tomorrow's purchase; ignoring a right one lets losses continue.
  • Why not a chatbot: Deciding takes several steps: pull meter and weather data, run a forecast, predict the message's value, check the cost, then create a ticket or propose a schedule change. A chat answer does none of that.
  • Why an agent: It plans those steps itself, calls tools, and asks a human before anything costly.
  • Example (illustrative): At 4 PM a vendor flag says tomorrow's evening load will be 20% above normal. The agent pulls the site's meter and weather, reruns the forecast, finds the weather already explains most of it, and routes the flag to Discount instead of buying extra power.

What a wrong message costs in India

₹5.39 per kWh

average deviation price 2022-23 (₹3.73 a year earlier)

₹40 per kWh

deviation charge in the worst blocks, 2022-23

₹12+ per kWh

Delhi evening peak, 5 to 9 PM, 2021

₹2.16 per kWh lost

on surplus sold off-peak, Rajasthan

~39% of flags recovered money

MSEDCL AI theft detection: 27,964 cases detected, 10,810 recovered ₹29.85 crore (press report)

Sources: CERC Annual Report on Short-Term Power Market 2022-23; CEEW; IEEFA (2020); press report on MSEDCL AI theft detection. ~39% is our rough ratio of the two counts (recovered / detected); the periods may differ.

3 of 6

What the agent does, step by step

3

1. Message arrives

forecast, outage notice, anomaly flag

2. Plan

LLM picks which checks to run

3. Call tools

meter, weather, forecast, helper agents

4. Predict value

gate: beneficial, harmful or negligible

5. Act or ask

accept, verify, discount or ignore; human approves costly steps

6. Log and learn

outcome saved, thresholds updated

Tools the agent calls (real calls on mock and public data)

Tool

Type

What it does

get_meter_data, get_weather

API over replayed BDG2 files

Hourly load, temperature and wind for a site

run_forecast

ML model

Expected load, to judge how unusual a message is

helper agents (4)

Rule agents

Fixed-limit, weather-adjusted, peer and trend messages

gate_predict

LightGBM model

Probability a message is beneficial, harmful or negligible

replay_cost

Simulator

Cost of acting versus not acting, with assumed prices

create_ticket, propose_schedule

Mock APIs

Inspection ticket; draft purchase-plan change (after human approval)

4 of 6

Agent design: planning, tools, memory, guardrails

4

Planning

The orchestrator (an LLM, open or free-tier) reads the message and chooses the next check. A small message that matches the forecast goes straight to the gate; a large or isolated one triggers the forecast, a peer check or a second agent opinion.

Tool use

Six tool groups (previous slide), with typed inputs and outputs. Every call and result is recorded, so each decision can be explained in plain language. If the LLM or a tool fails, the rule agents take over.

Memory

Stores each message, the decision, and what really happened next. Per-site thresholds and the gate are refreshed from this log, so the agent improves with use.

Guardrails

Human confirmation before any schedule change (the costly, irreversible step). Kill switch. Cap on how much of the purchase plan one message can change. Full action log.

The four helper agents are simple rules. The LLM plans and explains; the LightGBM gate makes the prediction.

5 of 6

Demo, data and reliability

5

  • What judges will see: A live dashboard replaying one site (Robin, 51 buildings): messages arriving, the agent's reasoning, its action (accept, verify, discount, ignore), and a running score of money saved against visits made.
  • Against what: Always-act, never-act, a fixed threshold and the message's own confidence. Our result is the gap to these.
  • Data: Public BDG2 hourly meter, weather and metadata (no personal data). Prices, visit cost and the shortfall multiple (1.5× to 3×) are assumptions, shown as a range.
  • Reliability: Seeded replay so the demo is repeatable; tests on the tools; fallback to the rule agents if the LLM fails; every action logged.
  • Demo flow (3 min): replay starts, three messages arrive (one good, one stale, one risky), the agent shows its plan and tool calls, a human approves one schedule change, and the scoreboard shows the gap to the baselines.
  • Success target: about 20% fewer wasted visits than always-act at the same recovered value, across the 1.5× to 3× price range. If the gate does not beat the baselines, we show that too.

Honest limits

  • Data: BDG2 is non-residential US and Europe, not Indian households.
  • Labels: "Worth acting on" is a replay-based proxy.
  • Prices: Assumed, not from a real discom.
  • Messages: Partly simulated; faults are injected.

6 of 6

Impact, innovation and our 24-hour plan

6

  • Impact (illustrative): A mid-size discom with about ₹120 crore a year of deviation cost saves about ₹12 crore from a 10% cut, plus fewer wasted visits. Every input is assumed; the demo measures the real gap.
  • Innovation: Existing tools forecast demand or flag anomalies. The closest idea is security-alert triage (predicting if an alert is actionable), but it is not in energy and has no asymmetric purchase cost. We found no tool that predicts the value of acting on a message before acting, labelled by replaying real data. Not a full literature review.
  • Scope: Core: inspection and day-ahead purchase messages. Later: solar-drop agent and battery.
  • If time runs short: ship one site (Robin) with the naive forecaster. The agent loop, guardrails and dashboard stay; the model upgrades are optional.

24-hour build plan

Hours

Work

0 to 4

Load Robin data; helper agents; forecaster

4 to 10

Replay labels; train and calibrate the gate

10 to 16

Orchestrator agent, tools, guardrails

16 to 21

Dashboard and baselines comparison

21 to 24

Tests, README, 3-minute demo video