PropTech Platform Built an AI Voice Property Discovery Agent

AVOX Realty is an AI conversational agent for real-estate discovery. A buyer talks to it in plain language and it turns that conversation into a structured, constraint-aware property search mapped to live listings, with no manual qualification in between. It was built for portals, builders and brokers, and it speaks the way buyers actually do — English, Hindi, and the Hinglish blend between them.

A buyer does not know what they want in the shape a search form requires. They say something like "somewhere near my office, not too far from a decent school, maybe two bedrooms, but I'd stretch for three if the commute's better." Every part of that is a real constraint. None of it is a field.

So a human does the translation. Someone talks to the buyer, works out what they actually mean, and types it into a system as a qualified lead. That step is the bottleneck and it is also where the information is lost: what gets recorded is the search, not the reasoning, so nobody can later tell why this buyer was shown these three properties.

Two things underneath make it harder. Listing data is fragmented and inconsistent — locality schemas differ from portal to portal — so a genuinely constraint-aware search across inventory is hard to deliver even when you know the constraints. And the input is messy in ways a naive voice loop cannot survive: mixed-language sentences, background noise, and buyers who interrupt.

That last one is unforgiving in a way that shapes the whole design. A property agent that lags, or talks over the caller, breaks the illusion immediately and the buyer hangs up. So none of this can be solved by slowing down to be careful.

• Turn free-form speech into deterministic search constraints, fast

• Hold a stable conversation in mixed languages, through noise and interruption

• Keep a structured record of preferences, not just the final query

• Ground every answer in current inventory, so nothing offered has already gone

We built a conversational backend for real estate and exposed it as a configurable voice and chat agent — reusing the runtime already hardened for insurance.

The expensive, reusable part carried over directly: the real-time listen-reason-act-reply loop, the turn detection, the noise handling. What changed was the domain layer around it — a new typed tool set, a new data plane, a new CRM.

That division is the entire point of the project. The conversational quality a buyer experiences on the line is quality that was earned in a completely different industry, and it moved by configuration rather than a rewrite. The domain layer is the cheap part; the loop is the expensive part; and the loop does not care what business it is in.

The other decision worth naming is that the conversation produces structured state, not just a query. The agent maintains a preference graph — constraints, intents and qualification signals — as the conversation goes. So the output is not "here are three properties." It is a record of what the buyer wants and why, which is the thing the human qualification step used to produce and throw away.

Design decision: recommendations are constrained by current inventory rather than generated. An agent that offers a property which has already gone has done worse than not answering.

The buyer talks the way they talk

English, Hindi, Hinglish, interruptions and all — with no form and no qualification call first.

The agent builds constraints as it listens

Locality, budget, amenities, commute tolerance and the trade-offs between them, accumulated into structured state rather than inferred once at the end.

It searches live inventory

Through typed tools for locality search, amenities and commute lookups, against current listings — so what is offered is actually available.

It replies inside the illusion

Around a second in English, under 1.3 seconds in Hindi and Hinglish, which is the range where a phone search feels like a conversation.

The lead arrives already qualified

Preferences, constraints and qualification signals sync to CRM as structure, so the human picking it up starts from what the buyer said rather than from a name and a number.

What the agent is allowed to do

It acts only through typed real-estate tools — locality search, amenities, commute times, inventory, CRM updates. Current inventory and captured preferences constrain what it can recommend, which is what prevents the failure mode buyers punish hardest: being offered something that is gone.

What runs, in what order

Detect the turn, transcribe across languages, update the preference graph, call the applicable tool against live inventory, reply in voice, sync qualification signals to CRM. The loop is the insurance runtime; the tools and the data plane are the parts that are specific to real estate.

What you can see afterwards

Every turn, session and action is logged through configuration rather than new code paths — which is a consequence of the reuse thesis, not a separate feature. The instrumentation came with the runtime.

The agent delivered a conversational property search that works in the languages buyers actually use, grounded in live inventory rather than a script. Turn stability improved 15 to 35 percentage points over baseline across the range from quiet rooms to call-centre noise, and the same orchestration handled English, Hindi and Hinglish without special-case flows per language.

The reuse result is the one that matters commercially. The hard part did move. A second industry did not require rebuilding the loop.

This project did not reach deployment. It concluded at internal stage, so what is described here is a system we built and tested, not lead conversion a brokerage realised.

• Sub-second multilingual property search by phone, grounded in current inventory

• Turn stability up 15–35 points in noise, holding through interruption and code-switching

• One voice runtime across two industries, retargeted by changing the domain layer rather than the loop

Stated plainly first: this was a real client project at internal stage and was not deployed. The numbers describe a system we built and tested. They are not conversion results and not production service levels.

The latency figures and the 15–35 point turn-stability improvement are our own internal measurements and should be reproduced before being relied on — both are properties of a specific audio path and a specific set of test conditions.

What is directly demonstrable: the multilingual loop with interruption handling, the typed real-estate tool layer, the unified inventory and preference data plane, CRM sync, and the fact that the runtime came across from insurance intact.

For your own estimate: inquiries × qualification time × loaded sales cost, minus escalation rate, review effort and infrastructure. Then consider the term nobody models — what a lead is worth when it arrives with its reasoning attached rather than as a name and a budget range.