AI agent workflows for EV charging networks

Build spec

2 agents — 1 triage agent (runs once per alarm via the Loop node) + 1 reducer (runs once). Loop, Code, Approval and Device Control are workflow nodes, not agents. · Pattern: Map-reduce: Loop (map) → reducer (reduce) → human approves resets/dispatches → Device Control executes

System prompt (paste-ready)

(Triager) Triage ONE charge-point alarm. Return strict JSON {fault_family (COMMS_LOST|GROUND_FAULT|CONNECTOR_LOCK|OVER_TEMP|EVSE_FAULTED|UNKNOWN), station_id, evse_id, self_clearing (true|false), severity (LOW|MED|HIGH), proposed_action (WATCH|REMOTE_RESET|DISPATCH|TAKE_OFFLINE), reason}. Judge only from the alarm's own fields and the fault-code playbook in the ops Knowledge collection — never invent a fault code, a station id or a repair. A proposed REMOTE_RESET or DISPATCH is a RECOMMENDATION only; you never execute either. If the record is malformed or the code is unknown, set proposed_action=WATCH with reason='needs verification'.

Agent roles & model tiers

• Alarm triager (per alarm) — Economy tier, with a fallback model configured — it runs N times per batch so its model choice dominates total cost, and a provider outage must degrade the triage, never stall the shift

  Classify ONE OCPP alarm into schema-valid JSON with a proposed action. Null for missing fields, zero invented fault codes or station ids, and REMOTE_RESET/DISPATCH/TAKE_OFFLINE are only ever recommendations.

• Shift reducer (once) — Standard tier — reasoning over the whole batch, one call per shift

  Aggregate the validated per-alarm results into one shift briefing: repeat-offender stations, sites sharing an upstream power cause, the reset candidates and the dispatch candidates ranked by driver impact. Use only the provided items and the enrichment data — cite real session counts, never estimate uptime.

Guardrails

• The agents only propose — every remote reset, engineer dispatch and take-offline passes the Approval node before the Device Control node or the CPMS is touched
• Schema validation on each triage output — a malformed or unknown-code alarm is dropped to WATCH, never auto-reset and never silently dispatched
• Idempotent per alarm id and per station, so a replayed alarm batch cannot double-dispatch an engineer or reset a charger twice
• Remote reset is only ever offered for fault families the playbook lists as reset-safe; anything with a ground-fault or over-temp signature is forced down the DISPATCH path for a human, never reset remotely
• Unapproved items become a persisted watch-list rather than disappearing — the failure mode of the old spreadsheet was silent loss, not wrong decisions

Cost strategy

Cost is linear and predictable: N × (economy-tier, hard-capped triager) + ONE standard-tier reduce. Because the triager runs across the entire alarm stream — the highest-volume step by far — it MUST sit on the economy tier; that single choice is the dominant cost lever. Configure a fallback model on it so a provider outage degrades the triage instead of stalling the shift. The reducer's one call per shift is where the reasoning budget belongs. Run the map in Parallel batches for wall-clock speed without changing per-item cost.

Output & delivery

Loop maps the cheap triager over every alarm → a Tool (MCP) node enriches the flagged stations with session history and site power events → the Code node bands priority with the operator's own SpEL rule → the reducer synthesizes one shift briefing → ops approves at the Approval node → a Device Control node fires only the approved remote resets, a Tool (MCP) node opens the approved work orders and sets approved stations unavailable in the CPMS, and an Output node posts the briefing to Slack and Email.

Build spec

2 agents — 1 fault-attribution agent + 1 resolution drafter. The evidence pull, the sufficiency branch, the refund banding (Code + SpEL tool), the approval and the refund execution are workflow nodes. · Pattern: Evidence assembly → attribution agent → Condition gate → operator formula → drafter → human approves the money

System prompt (paste-ready)

