Property Intelligence AI: Valuation, Grounded Search and Agents

A property intelligence product is useful when a professional can trust a number, ask a question in plain language, and then run a multi-step check without leaving the platform. A chat window alone does not do that.

This anonymised case describes the functions and technology behind one residential property data platform. The company name, product names and customer details are omitted. The point is the product benefit of each layer: faster valuation support, answers tied to internal records, and workflows that reuse the same data instead of starting again.

One stack, several product jobs

The platform is easier to understand as layers than as a list of features. Each upper layer calls the one below. None of them replaces the property data.

flowchart TB
  UI["Product experiences: chat, maps, reports"]
  Tools["Tool access: search, analytics, external connector"]
  ML["Classical models: valuation, comparables, forecasts, risk"]
  Geo["Geospatial services: boundaries, sites, maps"]
  Data["Normalised property data from many sources"]
  UI --> Tools
  Tools --> ML
  ML --> Geo
  Geo --> Data

The practical split is simple. Geospatial services and the internal property model make records searchable. Classical models turn those records into scores and estimates. A language model plans a request, calls tools, and explains the result. Deterministic calculations stay outside the language model.

Comparables that a valuer can defend

Comparable selection is the function users feel first. Given a subject property, the product should return a short set of similar transactions, not a dump of everything nearby.

flowchart TD
  Subject["Subject property"] --> Candidates["Candidate generation"]
  Candidates --> GeoFilter["Geography and property type"]
  GeoFilter --> Attributes["Size, age and condition"]
  Attributes --> Recency["Transaction recency"]
  Recency --> Score["Relevance score"]
  Score --> Top["Top comparables"]
  Top --> Valuation["Valuation"]

The technology is a ranking pipeline, not a single model call. Candidate generation limits the search. Filters remove the wrong property type and the wrong area. Feature matching covers size, bedrooms, age, condition and listing attributes. A relevance model then orders what remains.

The product benefit is a valuation that can be explained. A user can see why a comparable was kept, and a later automated valuation can call the same set instead of inventing peers.

Valuation, benchmarks and portfolio scoring

Automated valuation sits on the same features: location, property attributes, recent transactions and local market context. The production work is the pipeline around the model.

• Feature pipelines keep training data and live scoring data on the same definitions.
• Validation and confidence metrics show where the estimate is weak.
• Monitoring and retraining catch drift after the model is released.
• Batch scoring and APIs recalculate a portfolio without a manual export.

Granular benchmarks do a different job. They aggregate by area or property type, normalise the figures, and keep a time series so a single property can be read against its local market.

Together these functions change the product from a data browser into a valuation workspace. Analysts spend less time assembling peers and more time checking the exceptions.

Predictive sale and rent estimates use the same discipline. Historical sales, listings, rents, location, local supply and broader market signals go through feature engineering into a model that returns a future estimate plus a confidence range. The hard parts are temporal leakage, sparse local transactions and an explanation that does not hide the uncertainty.

Search and answers grounded in the platform's own data

Once valuation and search exist, a language model can sit in front of them. The user types a goal. The system turns it into filters, runs the existing datasets and models, and only then writes the answer.

flowchart LR
  Prompt["Natural-language request"] --> Intent["Intent and query understanding"]
  Intent --> Filters["Structured filters"]
  Filters --> Data["Property datasets"]
  Data --> Analytics["Models and aggregates"]
  Analytics --> Synthesis["Grounded synthesis"]
  Synthesis --> Output["Text, property cards and map"]

Grounding is the technology that makes this safe to ship. The model does not answer from general knowledge of an area. It answers from records the platform already holds: listings, transactions, ownership, planning context, comparables and demographics. The response can include property cards and a map because those objects come from the query, not from generated text.

The product benefit is a shorter path from question to evidence. An agent, buyer or investment analyst can ask for a yield, a location constraint or a property type and receive the same filters, charts and records they would have built by hand.

The engineering constraints are product constraints:

• natural language has to become a structured property query;
• a large candidate set has to be reduced before the model sees it;
• the selected context has to be traceable;
• entitlements decide which records a user may see;
• latency has to stay acceptable once maps and cards are included.

The same grounded access supports generated valuation and market reports, personalised recommendations, and a first pass at due-diligence or site analytics. The report is useful because the numbers already exist in the valuation and benchmark layers. The language model assembles and explains them.

Site intelligence: one goal, several lookups

Some questions are not a single search. "Is this site worth a closer look?" needs planning context, ownership, constraints and geography, then a score and the sources behind it.

