AI system design
Inside the build: an AI sales assistant for automotive dealerships
Understanding and designing a complex AI customer journey, then building it. A technical deep dive into the architecture powering a production dealership assistant, live at Bernardi Volvo Cars, Natick, MA.
The short version
This is a conversational AI sales assistant built for automotive dealerships, currently live in production on bernardivolvocars.com. It handles sales conversations, service and leasing enquiries, test drive booking, and human handoff, all while staying grounded in real dealership data instead of guessing. It’s built on two platforms working together: Botpress, an autonomous LLM driven conversation engine that handles the actual conversation, reasoning, and decision making, and Make.com, an automation layer that handles everything that happens after the conversation: emails, spreadsheets, bookings, digests.
Botpress
Autonomous LLM driven conversation engine. Handles the actual conversation, reasoning, and decision making.
Make.com
Automation layer. Handles everything after the conversation: emails, spreadsheets, bookings, digests.
The conversation layer: Botpress
Autonomous nodes, not decision trees
Older generation chatbots are built as rigid decision trees: if the customer says X, show button Y. This system works differently. It uses AI that reasons through each conversation in real time, the way a good salesperson would, instead of following a fixed script. The AI handles open ended sales conversations, while important actions like bookings, service requests and human handoffs move into controlled workflows built specifically for that job.
Personality and Policy agents
Separate behavioural, knowledge and safety layers make the system easier to maintain and safer to update.
The knowledge layer
Retrieval augmented generation is only as good as its source separation. This build uses two isolated knowledge bases, deliberately kept apart.
Website knowledge base
Inventory, model details, specials and service information, drawn directly from the dealership website.
Hours and contact knowledge base
Verified operating hours and department phone numbers, checked and controlled by hand.
Critical dealership information such as operating hours and contact details is controlled separately from broader website knowledge, to reduce incorrect responses.
Honest state of the knowledge layer
The knowledge layer is continuously expanded and maintained as models, inventory and dealership information change.
The automation layer: Make.com
Conversation, then qualification, then booking or handoff, then reporting. Once the AI reaches a decision point, a service request, a handoff, a test drive booking, Make.com takes over and handles what happens next.
It covers four things: logging every conversation, routing handoffs to the right person, confirming test drive bookings, and keeping the dealership team’s reporting up to date, using Google Sheets, Gmail and Calendly.
Where this is heading
The architecture can be adapted to other dealerships without rebuilding the system from scratch.
Built and maintained by LK Motion.
For technical teams
A short technical note for teams evaluating build quality. A few of the harder lessons from building this in production.
LLM driven state writes are unreliable. If a value absolutely must be captured correctly, like a phone number or a confirmation flag, it belongs in an explicit code action, not a natural language instruction to an autonomous agent.
Automation platform imports can silently break references. Re importing a scenario blueprint can reshuffle internal module IDs, breaking hardcoded field references in email templates that look fine until they’re tested.
Reasoning models aren’t a drop in replacement everywhere. Certain automation modules expect plain text completions; reasoning style models can return empty output through those same integration points if swapped in without adjustment.
Is this relevant to your business?
A 20-minute call is all it takes to find out.
LK Motion · lkmotion.co.uk