A Fleet Management Agent That Preserves Feasibility During Disruption

A fleet management agent should propose a feasible recovery plan, not merely a shorter route. Consider a hypothetical regional delivery fleet where a refrigerated truck reports a cooling fault while a nearby van has spare capacity. The van is geographically convenient but cannot carry the temperature-sensitive load. A language model may offer the obvious transfer unless vehicle capability is a hard constraint outside its control. This design combines operational evidence, constraint solving, and human dispatch approval.

Separate Telemetry, Eligibility, and Optimization

Telemetry reports observations; it does not automatically certify a vehicle as safe. Maintain distinct states for last known location, sensor freshness, maintenance clearance, load compatibility, driver assignment, and dispatch availability. A stale position can still be useful historical evidence, but it cannot support a precise current arrival promise.

An LLM can summarize a fault report, identify affected deliveries, and explain why a proposed plan changed. Deterministic services must enforce payload, equipment, maintenance, driver qualification, working-time rules, and customer windows. Applicable driving and rest requirements vary by jurisdiction and operation; qualified fleet staff must own the configured rules. The assistant must not waive them or declare regulatory compliance from a route summary.

Optimization is a separate responsibility. Google OR-Tools’ time-window routing guide demonstrates routes constrained by travel-time matrices and visit windows. It is a useful starting model, not a complete fleet safety system. Real deployments must add service duration, vehicle capability, depot schedules, breaks, road restrictions, and uncertainty in travel estimates.

Build an Eligibility Gate Before the Solver

The minimum architecture has an event ingester, a versioned fleet snapshot, an eligibility service, a bounded solver, and a dispatch change workflow. Identity and fleet scope are resolved server-side. Sensor data is authenticated at ingestion and associated with registered devices; the model cannot accept arbitrary chat-provided coordinates as trusted telemetry.

This executable Python illustrates a narrow vehicle filter. It is not a routing algorithm or maintenance diagnostic.

def eligible(vehicle, job):
    return (
        vehicle["maintenance_clear"]
        and 0 <= vehicle["telemetry_age_s"] <= 120
        and vehicle["free_payload_kg"] >= job["payload_kg"]
        and set(job["required_capabilities"]).issubset(
            vehicle["capabilities"]
        )
    )

job = {"payload_kg": 400, "required_capabilities": ["refrigerated"]}
van = {"maintenance_clear": True, "telemetry_age_s": 20,
       "free_payload_kg": 600, "capabilities": ["ambient"]}
assert not eligible(van, job)
assert eligible({**van, "capabilities": ["refrigerated"]}, job)
assert not eligible({**van, "capabilities": ["refrigerated"],
                     "maintenance_clear": False}, job)

The freshness threshold is illustrative and must match operational needs. Production validation must also check units, sensor plausibility, driver eligibility, cargo segregation, temperature range, and route restrictions. A refrigerator label alone does not prove the equipment currently works. The filter creates candidates for further checks; it does not authorize dispatch.

One coordinator with typed tools is sufficient initially. A maintenance specialist sub-agent earns its complexity when it helps a technician interpret documented fault codes with a separate evidence policy. It cannot clear a vehicle for service. Avoid assigning an autonomous agent to every truck; the resulting coordination problem can exceed the routing problem itself.

Replan Only What Needs to Change

Freeze completed stops and commitments too close to execution to change safely. Optimize the affected route suffix and eligible replacement vehicles rather than reshuffling the entire fleet whenever a sensor changes. Include a change penalty so small estimated travel savings do not repeatedly alter drivers’ plans.

Distinguish solver outcomes: feasible plan found, infeasible under current constraints, timed out with a feasible incumbent, and timed out without a plan. Do not translate every timeout into “no solution exists.” A feasible incumbent may be useful after independent validation, but it is not proof of optimality. The dispatcher should see the status and the remaining uncertainty.

For the cooling-fault example, a useful proposal might hold affected cargo for inspection, identify a compatible replacement truck, and show which delivery windows become at risk. It must not recommend continuing a potentially unsafe route to improve on-time performance. Cargo safety and vehicle return-to-service decisions belong to the responsible operational staff.

Attach the exact fleet snapshot version, job IDs, route revision, estimated arrivals, and constraint checks to each proposal. Approval applies to that change set. If the replacement vehicle is assigned elsewhere before approval, the service rejects the stale plan and requests a new one. A convincing explanation cannot override a version conflict.

Delivery of a Plan Is Not Acceptance

Persist approved route revisions before notifying drivers. Use an idempotency key for each vehicle and route revision so repeated delivery does not create conflicting instructions. Record queued, delivered, acknowledged, and superseded states separately. A push notification accepted by a messaging provider is not driver acknowledgment.

If a device is offline, retain the last acknowledged plan and alert dispatch that the change is unconfirmed. Follow a documented human contact procedure rather than assuming the driver saw the update. When reconnecting, the device should receive the current revision and identify superseded instructions. Never stack multiple stale route updates as if each still requires action.

Tenant and fleet isolation apply to locations, drivers, cargo, and customer addresses. PostgreSQL row security can reinforce scoped reads, but the integration must avoid privileged bypass roles. Limit location retention and access by operational purpose. Customer-facing tracking should expose only the relevant delivery, not an entire driver’s movement history.

Driver notes, customer instructions, and external traffic messages are untrusted input. OWASP’s LLM security project describes prompt injection and excessive agency risks. Such text cannot grant permission to disable a tracker, unlock a vehicle, clear a fault, or export routes. Keep those capabilities outside the assistant’s tool set.

Acceptance Tests and Measured Rollout

Test the operational boundary with these cases:

• A nearby ambient van has spare payload capacity but a refrigerated job. It is excluded before optimization.
• Telemetry arrives late and out of order. The current position does not regress, and stale evidence cannot support a current ETA claim.
• The solver times out with no incumbent. The assistant reports planning unavailable rather than claiming a feasible route or proven infeasibility.
• A dispatcher approves a plan after its replacement vehicle has been reassigned. Conditional publication rejects the stale change set.
• Route delivery succeeds but acknowledgment is absent. The old acknowledged plan remains visible, and dispatch receives an explicit unconfirmed-change alert.

Baseline dispatcher planning minutes, missed delivery windows, and route-change frequency under comparable demand. Measure proposal feasibility as independently validated proposals divided by all proposals presented. Measure on-time completion against all accepted jobs, including disrupted jobs rather than dropping them from the denominator. Track ETA error by forecast horizon.

Guardrails include safety-constraint violations, unacknowledged active changes, incompatible load assignments, and unauthorized location disclosure. Begin with shadow recommendations for one depot and one disruption type, then require dispatcher approval for every change. Distance-reduction targets are proposed hypotheses, not results, and must not reward unsafe or unstable plans.

The delivery exception guide explores customer recovery, while manufacturing maintenance develops equipment evidence and clearance boundaries. Golang Backend & API Engineering supports event and dispatch integration. Start by proving the eligibility gate and acknowledgment lifecycle before adding a more ambitious optimizer.

Sources

• Google OR-Tools: Vehicle routing with time windows
• PostgreSQL: Row security policies
• OWASP: LLM application security project