Production workflows / Guide 13
A Car Dealership Service Agent That Books Capacity, Not Empty Promises
Build a car dealership service agent that matches vehicles, parts, skills, and bay capacity while preserving repair consent and recovering failed bookings safely.
Illustrative engineering guide. Examples are not client deployments, production-ready integrations, or evidence of measured results. Validate the design with your domain and security owners.
A hypothetical dealership receives a message: “My brakes squeal, and I need the car back by lunch.” The calendar shows a free slot, but the brake specialist is training that morning and the relevant parts are not confirmed. Booking the customer into that slot creates an obligation the workshop cannot reliably meet.
A car dealership service agent should distinguish an intake appointment from a completed-repair promise. It can clarify the complaint, assemble vehicle history, and propose feasible appointments. Diagnosis, safety advice about operating the vehicle, warranty interpretation, and authorization for additional work belong to qualified staff and approved procedures.
A booking is a bundle of resources
Model technician skills, bay capabilities, diagnostic equipment, opening hours, and parts availability separately. A general bay may support an inspection but not a job requiring a particular lift or high-voltage qualification. The model should never invent compatibility because two service names sound similar.
The vehicle record matters just as much as the calendar. Verify the vehicle identifier against the authenticated customer’s relationship to it. A household may own two similar cars; a fleet contact may arrange service without being the registered owner. Record the authority relevant to booking and repair approval rather than assuming those permissions are identical.
Retain mileage units and observation dates. A prior service recorded in miles must not be compared numerically with a kilometer-based maintenance interval. Convert units in deterministic code and preserve the original measurement. If mileage is unknown, offer an appropriate intake path rather than manufacturing a number from vehicle age.
Give language interpretation a narrow job
The LLM can transform “rattles only when cold” into a structured complaint with onset, conditions, location, and customer expectations. It can ask whether the customer seeks diagnosis or a known scheduled service. It should not translate “brake noise” directly into a brake-pad replacement order.
The smallest workflow uses customer lookup, service history, an approved service catalogue, resource availability, quote drafting, reservation, and notification tools. A scheduling solver or transactional allocator selects feasible capacity. Calling that allocator an agent adds no useful autonomy.
Recall information needs particular care. The NHTSA API use policy states that its API is not intended for other applications to perform bulk VIN lookups and describes traffic controls. Do not build a dealership-wide bulk scanner against it. Use a supported manufacturer or authorized provider integration after confirming access terms, and route unresolved recall questions to an advisor.
A separate technical-document specialist may help when multiple brands have distinct approved manuals and vocabularies. It should retrieve model-specific evidence with provenance. Add it only after measuring a retrieval gap; it must not diagnose independently or overrule a technician.
Represent feasibility without promising completion
This executable Python example checks one simplified interval against existing reservations. It illustrates scheduling logic, not an automotive scheduling SDK.
def can_reserve(start, end, existing, required_skill, skills,
parts_confirmed, requires_parts):
if start >= end or required_skill not in skills:
return False
if requires_parts and not parts_confirmed:
return False
return all(end <= other_start or start >= other_end
for other_start, other_end in existing)
assert can_reserve(9, 10, [(10, 11)], "inspection",
{"inspection"}, False, False)
assert not can_reserve(9, 11, [(10, 12)], "inspection",
{"inspection"}, True, False)
assert not can_reserve(9, 10, [], "brake_repair",
{"inspection"}, True, True)Production needs timezone-aware timestamps, travel or cleanup buffers, multiple simultaneous resources, skill validity dates, inventory reservations, database locking, and dealer-management integration. The function deliberately omits those dependencies. A true result means this narrow check passed, not that the workshop should promise a return time.
For the hypothetical brake complaint, offer a diagnostic arrival window with explicit uncertainty about repair duration and parts. If the customer requires a guaranteed return by noon, an advisor can discuss alternatives instead of letting the assistant convert preference into commitment.
Treat consent as a versioned business object
An approved estimate should specify labor operations, parts, taxes, currency, and the permitted amount. Attach consent to that estimate version and the approving customer’s verified identity. “Do whatever is needed” in an old chat is not durable permission for unrelated future work.
If inspection discovers a worn rotor beyond the original scope, generate a supplement for advisor review and customer approval. Do not quietly revise the original estimate. A rejected supplement should preserve the approved work and any technician-determined safety escalation, not trigger an automatic release of the vehicle.
Loaners, pickup services, and payment collection are separate reservations or financial operations. Initially keep them outside the agent’s write permissions. Adding them later requires explicit compensation behavior when the main appointment changes.
Recover partial bookings and stale availability
Recheck capacity and parts at commit time. The availability returned during conversation is only a snapshot. Create a short-lived hold across the required resources, then confirm it transactionally where possible. If the dealer system cannot reserve all resources atomically, record each step and release confirmed holds when the overall booking fails.
Use a stable booking request ID for retries. If the dealer system accepted an appointment but the connection dropped, look up that request before resending. An SMS failure should retry notification, not appointment creation. Show staff the confirmed booking even while its customer notification is pending.
Server-side authorization must scope every request to the dealer organization, location, customer, and vehicle relationship. Do not expose another customer’s contact information through “next available appointment” responses. PostgreSQL row security can reinforce those boundaries when configured and tested with non-bypass roles.
Uploaded inspection reports and customer messages remain untrusted. Following OWASP’s injection guidance, keep tool permissions outside the prompt and reject attempts to change prices or retrieve customer lists through document text. MCP connects tools; it does not grant booking authority.
Acceptance tests for workshop reality
- Two customers select the last compatible bay concurrently. Exactly one booking commits; the other receives fresh alternatives without a false confirmation.
- A brake complaint has no confirmed parts. The system offers diagnosis, not a guaranteed replacement or completion time.
- A booking response times out after success. Reconciliation finds the existing appointment, and only the notification is retried.
- A service report contains instructions to waive charges. The estimate remains unchanged unless the authorized discount workflow approves it.
- A customer approves estimate version two while version three is pending. Execution cannot treat the earlier consent as approval of the new work.
Measure promises kept
Baseline advisor handling time and booking corrections for comparable service categories. Measure appointments needing no resource correction divided by all agent-assisted bookings. Measure completed visits with the promised intake window honored divided by eligible attended visits; keep no-shows separate and visible.
Guardrails include duplicate bookings, unauthorized estimate changes, and repair-time promises contradicted by the workshop. Track customer clarification contacts, because a fast booking that requires three follow-up calls has not removed work. No improvement is claimed here: set proposed targets with service managers and evaluate shadow bookings before enabling staff-approved reservations.
Start with routine inspections at one location, excluding diagnosis-dependent repair guarantees. The fleet management guide covers vehicle availability across an operating fleet, and the field service dispatch guide expands skill-constrained scheduling. Golang Backend & API Engineering is relevant when reservation consistency, rather than model sophistication, is the difficult part.