PropertyAgent
Search Singapore property in plain English, get an instant fair-value verdict, and book the viewing, no agent required. A conversational agent that pulls live listings, cross-checks valuations, and handles scheduling end-to-end.
The Idea
Buying, selling or renting a property in Singapore or most parts of the world requires a middleman. However, with open sourced data available (and with rising agent comission costs), a lot of the next generation buyers/sellers/renters and landlords are looking to go DIY. Current platforms exist but they do not synthesize these data points well. They are never end-to-end and often requires users to search for data on multiple platforms. This is why we built PropertyAgent, a conversational agent that can search, evaluate a price based on complex data sets, and be your personal property assistant - from scheduling of viewing to producing legal documents.
The Pain Points
These pain points determined what we actually shipped first, not the full platform vision in the PRD. See Scoping It for what's to come.
"My agent's commission is 1–2% of the sale price just to have someone tell me information that's mostly already public... But they represent me in the transaction so I just go with it"
→ No agent in the loop: search, valuation, and scheduling all live in one platform, with no commission anywhere in the flow.
"Most of the time we search with pre-set filters like location, size and price. But what if I wanted to live next to a park or a school, existing platforms exclude places like these"
→ Conversational search. Describe what you want in plain language; the agent extracts structured filters and searches live listings, not a fixed dropdown.
"I have no idea if a price is fair. I can't read into the valuator's mind. Bid too high and I overpay on COV, bid too low and I lose the flat."
→ Instant valuation verdict: the agent compares a listing against comparable percentile pricing and returns Overpriced / Fair value / Good deal, with the number behind it.
"Coordinating a viewing means messaging multiple owners across different platforms and juggling everyone's calendar by hand. That's just the start of all the admin work that I need to do."
→ Auto-scheduled viewings. The agent checks Google Calendar free/busy and books the slot directly, no back-and-forth.
Customer Journey
Before PropertyAgent, Josh had two options: pay a traditional agent, or do it all himself. Here's what both looked like, phase by phase — and where PropertyAgent actually changes something today.
Josh, a first-time buyer, works as a teacher, doesn't have experience with resale transactions, and he doesnt have much time to think about this.
Scenario
Josh needs to find a flat that fits his lifestyle, book viewings without the usual back-and-forth, and know whether an asking price is worth bidding on.
Standard agent vs. doing it himself, phase by phase — click to enlarge
Scoping It
The PRD covers a full platform: Singpass verification, statutory milestone tracking, contract generation, monetization. Shipping a focused proof of the core agent loop meant almost none of that could make it into this build. Every cut needed an actual reason.
Cut, and why
- Singpass verification & MyInfo pull: needs government API access and legal review, not a hackathon sandbox
- Statutory milestone tracker (OTP, Request for Value, Resale Application), which carries high compliance surface area; needed HDB data plumbing we didn't have time to build safely
- Multi-language translation layer, nice to have, not core to proving the agent loop
- Legal document generation (CEA tenancy agreement, OTP auto-fill): regulatory risk, not something to prototype under deadline
- Monetization (premium pass, legal closure kit, affiliate fees), not needed to prove the concept
Kept, and why
- Conversational search over Elasticsearch: the core "beyond rigid filters" bet, and the reason for the Elastic partner track
- Auto-scheduled viewings via Google Calendar, the clearest "no manual coordination" win, small enough to ship in days
- Instant valuation verdict: a percentile-based read on price, without needing a licensed financial advice product
- A synthetic ~700-listing dataset instead of live HDB/URA feeds, sidestepping data-access and licensing lead time while still proving the search-and-valuation loop end to end
Requirements
The PRD turned scope into criteria specific enough to check a build against directly, with no guesswork about what was meant. A few examples:
- Filter extraction returns typed values through a function-tool call the frontend merges directly, with no text-parsing fallback in production
- A valuation verdict always states Overpriced / Fair value / Good deal plus the % deviation from median comparable PSF, never a bare label with no number behind it
- The agent auto-detects whether a message is a search request or a market question, and only calls the filter tool for the former, so analytics questions never corrupt the active filters
- Viewing requests check the host's live Google Calendar free/busy before offering a slot, never booking blind
Technical Approach
One call shaped the rest: routing search and valuation through Elastic's own Kibana Agent Builder MCP server, rather than querying Elasticsearch directly from application code. A requirement of the hackathon's Elastic partner track, and the reason filter search and valuation numbers reflect a live index instead of hardcoded logic.
- Agent chat panel
- Property list & map
- User calendar view
- Calls agent to build property filters, returns to frontend
- Executes ES queries
- Books viewings for user
- FunctionTools: extract_property_filters, get_free_slots, create_viewing_event
- MCP Toolset: generate_esql, execute_esql, get_index_mapping, search, get_document
- Kibana Agent Builder MCP: /api/agent_builder/mcp
- Elasticsearch: property index, ~700 SG listings
- Free/busy queries
- Create viewing events
Building It
Each stage built on top of something that already worked, before the next layer went on.
Acceptance criteria
- Filter-extraction tool call returns typed values the UI merges directly, with no text-parsing fallback in production
- Valuation verdict always pairs a classification with the fair-price range behind it
- Calendar booking checks free/busy before offering a slot to the requester
Risks encountered
- The model swap to Gemini 2.5 Flash landed mid-week, which meant re-validating agent behaviour late in the build
- Map pins failed to render on initial load in one build, caught and fixed before demo day
- Auth was pulled entirely just before submission so judges could reach the demo without credentials: a reasonable call for a judged demo, not how this would ship to users
What's Next
Search, scheduling, and valuation close the gaps a self-directed buyer hits first. Negotiation and the statutory paperwork are where the same buyer is still exposed, so that's where the next build goes:
- Buyer & seller verification. Without an agent as a trust layer, self-directed deals are more exposed to ghosting, lowballing, and false signals from the other side — verification logic closes that gap.
- A structured, data-backed bidding flow. A directional fair-value verdict tells a buyer what to expect, not what to actually offer. Offer stage is the highest-stakes, most emotional decision in the process, and it's the one point still unsupported.
- A step-by-step statutory milestone tracker. This is the Administrative Completion stage flagged as unbuilt in the Customer Journey above — the paperwork after an accepted offer is exactly where a deal can quietly stall.
Reflection
Ambiguity hiding in a feature's language, or in how a requirement was worded, caused more trouble here than any technical issue did. Two things I'd sharpen next time: