The AI Estate Agent: From Property Listing to Verified Recommendation

Imagine a buyer looking for a two-bedroom flat under a fixed budget, within a few preferred neighbourhoods, with outdoor space as a strong preference. Listings arrive from several providers. One calls a room a study, another calls it a bedroom; a price may have changed yesterday, and parking may not be mentioned at all.

An AI estate agent should narrow the search, explain why a home fits, and call out what it cannot verify. The difficult part is not producing a fluent paragraph. It is making sure the paragraph refers to the right home, current listing facts, and the buyer's actual constraints.

This is a design exploration, not a description of a built or deployed product. The first version should solve a narrow problem: ingest a limited set of listings, capture a buyer's requirements, retrieve plausible candidates, and return recommendations with traceable evidence. Viewings, offers, mortgage advice, and a complete agency workflow can remain out of scope.

The model should help explain evidence. It should not be asked to invent the evidence.

Model the domain before choosing the model

Domain modelling means identifying the concepts that matter to the business, their attributes and behaviours, and the relationships between them. Nouns in a product brief can suggest candidate concepts; verbs such as lists, matches, supports, and saves can reveal relationships and actions. Grammar is a starting point, not a schema generator. The domain determines which concepts deserve to exist.

That distinction matters when people use the same word differently. Is a property the physical home or the advertisement? Is a feature a verified fact about the home or a buyer's preference? Is a recommendation a search result, a ranking, or an explanation produced by a language model? If those meanings stay implicit, one service may expose bedrooms from a listing while another treats it as a property fact, and the interface may display a generated explanation as if it were verified data.

Agreeing on these terms is part of building a ubiquitous language: the shared vocabulary used by domain experts, product designers, and engineers. It gives database fields, API contracts, business rules, and interface labels the same meaning.

The most consequential distinction is Property versus Listing. A property represents the physical home. A listing is a time-bound offer to sell or rent it, published by a particular source. One property may have several listings over time, possibly with different asking prices, descriptions, or availability. If the product needs to reconcile portals, preserve price history, or identify relisted homes, separate entities keep those facts in the right place.

For a small MVP with one trusted source and no cross-listing identity problem, a single PropertyListing record may be simpler and entirely reasonable. Splitting the entities before the product needs those lifecycle rules adds joins and identity-resolution work. The design should preserve the distinction in language even if the first storage model combines them.

Give each concept a clear responsibility

The following model describes responsibilities, not a mandated database schema:

BuyerRequirement should distinguish hard constraints from soft preferences instead of flattening both into an opaque prompt. A budget ceiling or minimum bedroom count can be checked deterministically. A preference such as “near a park” may need interpretation and ranking, but it should not silently become a hard exclusion.

Property holds the stable concept of the home; Listing owns facts that can change with an offer. PropertyFeature can represent normalized characteristics, while Evidence preserves where a particular claim came from and when it was observed. A recommendation should refer to the version of requirements it evaluated, rather than becoming detached from the buyer's intent when preferences change.

The diagram is conceptual. It shows that a buyer can have multiple requirement sets and recommendations; a property can be advertised by multiple listings; and evidence can be attached to listings and to recommendations that rely on it. A production schema might represent evidence as immutable source snapshots, event records, or references to an external store.

