Dipp AIDipp AI

Case study · Energy & Utilities

A grid operator held peak agent demand inside a fixed compute envelope

Storm events multiplied agent demand eleven-fold in under an hour. Governed elasticity absorbed the surge without an unbounded bill or a queue of stalled directives.

Electric utility · 6.1m customers · published September 9, 2026

Download the PDFApply for early access

11×

peak surge in agent demand absorbed

March storm event

0

restoration directives dropped or delayed beyond 90 seconds

1.0×

of the pre-agreed cost envelope at peak

ceiling held exactly

40 min → 0

dispatch queue delay at peak

Summary

Outage-management agents at an electric utility were fine on an ordinary Tuesday and catastrophic during a storm. Orcher's elastic compute governance let demand scale with the event while holding a hard ceiling, shedding low-stakes directives first and keeping restoration work at full priority.

Orcher components enforced

  • Cost Governance

    Routes by stakes and halts runaway loops.

  • Observability

    Real-time cross-provider trace: which model, which role, what cost, what outcome.

  • Logic Scrubber

    Verifies the proposed action against systems of record before commit.

Solution: Elastic compute

The situation

What was happening before Orcher.

  • Outage-management, crew-dispatch and customer-notification agents shared one unmanaged capacity pool.
  • During a March storm the pool saturated: customer notifications crowded out crew dispatch, and restoration directives queued for 40 minutes.
  • Provider rate limits produced silent failures that only surfaced in customer complaints.

What Orcher enforced

The control surface, component by component.

  • Directive classes were ranked by restoration impact, and the ceiling was expressed as a total envelope rather than a per-workflow quota.
  • Under pressure Orcher sheds from the bottom of the ranking — notification retries first, dispatch never — and records every shed decision.
  • Cross-provider routing spread the surge across three providers, so one provider's rate limit no longer became an outage in the utility's own operations.
  • Observability exposed the live envelope to the storm-room dashboard, so the incident commander could see agent capacity next to crew capacity.

The data

Measured over the engagement window.

Directive classPriorityPeak volumeShed at peakMax latency
Crew dispatch1 — never shed8,400/hr09s
Outage confirmation221,000/hr022s
Restoration ETA363,000/hr4%71s
Customer notification retry4 — shed first118,000/hr38%deferred
Post-event summary5 — deferrablen/a100%batched after event

Peak hour of the March storm event, measured at the control plane.

Outcomes

What the organisation did next.

  • The utility retired its per-workflow capacity quotas, which had been the cause of the crowding-out behaviour.
  • Storm-room operations now treat agent capacity as a managed resource with a named owner, alongside crews and materials.
  • Post-event reporting is generated from the ledger rather than assembled by hand.
  • The same envelope model was applied to wildfire-risk inspection agents in the following quarter.
“The failure mode was never the model. It was that everything shared one bucket and nothing decided what mattered when the bucket ran out.”
— Director of Grid Operations Technology, electric utility (partner declined attribution by name)

Read further

The research behind this engagement.

Disclosure. Design-partner engagement, anonymised at the partner's request. Figures are measured by Orcher's own observability and ledger instrumentation over the stated period and have not been independently audited. Market figures carry their own source line.

More engagements

Other organisations that had to prove the same thing.

Run this pattern on your own workflow

Design partners deploy Orcher on one directive class, instrument it the way this study was instrumented, and keep the evidence whatever they decide afterwards.

Apply for early accessAll case studies