Supervised automation for dispatch and billing—approvals without the busywork

Dispatch and billing are not batch ETL jobs you can run overnight and reconcile later. They are online, side-effect-heavy workflows where each action touches money, a customer relationship, or a person’s schedule. A tech calls in sick, a commercial GC moves a start date, a homeowner disputes a line item—and someone with authority has to say yes or no under time pressure.

Fully autonomous agents fail here for a structural reason: the cost of a wrong action is asymmetric and often irreversible. Sending an incorrect invoice, double-booking a crew, or auto-approving a warranty credit is not a rollback of a database row—it is a phone call, a refund, and a trust hit. When the expected cost of an error times its probability exceeds the labor saved, autonomy is the wrong default. Supervised automation exists to keep the machine on the high-frequency, low-severity actions and route the low-frequency, high-severity ones to a human.

The clean way to model this is an explicit state machine per unit of work, not a pile of if-statements. Each action an agent proposes moves through states: proposed → validated → (auto-approved | pending_review) → applied → confirmed, with compensating transitions for reject and rollback. The classifier that decides auto-approve vs. pending_review is policy-driven, not vibes: it reads thresholds, actor roles, and confidence, and it fails safe to pending_review when uncertain.

Two properties make this production-grade. First, idempotency: every proposed action carries an idempotency key so a retry after a network blip cannot invoice a job twice. Second, durability of intent: the proposal, its inputs, and its rationale are persisted before any side effect, so a crash mid-apply is recoverable and auditable.

When dispatch and billing share one surface, the agent operates over a single consistent view of the job rather than two systems that reconcile nightly. Architecturally this is the difference between reading a shared event log and stitching together two REST APIs with different consistency guarantees. The classic failure—field marks complete, billing never hears about change order #3, AR chases the wrong total—is a stale-read bug, and you fix it the same way you fix stale reads anywhere: one ordered log of job events that both dispatch and billing project from.

An event-sourced job timeline also gives the agent the context it needs to be useful. “Invoice this job” is only safe if the agent can see that a change order was logged after the original estimate. Reading from the same append-only history means the model reasons over the current truth, and every projection (the billing view, the dispatch board) is deterministically rebuildable from events.

Because a language model sits in the loop, the guardrails are as important as the model. The reliable pattern is deterministic validation around probabilistic generation: the model drafts, but a rules layer verifies totals, checks that referenced parts exist, and confirms the customer and job IDs resolve before anything is proposed. The model proposes; deterministic code disposes.

You also need evals, not anecdotes. Treat approvals as labeled data: replay historical jobs, compare the agent’s proposed action to what the office actually did, and track precision on the auto-approve path specifically—that is the path with no human backstop. A regression there is a production incident, so it belongs in CI against a frozen set of representative jobs before any model or prompt change ships.

The human side is a queue-design problem. Owners who batch approvals once or twice a day stay in control without living inside legacy field-service UIs—but only if the queue is ranked by dollar impact and urgency, deduplicated, and rich enough to decide without opening four systems. A queue that surfaces 80 undifferentiated items trains people to rubber-stamp, which quietly re-creates silent autopilot with extra steps.

Done well, the approval surface becomes the owner’s daily habit and the system of engagement, while your field-service tools remain systems of record. That ownership of the daily loop—not the underlying database—is what actually retains the relationship.