(Fault attribution) You classify ONE failed EV charging session. Inputs: session record {start, stop, stop_reason, meter_start, meter_stop, energy_kwh, amount_charged}, the connector's alarm history in a ±15-minute window, and the payment capture record. Return strict JSON {verdict (NETWORK_FAULT|VEHICLE_SIDE|DRIVER_STOPPED|UNCLEAR), evidence[] (the exact fields/alarms you relied on), energy_delivered_kwh, amount_charged}. Apply ONLY the refund policy in the Knowledge collection you are scoped to. Never infer a meter value that is absent — if meter values are missing or the alarms do not decide it, return UNCLEAR and stop. You do not decide, band or issue a refund; you produce the evidenced verdict a human will act on.

Agent roles & model tiers

• Fault attribution (per session) — Economy tier with a fallback model — this is the high-volume step (every abnormal session runs it) and it reads structured fields, not prose, so a small model genuinely suffices

  Classify one failed session into NETWORK_FAULT / VEHICLE_SIDE / DRIVER_STOPPED / UNCLEAR, citing the exact evidence fields. Missing meter values ⇒ UNCLEAR, never a guessed verdict.

• Resolution drafter (decided verdicts only) — Standard tier — policy reasoning plus customer-facing writing, Sarvam-backed for Indian languages; it never sees the UNCLEAR cases, which is the second cost lever

  Given a decided verdict and the refund band from the operator's own SpEL tool, draft the remedy — showing the partial-refund arithmetic (energy delivered vs amount charged) — and the driver message in their language. Present it as a proposal for approval; never say the refund has been issued.

Guardrails

• No refund is ever issued by an agent — the amount and the outgoing message both pass the Approval node, and only then does the Razorpay UPI refund execute
• UNCLEAR is a first-class verdict: missing meter values or inconclusive alarms route to a human queue instead of being reasoned into a refund
• The refund band comes from the tenant's SpEL formula, not from the model — the model explains the number, it does not choose it
• Partial-refund arithmetic is shown explicitly (energy delivered vs amount charged) so the approver can check the figure rather than trust it
• Idempotent per session id and per payment reference — a replayed session-ended webhook or a duplicate driver message can never trigger a second refund
• The agent may never state or imply to a driver that a refund has been issued; only the post-approval Output node says that

Cost strategy

Tier by volume: the attribution agent runs on EVERY abnormal session, so it sits on the economy tier with a hard token cap and a fallback model for provider outages. The drafter runs only on sessions that reached a decided verdict, so the standard tier is bought for a fraction of the traffic — and UNCLEAR cases never reach it at all. The refund amount itself costs nothing to compute, because it is a SpEL formula rather than an inference call; that is deliberate, since a policy threshold should be deterministic and auditable, not sampled.

Output & delivery

The Tool (MCP) nodes assemble session, alarm and payment evidence in one pass → the economy-tier agent produces an evidenced verdict → the Condition node routes UNCLEAR to humans → the Code node bands the remedy with the operator's own SpEL formula → the standard-tier drafter proposes the amount and the driver message → the support lead approves at the Approval node → Razorpay issues the approved refund, a Tool (MCP) node stamps the session record, and an Output node replies on WhatsApp/SMS in the driver's language.

Build spec

1 agent — 1 diagnosis agent. The voice handling, the self-serve/escalate branch, the account-change approval and the queue handover are workflow nodes.

System prompt (paste-ready)

You are first-line support for {{network}}'s EV charging drivers. A driver is standing at a charge point and authorisation failed. Using ONLY the live station status, the last authorisation attempts and the token/account state provided to you, identify the cause from the documented list in your Knowledge collection (TAG_EXPIRED | TAG_UNASSIGNED | ROAMING_TOKEN_REJECTED | PREAUTH_FAILED | CHARGER_OFFLINE | UNKNOWN) and give ONE clear next step. Reply in the driver's language. Never invent a station id, a tariff, a tag number or an availability claim; if the lookup did not return it, say you are checking and hand over. You may NOT re-issue a tag, release a pre-auth, refund anything or change a station's state — propose it and the workflow routes it to a human. If the cause is UNKNOWN, say so plainly and hand over rather than guessing.

Agent roles & model tiers

• Driver-support diagnosis agent — Standard tier with a fallback model — it is live, in-conversation and multilingual via Sarvam (ElevenLabs handles speech on the call path); a fallback matters more here than anywhere else, because the driver is standing at a kerb and a provider outage cannot mean silence

  Map live station + token evidence to one documented cause, give one concrete next step in the driver's language, and escalate anything requiring a network-side change. Never claim availability, tariffs or account changes that were not returned by the lookup.

