The problem
A regional HVAC and facilities company runs about 40 technicians across six service areas, roughly 180 jobs a day. One dispatcher built the schedule every morning in a whiteboard- and-spreadsheet ritual, then spent the day tearing it up as emergency no-heat calls came in. Good days depended on that one person's memory of who was near what and who was good at which equipment.
The design principle
The agent proposes, the dispatcher commits. It can build a full schedule and rebuild it on every new call, but nothing is dispatched and no customer is messaged until a person clicks confirm. The goal was to give the dispatcher a strong first draft and fast what-ifs, not to remove them.
Architecture
The system runs in the client's own AWS account. They already had an ops team and a compliance reason to keep customer and technician data in their boundary, so we provisioned it as Terraform, wired it to their existing Grafana, and handed over the repository and runbooks. Their team operates it; we are on call.
- A queue-and-worker runtime, event-driven — a new job, a cancellation, or a technician running late all trigger a re-plan.
- A supervisor agent owns the day. It assigns jobs to service areas and spawns a sub-agent per area to sequence that area's route.
- MCP servers for the field-service management system (jobs, skills, availability), a routing and traffic API, and the SMS provider. The agent reads and writes jobs through the FSM server; it has no other path into their systems.
- OpenTelemetry tracing for every plan and re-plan: which jobs moved, why, and what the drive-time delta was.
Building the daily plan
Each morning the agent produces a proposed schedule: technician, order, estimated drive and on-site time, and the constraints it respected — skill match, service-level windows, parts on the truck. The dispatcher sees it as an editable board. Early on they overrode about one schedule in five, usually for a customer relationship the agent could not know about; after tuning the constraints that settled to about one in twelve.
Handling same-day emergencies
When a priority call lands, the agent re-plans just the affected areas and shows the dispatcher a diff: this job slots here, these two shift, this one moves to tomorrow with a reason. Small reshuffles — under a threshold number of moved jobs — apply on one click. Larger ones need the dispatcher to walk the diff. Same-day emergency jobs hit their SLA window about 91% of the time, up from about 74%.
Customer messaging
The SMS server is wired but gated. The agent drafts the "your technician is now scheduled between 1 and 3" message; it sends only after the dispatcher confirms the plan that produced it. There is no path for the agent to text a customer on its own.
Guardrails
The agent cannot dispatch, cannot message a customer, and cannot move a job outside its service window without surfacing it. Every plan is a proposal with a trace; the committed schedule is always a human action. A spend cap on the routing API and a step budget on the re-planner keep a bad day from becoming an expensive one. An operator can freeze re-planning and fall back to the last committed schedule instantly.
What it costs to run
A few hundred dollars a month of compute in the client's account, plus routing-API usage that scales with re-plans. It replaced a daily hour of whiteboard work and cut drive time per job by about 18%, which at 40 trucks is the real return.
How we rolled it out
For a month the agent produced a shadow schedule next to the dispatcher's real one, and we compared them every morning — where it agreed, where it did better, where it missed context. Then the dispatcher started working from the agent's plan with one-click edits. Then small same-day reshuffles stopped needing a second look.
This is the kind of system we build
If your operation lives and dies by one person's scheduling instinct, we can give them a draft and a fast undo. Book a call, or see Agent Design & Orchestration.
Publishing note: a representative composite of dispatch and scheduling work, not a single named client. Fleet size, job counts, and rates are illustrative of the range we see.