Autonomous dispatch agent for a North American service network.

The client operates a service network across multiple US regions — technicians in the field, a central dispatch desk, and customers calling for service requests. Most of the volume hit between 9am and 6pm local time, but a stubborn 30 — 40% of it landed outside business hours. After-hours requests either waited until morning or pushed dispatchers into expensive on-call rotations.

The team had explored hiring a second-shift dispatch crew, but the math didn't work — the after-hours volume was significant in aggregate but uneven enough that any individual shift sat idle most of the time. They needed a system that could handle the predictable parts of dispatch — intake, basic triage, technician matching, scheduling, customer confirmation — and escalate only the complex cases to a human.

The CRM was already custom and integrated with their technician app and billing system. The new system had to fit inside that existing graph, not replace it.

The triage agent fronts the system. It pulls signal from the inbound channel, assigns a severity score, classifies the service category, and decides whether to route the case to the agents or escalate immediately to a human dispatcher. Anything urgent or anomalous — a safety issue, a customer at risk of churn, a request the model isn't confident about — goes straight to a person.

Three specialist agents handle the routine cases. The routing agent picks the right technician from a pool of dozens based on skills, current location, certifications, and historical fit. The schedule agent finds a time window that works for both the customer and the tech, accounting for travel time and existing appointments. The comms agent handles the customer-facing thread — SMS confirmations, voice calls for older customers who prefer them, follow-ups when a tech is running late.

Everything writes back to the existing CRM as the source of truth. The agents read and write through a thin service layer — they never touch the CRM database directly, which kept the integration tight and made rollback trivial during the first weeks.

FastAPI for the service layer between agents and CRM. The team's existing stack was Python; staying in-language meant their engineers could review and extend the code without context-switching. OpenAI for the agent calls — at the time of build, function-calling reliability on dispatch-style structured outputs was the strongest among options we benchmarked.

Postgres for the agent state store, sitting alongside the CRM's existing Postgres. No new database technology introduced. The schedule-agent's time-window logic ran as deterministic SQL with the LLM only used to summarize and explain — a deliberate choice to keep the highest-stakes decisions out of model reasoning.

Considered and rejected: a no-code dispatch platform (couldn't express the CRM-specific routing logic), a single big agent with all three responsibilities (failed safety review on the comms-agent voice tone in week 2 testing), and routing entirely through model context (degraded over long conversations, lost track of half-scheduled appointments).