flowchart TD
  Request["Natural-language site request"] --> Planner["LLM planner"]
  Planner --> Planning["Planning context"]
  Planner --> Ownership["Ownership"]
  Planner --> Constraints["Constraints"]
  Planning --> GeoAnalysis["Geospatial analysis"]
  Ownership --> GeoAnalysis
  Constraints --> GeoAnalysis
  GeoAnalysis --> Scoring["Site score"]
  Scoring --> Evidence["Evidence and sources"]
  Evidence --> Answer["Actionable answer"]

The language model is the planner. Search, geospatial analysis and scoring stay as tools. The answer is allowed to sound fluent only after those tools return evidence.

For the project, this turns a research sequence that used to cross several screens into one workflow. The user still sees the sources, so the score can be challenged.

MCP / AI Connector

The product's own chat is only one client. Customers also want Claude or another agent to call the same property search, comparables and market analytics under their own subscription. That is a separate engineering block: an MCP / AI Connector in front of the platform.

flowchart TD
  Agent["Claude or another AI client"] --> MCP["MCP / AI Connector"]
  MCP --> Auth["Authentication and permissions"]
  Auth --> Catalogue["Tool catalogue"]
  Catalogue --> Search["Property search"]
  Catalogue --> Comps["Comparables"]
  Catalogue --> Market["Market and portfolio analytics"]
  Search --> Land["Planning and ownership"]
  Comps --> Land
  Market --> Land
  Land --> Response["Structured response"]

The connector does not add a new valuation model. It exposes tools the models and datasets already provide, and it refuses anything the caller's subscription does not allow.

The build covers:

• tool schemas for search, comparables, market analytics, planning and portfolio queries;
• authentication and permission checks;
• subscription entitlements;
• parameter validation and query limits;
• context shaping, so the agent receives the records it needs rather than a raw extract;
• geospatial response formats for maps and site results;
• observability, audit logging, latency control and error handling;
• regression tests for prompts and tools, so a schema change does not silently break an agent.

The project benefit is distribution without opening the database. A customer's agent can run a property workflow inside its own chat, and every call stays authenticated, limited and traceable. The same catalogue is what later assistants, including an underwriting workflow, call instead of rebuilding search and analytics.

Risk scores from filings and ownership

A separate scoring function combines corporate filings with property ownership. Accounts, charges, director records and late filings become features. Ownership links those signals to assets. A distress model produces a risk score, and a monitoring loop refreshes it.

flowchart TD
  Filings["Corporate filings"] --> Features["Feature engineering"]
  Ownership["Property ownership"] --> Features
  Features --> Model["Distress model"]
  Model --> Score["Risk score"]
  Score --> Monitor["Monitoring"]

The model is the smaller piece. Most of the value is the join between two source types and a score the portfolio team can watch. The product benefit is an earlier shortlist of assets that may need attention, with the filing and ownership evidence still attached.

What the project gains by keeping the layers separate

New workflows get cheaper when they call existing functions. An underwriting assistant, for example, does not need a new property database, a new map or a new valuation model. It needs orchestration, underwriting rules, deterministic calculations, citations, customer-specific configuration and an audit trail.

flowchart LR
  Existing["Existing data, geo, valuation, comparables and tools"] --> NewWork["Workflow rules and evidence"]
  NewWork --> Memo["Underwriting output"]

That is the project-level payoff. Each function remains available to the next one:

Function	Technology	Benefit for the product
Comparables	Candidate filters plus a relevance model	Defensible peers for a valuation
Automated valuation	Feature pipelines, validation, confidence, retraining	Repeatable estimates and portfolio recalculation
Benchmarks	Aggregation, normalisation, time series	Local context around a single asset
Forecasts	Temporal features and confidence ranges	Sale and rent estimates that show uncertainty
Grounded search	Query understanding, retrieval, synthesis	Plain-language access to the same records
Site intelligence	Planner, multi-tool lookup, scoring, sources	One workflow instead of several research steps
MCP / AI Connector	Tool schemas, auth, entitlements, limits, audit	Customer agents call the platform without a raw database connection
Risk scoring	Cross-source features and monitoring	A watchlist backed by filings and ownership

Rules that keep the functions trustworthy

Use a classical model when the output is a number. Valuation, comparables, forecasts and risk scores need validation, drift checks and confidence. A language model can call them and explain them. It should not invent the figure.

Ground every sentence that states a fact. If the answer mentions a price, a comparable, a planning constraint or an owner, that item should be a record returned by a tool.

Put permissions in the tool layer. Once an external agent can call search and analytics, entitlements and audit logs are part of the product, not a later cleanup.

Add the next assistant only when it reuses these functions. The saving is reuse. A second agent that rebuilds valuation and search will cost almost as much as the first platform.

---

Building valuation, grounded search or a tool layer on top of existing property or market data? Tell us which function is missing, or see our approach to AI development and applied AI automation.