Honda Service Advisor AI Agent: My Production Workflow

ZenMaster Expert 1h ago Updated Jul 26, 2026 34 views 14 likes 2 min read

Building an LLM agent for a real-world dealership taught me a hard lesson: the model should classify, but the code must guarantee. I deployed an SMS agent for my Honda service drive in South Florida to handle repetitive questions—pricing, warranty coverage, and booking—across six different languages. It works by pulling from owner's manuals and service contracts, escalating to my Telegram only when a human is actually needed.

The biggest breakthrough came when I stopped trying to "prompt engineer" my way out of logic errors and started moving that logic into Python.

The "Model Classifies, Code Guarantees" Rule

Many developers try to fix logic errors by refining the system prompt, but for production-grade agents, that's a losing game. I hit three major bugs that proved the LLM is a terrible calculator and date-comparer.

The Date Comparison Failure: A customer with an expired contract was told their repair was covered. Even with today's date in the system prompt and explicit instructions to compare, the LLM failed. I stopped asking the model to compare dates and moved the logic to a Python function. Now, the code calculates the status, and the model simply relays the verdict.

The Calculation Drift: Pricing for shop supplies and taxes is a strict formula. Letting an LLM calculate a "total" leads to drift. I now use a dedicated function to handle the math, ensuring the "out-the-door" price is always accurate to the cent.

The False Completion Bug: My agent uses Pydantic for structured output with a complete flag. I found cases where the model marked a booking as "complete" despite missing the service type. I now implement a server-side validation check that ignores the model's self-assessment and verifies the data independently.

Implementation: Logic over Prompting

To make this work, I shifted the AI workflow. Instead of one giant prompt, I use the LLM as a router and a communicator. Here is how I handle the expiration logic to prevent the model from hallucinating coverage:

def _annotate_expirations(in_md: str) -> str:
    """
    Stamp a computed past/active verdict next to every expiration date in the 
    portal data. LLMs are unreliable at date comparison, so the comparison 
    is done here and the model only relays the verdict.
    """
    # Logic to compare current date vs expiration date
    # Append [EXPIRED] or [ACTIVE] to the text before sending to LLM
    ...

And for pricing, I keep the "single source of truth" in code:

def calculate_total(subtotal):
    """
    Single source of truth for the fee formula so it never drifts between 
    the prompt and the code:
    shop supplies = min(subtotal × 10%, $59.50)
    tax = (subtotal + shop supplies) × 7%
    """
    shop_supplies = min(subtotal * 0.10, 59.50)
    tax = (subtotal + shop_supplies) * 0.07
    return round(subtotal + shop_supplies + tax, 2)

By treating the LLM as the interface and Python as the engine, the agent became stable enough for real customers. If you're building an LLM agent, move your business logic out of the prompt and into the deployment code.

AILLMpythonPrompt

All Replies (4)

J
Jules45 Expert 9h ago
Make sure you're handling time zone offsets for the scheduling part, otherwise appointments get messy.
0 Reply
R
Ray37 Intermediate 9h ago
Good call. I'm currently using UTC on the backend to avoid that headache.
0 Reply
L
Leo37 Novice 9h ago
did you use a specific framework for the classification part or just raw prompts?
0 Reply
M
Max75 Advanced 9h ago
Had the same issue with a CRM bot; hard-coding the logic saved me from endless hallucinations.
0 Reply

Write a Reply

Markdown supported