Yes, an AI agent can improve parts of the CAD operating model. No, the first design goal should not be an autonomous dispatcher.
Dispatch is a chain of time-sensitive tasks: receive information, classify the event, locate it, retrieve context, identify available resources, consider capability and travel time, communicate, update status, monitor changes and escalate. Some of these tasks are information-heavy and repetitive. Others are high-consequence judgements under uncertainty.
Break dispatch into decision components
The word “dispatch” hides several different decisions. An AI system might safely summarise caller information while it would be inappropriate to autonomously downgrade a life-safety incident. It might recommend the nearest suitable resource while a dispatcher retains authority to account for local knowledge, crew safety or an emerging event.
The architecture should map each component to consequence, reversibility and evidence requirements.
Strong early use cases
Context assembly: retrieve prior incidents at the location, known hazards, current road closures and relevant procedures. Classification support: suggest incident type or priority with reasons. Resource recommendation: rank available resources based on capability, proximity and constraints. Communication preparation: draft concise dispatch information. Monitoring: watch for status changes, stale acknowledgements or resource conflicts.
These functions reduce dispatcher cognitive load without removing the dispatcher from consequential choices.
The optimisation function must be explicit
“Send the closest unit” is not an adequate dispatch strategy. The best resource may depend on capability, coverage, expected travel time, fatigue, current workload, station backfill, future demand and safety. If an AI system is recommending resources, the optimisation objective and constraints need to be visible.
Otherwise the organisation may deploy a model that optimises the wrong variable extremely well.
Real-time data quality is part of safety
An agent needs current location, status and capability information. Stale resource data can produce a recommendation that looks rational but is operationally wrong. The system therefore needs freshness indicators and graceful degradation when feeds fail.
AI should make uncertainty visible. If travel-time data is unavailable or a location match is low confidence, that should change the recommendation and trigger human review.
Use the agent as an operational second set of eyes
A particularly useful pattern is continuous monitoring after the initial dispatch. The agent can watch for events that a busy dispatcher might otherwise have to track manually: a unit has not acknowledged, route conditions have changed, another incident now competes for the same specialist resource, or the incident description has materially changed.
This is agentic because the system is continuously observing and reasoning, but the authority can remain bounded.
A safe autonomy progression
- Summarise and retrieve.
- Recommend classification and resources.
- Prepare communications and actions for approval.
- Execute low-consequence administrative actions automatically.
- Continuously monitor and escalate anomalies.
- Only consider broader autonomous dispatch authority where policy, evidence, evaluation and legal accountability are exceptionally mature.
Evaluation must use real operational scenarios
CAD agents should be tested on ordinary work, edge cases, degraded data, conflicting signals and high-pressure scenarios. NIST’s current emphasis on test, evaluation, verification and validation for AI systems is relevant here: impressive average performance is not enough when rare failure modes carry high consequence.
The right ambition is not to remove the dispatcher. It is to give the dispatcher an intelligent operational partner that continuously assembles context, proposes options and watches the system for conditions that need attention.
Dispatch is a constraint problem before it is an AI problem
A dispatch recommendation may need to consider incident priority, unit capability, current location, crew status, coverage obligations, travel time, fatigue, specialist equipment and changing conditions. Some of those are hard constraints; others are optimisation goals. Conflating them inside a generative model makes the decision harder to explain and test.
I would keep deterministic constraints explicit and let AI assist where uncertainty or unstructured context adds value—for example, extracting relevant facts from incoming narrative, explaining a recommendation, or comparing feasible options produced by an optimisation engine. This hybrid approach is easier to evaluate because the system can show which rules excluded an option and which evidence influenced the ranking.
Shadow mode should precede operational authority
Before an autonomous component influences live dispatch, it should run in shadow mode against real operations and record what it would have recommended. That allows comparison with dispatcher decisions and outcomes without operational risk. Differences are especially valuable: sometimes the model is wrong; sometimes it exposes an inconsistent local practice or a constraint not represented in the system.
Design for the moment the data is wrong
CAD data can be stale. GPS may be unavailable. A unit may have a capability that is not correctly recorded. A major incident can invalidate normal coverage assumptions. The safe design is one that detects low-confidence conditions and reduces automation. An agent that knows when it lacks sufficient evidence is more useful than one optimised to always produce an answer.
For executives, the case for AI in dispatch is therefore not “replace the dispatcher.” It is to reduce cognitive load and improve the consistency and speed of feasible-option analysis while retaining clear operational authority.
