Demand response and automated dispatch are often discussed as if they are competing approaches to the same problem. They are not. They operate on different timescales, require different enabling infrastructure, and serve different optimization objectives. Understanding the distinction matters for operations teams evaluating how AI forecasting fits into their toolkit.
What demand response is and is not
Demand response is a contracted agreement with large customers to reduce load when the utility requests it. It is a resource, not an automation system. The utility sends a demand response event notice, typically with 1 to 4 hours of lead time, and the customer reduces load according to the contracted terms. The utility does not control what the customer does. The utility activates the resource and the customer responds.
Demand response is most appropriate for handling predictable, scheduled peak events where lead time is sufficient for customers to adjust their operations. It is not appropriate for handling rapid, unpredicted load spikes, because the activation and response cycle is too slow. It also degrades over a season if activated too frequently, because customers start resisting disruptions to their operations.
What automated dispatch is
Automated dispatch, in the distribution context, refers to switching actions, load balancing operations, and direct control of utility-owned assets that happen without requiring individual operator authorization for each action. The classic example is automated feeder sectionalizing that can isolate a faulted section and restore unfaulted sections without dispatcher intervention.
Ampgrove's dispatch recommendations are not automated dispatch in this sense. We generate recommendations that go to operator consoles for human authorization. The recommendation might say: shift 40 MW from feeder A to feeder B via the existing tie switch at substation X, expected to bring feeder A's projected peak from 92 percent of rated capacity to 79 percent. The operator reviews the recommendation and executes it or does not. The automation is in generating and surfacing the recommendation, not in executing the switching action.
How forecasting ties the two together
Better feeder-level forecasting improves both demand response and dispatch recommendation effectiveness. For demand response, a more accurate 4-hour ahead forecast means you activate demand response on the events that actually materialize at levels requiring relief, rather than activating defensively on events that might not develop. That preserves demand response capacity for events that genuinely need it.
For dispatch recommendations, forecast accuracy determines how far ahead the recommendation system can generate actionable suggestions. A recommendation to shift load between feeders that requires a switching operation needs to be generated early enough that the operator has time to review and execute before the load condition develops. A 4-hour ahead forecast with 94 percent accuracy supports recommendations with 2 to 3 hours of execution lead time, which is the window where the operator has meaningful options.
The operator's decision authority
The most important design principle for any AI-assisted dispatch system is preserving unambiguous operator decision authority. The system surfaces recommendations based on forecast conditions. The operator decides whether and how to act. This boundary is not just a regulatory requirement. It is the architecture that makes the system trustworthy: operators who understand exactly what the system is and is not doing are more likely to use it effectively and more likely to escalate appropriately when conditions fall outside the model's experience.
The forecasting accuracy threshold for each strategy
The accuracy level required for effective deployment of each peak management strategy is different. Battery storage dispatch requires the lowest accuracy bar: you need to know a significant peak is coming with reasonable confidence, but being off on timing by 30 to 60 minutes does not ruin the intervention. Demand response requires higher accuracy: you are committing contracted customers to curtailment, so false positive activations matter both financially and for customer relationship management.
Feeder switching recommendations require high accuracy at the feeder level, because a switching operation that moves load between feeders has consequences on both sides of the switch. You need accurate projections for both the sending and receiving feeder to ensure you are not creating a problem while solving the original one. This is why substation-level forecasting is insufficient for dispatch recommendations: the averaging effect hides the feeder-level variance that matters for the switching decision.
Coordinating demand response and dispatch in the same event window
For utilities that have both demand response capability and feeder switching capacity, the question becomes how to stage these resources across the event window. A typical approach based on Ampgrove's pilot experience: at the 4-hour ahead forecast horizon, stage demand response pre-notification if the forecast projects conditions exceeding your activation threshold. At 2 hours, review the updated forecast and confirm or cancel the demand response activation. At 1 hour, execute feeder switching operations based on the near-real-time load picture. This staged approach uses the cheapest available resource first (switching operations have no direct cost) and activates demand response only when switching alone is insufficient.
Coordinating these two resources requires visibility into both the forecast picture and the real-time switching topology. Ampgrove's recommendation engine tracks available tie-switch capacity alongside feeder load projections specifically to support this kind of staged resource deployment. The recommendations it surfaces include projected outcomes for both switching-only scenarios and switching-plus-demand-response scenarios when both options are available.
What utilities in early AI forecasting adoption typically get wrong
The most common mistake we see when utilities first deploy AI-assisted forecasting is treating the forecast as a signal to change behavior immediately, rather than as information to inform the next set of decisions. An operator who looks at a 4-hour ahead overload forecast and immediately activates demand response without reviewing the updated 1-hour forecast is using the system suboptimally. The 1-hour forecast is more accurate, and in many cases the condition that looked alarming at 4 hours has already shifted by the time the 1-hour update arrives.
Good deployment design includes guidance on how to stage decision-making across the forecast horizons available, not just on how to read individual forecast outputs. Operators who understand the accuracy characteristics at each horizon make better decisions than operators who treat all forecast outputs as equally certain. This is part of the operator training component of every Ampgrove deployment, and it is one of the aspects of deployment that takes the most time to get right.