Building the Mahindra Electric Agent: Architecture

We built the customer-facing agent for Mahindra Electric. This is a description of how it is put together, written from our side of the table.

There are no performance figures in this post. We have them in a dashboard and they are not ours to publish, so rather than dress up estimates as results, here is the architecture and the reasoning, which is the part that transfers to anyone building something similar.

The shape of the problem

Buying an electric vehicle is a long, researched decision with a lot of questions in front of it. Range under real conditions. Charging at home versus on a route. What the warranty covers on the battery specifically. Which variant has which feature. What a booking actually commits you to.

Those questions arrive continuously and they arrive at every hour. They are also almost entirely answerable from material that already exists, which is the profile where an agent is genuinely useful rather than merely fashionable.

The commercially important ones are different. A person asking about a test ride in a particular city has moved from research to intent, and that conversation should not end with a helpful answer. It should end with a booking.

Four services, split by what they own

The system divides into four pieces, and the division is by ownership of data rather than by technical layer.

The chatbot is the customer surface. It holds the conversation and nothing else.

The catalogue is product truth. Variants, specifications, features. This is deliberately not in the agent's prompt. Specifications change, and an agent that has memorised last quarter's range figure will state it confidently forever.

Enquiries are the commercial output. A conversation that reaches intent produces a record, and that record is the thing the business acts on.

Insights and analytics read completed conversations and turn them into aggregate answers about what people are actually asking.

The rule underneath the split: the agent may read anything, and may write in exactly one place. Widening what an agent can write is where most of the risk in these systems lives.

Enquiry, then booked

The enquiry record has two states, and separating them is the design decision that matters most.

An enquiry is created by the conversation. Someone expressed interest, gave their details, and asked about a test ride. That is a claim about intent and the agent is competent to make it.

Booked is a different assertion. It says a real appointment exists in the world, at a place, with a person who will be there. That depends on dealer capacity, vehicle availability, and a human schedule the agent cannot see.

Marking an enquiry as booked is therefore a separate, password-protected operation performed by a person. The agent never sets it.

This is unglamorous and it is the correct line. The cost of an agent over-claiming intent is a follow-up call that goes nowhere. The cost of an agent confirming an appointment that does not exist is a customer driving to a dealership on a Saturday for nothing. Those are not comparable failures and they should not sit behind the same permission.

Bulk booking, and why a preview step exists

Confirmations come back from dealers in batches and in whatever format the dealer uses. Someone pastes a list of references.

That flow has two steps rather than one. A preview parses the pasted text and shows exactly which enquiries it matched, and only then does a confirm apply the change.

The reason is that fuzzy input plus a bulk write is a bad combination. A parser that is ninety-five percent right on twenty rows is wrong on one of them, and without a preview the first time anyone learns which one is when a customer is contacted about an appointment they never made. The preview turns an irreversible batch into a reviewed one, and costs a click.

Handover

Some conversations need a person. A specific complaint, a commercial negotiation, anything where the agent has been asked twice and not resolved it.

The handover carries the transcript. This sounds obvious and it is the single most common thing done badly, because a transfer that arrives as a fresh "how may I help you" makes the customer restate everything they just typed. The escalation then costs more than having no agent at all: the customer has done the work twice and is now annoyed as well as unresolved.

Handover is a feature of the conversation, not an error path out of it.

What the insights are actually for

Conversation analytics get sold as a reporting feature. Their real use here is as an editing tool.

Reading what people genuinely ask, in their own words, at volume, tells you what your published material fails to explain. A question that recurs constantly is not an agent problem to be patched with a prompt. It is a gap in the source content, and the correct fix is upstream: write the answer properly, in public, where it also helps everyone who never opens a chat window.

The agent, used this way, is a very good instrument for finding out what your documentation does not say.

What we would tell someone doing this again

Keep product truth out of the prompt and behind a lookup. Specifications change and prompts do not know that.

Give the agent exactly one thing it may write, and make every state beyond that a human decision.

Never let a batch operation run without a preview.

Carry the context through the handover, always.

And read the transcripts yourself, regularly. Every genuinely useful change we have made to this system came from reading what people typed, not from looking at a chart.