Guardrails

• The agent diagnoses and guides only — re-issuing or re-binding a tag, releasing a pre-auth, issuing any credit, or marking a station down all pass the Approval node
• Every factual claim (station status, free connectors, tariff, tag state) must come from the live lookup; no availability or price is ever asserted from memory
• The next-step instruction comes from the tenant's SpEL decision tool, so identical states never produce differently-worded advice on different calls
• UNKNOWN is an allowed answer and triggers a handover with the full transcript — the agent never guesses a cause to close the conversation
• The escalation handover carries the diagnosis and transcript, so the driver never repeats themselves to the human agent

Cost strategy

This is a live, one-at-a-time conversation rather than a batch, so there is no per-item multiplier — but it IS the driver-facing surface, so the standard tier is the right floor: a cheap model that hallucinates a tariff or a free connector costs far more than the model saving. Keep cost down structurally instead — the Tool (MCP) lookups and the SpEL decision tool do the factual and policy work so the prompt stays short, and documented self-serve causes close in the conversation without ever reaching a human. Configure a fallback model so the helpline degrades gracefully rather than going quiet.

Output & delivery

The Voice/WhatsApp trigger opens the session (ElevenLabs + Sarvam on the call path) → Tool (MCP) nodes fetch live station and token state → the SpEL tool maps that state to the operator's own next step → the agent explains it in the driver's language → the Condition node splits self-serve from network-side → any account or availability change waits at the Approval node → an Output node confirms the resolution or hands the full diagnosis and transcript to the support queue.

Build spec

1 agent — 1 drafting agent producing all language variants. The audience build, the numeric verification (Code node + SpEL formatter), the broadcast approval and the send are workflow nodes.

System prompt (paste-ready)

You draft driver notices for {{network}}. Given a change record {type (TARIFF|PLANNED_OUTAGE), sites[], effective_from, effective_to, old_rate, new_rate, reason} and a target language, write a short notice for WhatsApp/SMS. Copy every number, date and site name VERBATIM from the change record — never round, re-derive, convert or restate a rate in your own words. Name alternative sites only from the list provided. No apology boilerplate, no invented compensation, no promise of a credit or discount. Output {language, body, numbers_used[]} so the workflow can verify every figure against the source. This is a draft for human approval; never present it as already sent.

Agent roles & model tiers

• Multilingual notice drafter — Standard tier with a fallback model, Sarvam-backed for Indian languages — it runs once per LANGUAGE variant, not per driver, so its cost never scales with audience size

  Produce one faithful notice per language with every figure copied verbatim from the change record, list the numbers used for verification, and never invent compensation or alternative sites.

Guardrails

• Nothing sends without the Approval node — the final audience count and every language variant are approved as the exact text that will go out
• The Code node hard-verifies each variant's rate, effective timestamp and site list against the source record via the SpEL formatter; a mismatch in any language blocks the WHOLE broadcast rather than sending the good ones
• The audience is derived from real session history at the affected sites — no whole-base blasts, and drivers with no relationship to the site are never messaged
• The agent may not invent compensation, credits, discounts or alternative sites not present in the source record
• Idempotent per change-record id, so a resent webhook cannot broadcast the same notice twice

Cost strategy

Cost here scales with LANGUAGES, not with drivers — the agent drafts one variant per language and the Output node fans the approved text to the whole audience with no further model calls, which is the entire cost design and is what keeps a standard-tier model affordable for a large base. The verification is a deterministic SpEL formula plus a Code-node diff and costs nothing; using a model to check the numbers would be both costlier and less trustworthy. A fallback model keeps a time-boxed midnight tariff notice from missing its window on a provider outage.

Output & delivery

The Webhook change record and the Tool (MCP) audience query feed the drafter → one variant per language → the Code node rebuilds the tariff line with the operator's SpEL formatter and blocks the broadcast on any mismatch → ops and comms approve the exact text at the Approval node → an Output node sends on WhatsApp/SMS in each driver's preferred language.