The RECOMMENDATION ||--|{ EVIDENCE relationship encodes an important product rule: a recommendation is not valid unless at least one evidence record supports it. That rule belongs to the domain, even if the final relational schema enforces it in application code rather than a database constraint.

Keep provider data out of the domain

An external provider's JSON shape reflects its own API, not the concepts this application needs. Mapping provider data into a canonical model introduces work, but it prevents provider-specific names, null conventions, and status codes from becoming the language of every service and screen.

Consider a source payload with asking_price, beds, and a provider-specific status such as UNDER_OFFER. The ingestion adapter can map it into a canonical listing with a typed price, a normalized bedroom count, an internal status, and a source reference. A separate property record can then be linked only when the system has enough information to identify the physical home.

For example, asking_price plus currency becomes Listing.askingPrice; UNDER_OFFER becomes an internal under-offer status while retaining the provider value for traceability; and beds becomes a normalized bedroom feature with its source evidence. The provider's ID remains a source reference—it is not automatically the canonical Property ID.

Keep four concerns distinct:

• Ingestion model: what the source sent, including its identifiers and original values.
• Domain model: what the application means by a property, listing, requirement, or evidence.
• API contract: the stable shape a client needs for its task.
• Frontend view model: the labels, formatting, and states needed to render the result.

This is not a call to create a mapping layer for every trivial field. It is a boundary worth keeping when provider differences affect meaning. If all clients consume a provider's schema directly, switching providers or correcting a normalization rule becomes a cross-application migration.

Make the recommendation pipeline explicit

A modest modular design is enough to start. Each step has a clear input and output, so the system can be tested and audited without an agent framework coordinating a collection of agents.

In practical terms, the modules are:

1. Ingestion and normalization preserve source references and translate external fields.
2. Property and listing storage retain canonical records and the facts needed to reconstruct what was known at a given time.
3. Requirement handling validates budgets, locations, bedroom thresholds, and preference categories.
4. Candidate retrieval applies hard constraints and gathers relevant listing evidence.
5. AI-assisted interpretation can extract structured intent from natural language and draft a concise explanation from supplied evidence.
6. Recommendation validation checks constraints and claims before accepting the response.
7. API and presentation return the decision, evidence references, unknowns, and useful display data.

The language model is useful where language is genuinely ambiguous or variable: translating “somewhere I can cycle to the station” into a candidate preference, or summarizing why three verified facts may matter to a buyer. Its output should be structured and validated. It should not decide whether an asking price is within budget, establish a bedroom count absent from the source, or turn a guess into a fact.

Start with one request path and a few well-defined modules. A multi-agent orchestrator adds coordination, failure modes, latency, and debugging surface. Introduce one only when independent agents have a demonstrated need for separate tools, permissions, or parallel work—not just because the product contains an LLM.

Make trade-offs explicit

Property versus Listing

One PropertyListing record is a reasonable shortcut for a single trusted source. Separate entities support multiple portals, price history, and relisting, but add identity resolution and joins. Split them when cross-source identity or listing history becomes a real requirement.

Structured filters versus semantic search

Exact filters for budget, area, and bedrooms are easy to explain and test. Semantic retrieval can find relevant descriptions expressed in varied language, but requires indexing, relevance tuning, and explainability work. Add it when structured fields cannot retrieve useful candidates.

Canonical model versus provider schema

Mapping source fields at ingestion protects the domain from provider-specific names and status codes. Exposing the provider schema directly minimizes initial mapping, but changes then spread through clients and rules. Prefer the canonical boundary unless the product is deliberately a thin wrapper for one stable provider.

Deterministic rules versus LLM interpretation

Code should apply hard constraints and verify facts; a language model can interpret natural language and summarize evidence. The model brings variance and unsupported-claim risk, so use it where language flexibility benefits the buyer—not for arithmetic or factual authority.

Semantic search is not synonymous with AI quality, and a vector database is not a prerequisite for an AI feature. Add either when observed queries cannot be served well by normalized fields and conventional retrieval, and when a representative evaluation set can show that the new retrieval method improves relevant results without weakening hard constraints.

Define what “verified” means

A buyer's hard constraints—for example, maximum price or at least two bedrooms—are eligibility rules. Soft preferences, such as a garden or a particular architectural style, help rank or explain candidates but should not be represented as mandatory unless the buyer says so.

For each candidate, separate:

• Verified facts: claims supported by a retrievable listing or source record, such as the asking price and stated bedroom count.
• Unknowns: details the available sources do not state, such as whether parking is included.
• Conflicts: facts that disagree across sources or between an old and a current listing.

A language model's confidence and a fluent explanation are not evidence. A valid recommendation should meet the hard constraints using current enough data, point to the facts behind its explanation, preserve source and freshness information where available, and name material unknowns or conflicts. When the evidence is insufficient, the correct result may be “not enough information” rather than a confident-sounding answer.

Even a well-grounded result describes the listing evidence, not the home's real-world condition. A listing that says “recently renovated” does not prove workmanship, and a stale price does not establish today's asking price. The system can make its reasoning traceable; it cannot guarantee facts that have not been independently checked.

Test the pipeline and the AI separately

Conventional tests should cover deterministic behavior: requirement validation, price and bedroom boundaries, source normalization, evidence selection, and API contracts. Integration tests should exercise ingestion through retrieval. Regression scenarios should include missing fields, contradictory listings, stale prices, ambiguous room descriptions, and a property that violates one hard constraint while matching several preferences.

AI evaluation needs representative examples with expected constraints and supporting evidence. Track hard-constraint violations, evidence coverage, unsupported claims, and recommendation relevance. Do not invent a benchmark before the system and evaluation set exist; establish a baseline from labeled scenarios, then compare changes to prompts, models, or retrieval.

Passing the pipeline's unit tests does not prove that generated explanations are correct. A response can be valid JSON and still overstate a claim. Record failed cases as regression examples so future model or prompt changes have to meet the same evidence standard.

The engineering lesson

The domain model gives buyers, product designers, and engineers a shared language. Boundaries keep provider formats and interface needs from defining the core concepts. Deterministic validation gives generated language a clear limit: it can interpret and explain, but evidence and constraints decide whether a recommendation is acceptable.

For engineers designing AI-enabled products:

• Define the domain and a correct result before selecting infrastructure.
• Keep facts, preferences, and unknowns distinct.
• Let deterministic code enforce hard constraints.
• Require explanations to point back to evidence.
• Add semantic retrieval or orchestration only when measured needs justify their cost.

The estate agent is “AI” only at the parts where language understanding adds value. The reliability of the product still comes from the software around it.