Intelligent Vehicle Diagnostics for an EV Company

When an EV company preparing for their 2027 launch reached out about AI-powered service capabilities, they had a clear vision: build customer service that’s as modern as the vehicles themselves.

The traditional automotive service model wasn’t built for this. Long hold times. “We’ll call you back with pricing.” Three calls to resolve a simple question. For a new EV brand launching into a competitive market, that experience would be a liability, not a differentiator.

Over 16 weeks, we worked with their Digital Product team to validate whether AI could handle real-world service scenarios while adapting to different customer types.

The challenge

The team needed an AI system that could translate customer-described symptoms into diagnostic recommendations, adapt response complexity based on customer technical knowledge, provide transparent cost estimates including warranty status, and escalate to human support when needed without losing context.

The last point mattered most. They weren’t trying to eliminate human service. They wanted AI that could handle routine questions well and hand off complex ones gracefully.

What we built

We built custom MCP servers that gave the AI agent access to their service data: repair codes, maintenance schedules, warranty rules, and FAQ content. Twelve tools in total, covering the full diagnostic workflow.

The architecture:

  • search_repair_codes(): Semantic search over 85+ repair codes. When a customer says “grinding noise when I brake,” the system finds the right code even though they never said “brake pads.” We used ChromaDB with OpenAI embeddings, returning results in 50-100ms.
  • check_warranty_coverage(): VIN + mileage + repair code lookup against warranty rules.
  • estimate_repair_cost(): Parts, labor, and tax breakdown with warranty adjustments.
  • get_maintenance_schedule(): Mileage-based service intervals.
  • search_faq(): Natural language search across FAQ content.

The key technical decision was semantic search rather than keyword matching. Customers don’t know repair codes, but they can describe symptoms. Bridging that gap with embeddings worked reliably.

The personalization problem

Early in the pilot, we hit an interesting challenge. The same question needed different answers depending on who was asking.

A customer who knows cars wants specifics: “Code 2520 indicates worn brake pads on the front axle. Given your current mileage, this is expected wear. The repair involves removing the caliper, replacing pads, and inspecting rotors.”

A customer who doesn’t wants reassurance: “That grinding sound usually means your brake pads need replacing, which is normal after the miles you’ve driven. It’s a straightforward fix.”

Same diagnosis. Different delivery.

The traditional approach would be prompt engineering: long system prompts with conditional logic about when to be technical vs. simple. That gets brittle fast.

Instead, we solved it at the context layer. We built an MCP tool that retrieves customer profile information, including an expertise indicator. The agent receives that context alongside the diagnostic data and naturally adapts its explanation style. No complex prompt logic. No fine-tuning. The personalization emerged from giving the agent the right information at the right time.

Multi-issue triage

The scenario that resonated most with their team involved a customer with multiple concerns: brake noise, a battery warning light, and AC not cooling.

Traditional service would handle these as separate tickets or one overwhelming call. The AI agent approached it differently:

  1. Parallel diagnosis. Searched repair codes for all three symptoms simultaneously
  2. Warranty lookup. Checked coverage status for each repair code
  3. Cost estimation. Calculated customer cost for each, accounting for warranty
  4. Prioritization. Recommended order based on safety and coverage

The agent recommended addressing the battery first (safety-critical and covered under warranty), then AC (covered, comfort), then brakes (safety-important but customer pays). One appointment, clear expectations, no surprises.

Human escalation

We designed the system for handoff, not replacement. When the AI encounters situations outside its scope (emotionally charged customers, ambiguous multi-symptom scenarios, or edge cases in warranty coverage) it transfers to a human agent with full context: the conversation history, diagnostic findings so far, and relevant customer data.

The human picks up where the AI left off. No “can you repeat your issue?” No starting over.

What we learned

Context injection beats prompt engineering for personalization. Instead of encoding customer handling rules in prompts, we surfaced customer context through tools. The agent’s natural language abilities handled the rest. It scales better than conditional prompt logic.

We were surprised how well semantic search worked over structured data. The embedding approach reliably bridged the gap between customer language and technical terminology.

Cost transparency changes the conversation. Every diagnostic conversation included cost estimation. Showing warranty status alongside pricing removed the “how much is this going to cost?” anxiety. That transparency changed the tone of interactions.

One regret: human handoff was the last integration we built. It should have been first. The AI’s value is clearest when you see what happens at the boundary between automated and human service.

The outcome

After 16 weeks, their team could configure and extend the system independently. The technical architecture provided a foundation for their production planning. No vendor dependency. They own the tools, the data, and the knowledge of how it all fits together.

Have a similar problem? Let's talk.

Or email directly: hello@nimblebrain.ai