Best practices for agentic real estate and proptech data: a field guide for property data teams

A property record is built from sources that were never designed to fit together. County recorders and tax assessors publish on their own schedules in their own layouts. MLSs expose listings through the RESO Web API, older RETS feeds or flat files, each with local fields and licence terms. Every property manager sends a rent roll with its own charge codes. The data team turns all of it into one record that an appraiser, an asset manager, a lender and now an analyst copilot can rely on (the infrastructure view of this domain covers the plumbing).

The mandate has hardened. Valuation inputs feed fund NAV and loan terms, certificates and investor reports land on fixed dates, and more questions about rents, comps and exposure go to AI agents that repeat whatever the record says. A stale comp used to cost an analyst an afternoon. Now it can reach a committee with confidence attached.

Our view: almost everything that keeps a property record correct is repeatable, and agents should do it. The judgement stays with the valuation lead, the asset management controller and the stewards who own the numbers. This guide, a companion to the full playbook, sets out the practices that make that split work.

The old world

It is the Wednesday before quarter-end. A county moved its assessor export to a new layout three weeks ago, and nobody noticed until an engineer saw its assessed values had stopped updating. Forty-odd addresses from the latest sales files match no parcel, some because a parcel was split last month. One property manager's rent roll arrived late with a new charge code, so occupancy in the asset report and in finance disagree. The valuation lead asks where a rent assumption in the committee deck came from, and answering takes two people and a day. The lender certificate is due Friday.

The new world

Same Wednesday with Data Workers. The Connectors agent flagged the county change the morning it arrived. Schema Evolution mapped the new columns against history, Pipeline Building updated the staging model with tests, and Quality Monitoring proved parcel counts and assessed values still tie. Doubtful address matches sit in a steward's queue with the likely cause attached. Autonomous Data-Conductor sends the valuation lead one decision with the diff and tie-out. Every input in the pack carries its source and date.

Here is that morning as a chain of hand-offs:

The rest of this report covers seven practices behind it. At a glance:

The practices, one by one

1. Onboard every county and MLS feed against one dictionary

A property record is only as consistent as its worst-mapped source. Map each feed ad hoc and "living area" or "status" quietly means different things by county, so comps stop comparing.

Why it's harder than it looks: county exports are flat files with thin documentation, so profiling is by hand. MLS feeds mix standard RESO fields with local extensions, and each source carries licence terms that no column profile will reveal.

1. 1.The Connectors agent registers the source read-only and runs get_connector_status, so you know what is reachable before anyone writes a mapping.
2. 2.The Data Ingestion agent lands a sample load and profiles keys, nulls, ranges and date formats.
3. 3.The Pipeline Building agent drafts the staging model with generate_pipeline, mapping listing fields to RESO Data Dictionary names, then runs validate_pipeline.
4. 4.The Quality Monitoring agent adds tests with create_quality_tests_for_pipeline and a freshness target with set_sla.
5. 5.The Data Context & Catalog agent documents the source with generate_documentation: owner, licence, cadence, consumers.
6. 6.The data product owner approves the field mapping and licence class before the source feeds production.

See agents onboard new sources in days, and data ingestion vs data integration for the distinction.

2. Catch layout changes the day they happen

A layout change is rarely an error. The load succeeds and the data is wrong, or one county stops updating while the rest look healthy.

Why it's harder than it looks: a renamed column is easy to see; a split owner field, a changed date format or a widened code list is not. Row counts stay flat, so the failure is found downstream, and the fix means reprocessing everything loaded since.

1. 1.The Connectors agent notices the feed no longer matches its last known layout.
2. 2.The Schema Evolution agent runs detect_schema_change, checks validate_schema_compatibility against history and writes the migration with generate_migration, with a rollback plan.
3. 3.The Pipeline Building agent updates staging, adds tests and reprocesses the affected window from raw.
4. 4.The Quality Monitoring agent runs run_quality_check: parcel counts and assessed value totals must tie to the prior load.
5. 5.If a check fails, the change is reversed with rollback_migration instead of patched forward.
6. 6.The property data product owner approves the migration before it applies to the property record.

Background: schema changes that never break downstream and schema drift detection. The effect on elapsed time, across the routine work:

3. Re-match addresses to parcels on every load, and queue the doubtful ones

Every sale, lien, permit and tax bill hangs off the link between an address and a parcel. Get it wrong and a building inherits someone else's history.

Why it's harder than it looks: one building appears under three spellings, a unit number migrates into the street line, and a parcel split leaves two records where there was one. A quarterly clean-up fixes the past and misses everything since, and a confident wrong match flags nothing. Marketplace teams face the same problem, covered in best practices for location and marketplace data.

1. 1.The Pipeline Building agent builds the matching step in your own dbt project with generate_pipeline, so the logic is code you can review.
2. 2.On every load, the Quality Monitoring agent checks each new address resolves to one parcel and surfaces exceptions with get_anomalies.
3. 3.The Incident Debugging agent runs get_root_cause on the queue and groups it by cause, such as a split recorded last month.
4. 4.The Data Context & Catalog agent shows every record a split touched with trace_cross_platform_lineage.
5. 5.A named data steward works the remaining queue with the evidence attached. Agents never guess a match to clear it.

4. Normalise rent rolls to one lease record and tie them to the ledger

Occupancy, in-place rent and arrears drive underwriting, covenants and investor reports, and mean nothing unless they tie to the ledger.

Why it's harder than it looks: every property manager has its own columns, charge codes, unit identifiers and date formats, and an acquisition arrives as a dozen spreadsheets. Mapping is the easy half. Reconciling and explaining every unit that does not tie is the hard half.

1. 1.The Connectors agent lands each rent roll and checks it with get_connector_status.
2. 2.The Pipeline Building agent builds the mapping to the single lease record with tests, so the next property manager is configuration.
3. 3.The Data Context & Catalog agent records the definitions of occupancy, in-place rent and arrears in Data Context Wizard with define_business_rule.
4. 4.The Quality Monitoring agent ties rents to the ledger with run_quality_check and flags units that do not tie.
5. 5.The Incident Debugging agent runs get_root_cause on those units, for instance a new charge code that is really a parking fee, and proposes the mapping.
6. 6.The asset management controller approves new charge-code mappings, because they move income between lines.

5. Give every valuation input its source, its date and its lineage

When the committee asks where an assumption came from, the answer should take seconds, not a search.

Why it's harder than it looks: a comp set is pulled, pasted into a model and copied between workbooks. A sale recorded afterwards makes it stale without notice, and the input and the number it fed rarely sit in the same system.

1. 1.The Data Context & Catalog agent traces each input to its source records with trace_cross_platform_lineage, and checks its age with check_freshness.
2. 2.The Quality Monitoring agent flags comps affected by later recorded sales.
3. 3.Before any feed or definition change ships, blast_radius_analysis lists the valuation inputs, reports and models it would reach, as in end-to-end lineage.
4. 4.Autonomous Data-Conductor holds a changed input as a proposal with the diff, tie-out and affected comps.
5. 5.The valuation lead approves it and rejects any comp that is not an arm's-length sale.

6. Govern definitions and licences before analysts and copilots read the record

A copilot built on ungoverned tables spreads one wrong rent or stale comp to everyone who asks, and trust in the programme drops.

Why it's harder than it looks: asset management, finance and the lender each hold a version of occupancy, NOI and square footage. Licensed listings may not be redistributed, rent rolls hold tenant personal data, and unreleased deal data is more sensitive than either. Policy lives in contracts, while access is granted ticket by ticket.

1. 1.The Data Context & Catalog agent holds one definition of occupancy, NOI and area, answers through it with resolve_metric, and points to get_authoritative_source when two definitions disagree.
2. 2.The Data Access & Governance agent runs scan_pii on tenant files, and auto_tag_dataset marks sensitive and licensed fields.
3. 3.check_policy and enforce_rbac apply each rule the same way every time; provision_access issues time-boxed grants with an approval record.
4. 4.The data owner for each licensed feed approves who may see it, and the head of real estate data approves any change to a shared definition.

7. Hold valuation inputs, covenant figures and investor numbers for a named approver

These numbers set appraisals, loan terms and fund NAV, so a person must own them. The same discipline applies to lenders and financial services reporting.

Why it's harder than it looks: the choice is usually binary. Either everything waits for review and the team is the bottleneck, or changes go straight to production and are rolled back after someone notices. Neither gives an approver a before-and-after view they can sign in a minute.

1. 1.Autonomous Data-Conductor holds valuation inputs, covenant figures and investor reporting numbers at L2.
2. 2.The Data Access & Governance agent opens the review with request_governance_review, routed to the right person.
3. 3.The Pipeline Building and Quality Monitoring agents attach the diff, the tie-out and the downstream reports affected.
4. 4.The valuation lead approves valuation inputs; the asset management controller approves covenant and investor figures. The highest-risk changes need two different people, and the requester never approves their own.
5. 5.After approval the change applies with a rollback point, and get_audit_trail and generate_audit_report hold the evidence.
6. 6.Appraisal conclusions and valuation sign-off never go to an agent.

Where the line falls, task class by task class, in a mature deployment:

Designing the autonomy ladder

Autonomy is set per task class. L0 watches, L1 suggests, L2 acts after a named person approves, L3 acts and keeps a rollback point, L4 acts on its own within a boundary you set. L0 to L2 run today. L3 and L4 are where a domain can go on its own review record, never switched on everywhere at once. Only a domain's owner can raise its level.

The operating model: who owns what

Agents change who does the work, not who is accountable for it:

The swarm behind the practices

No single agent delivers these practices. Each is a hand-off between specialists, coordinated under the autonomy you set per domain.

Data Context Wizard holds one governed definition of occupancy, in-place rent, NOI and area, so reports, valuation models and the analyst copilot answer from the same place. Autonomous Data-Conductor routes each trigger and verifies the numbers that matter before the valuation pack. Spellbook Data Catalog (in preview) makes each property data product discoverable in plain English.

What disappears

The clearest sign the practices are working is what stops happening:

• •The county that quietly stopped updating three weeks ago.
• •The same building living under three addresses.
• •Rent rolls rebuilt by hand for every acquisition.
• •"Which occupancy number is right" in the middle of a committee meeting.
• •Comps in the deck that a recorded sale made stale.
• •A weekend of reconciliation before the lender certificate.

Bad data is caught where it enters, not where it is read. Every action leaves a signed receipt and a tamper-evident audit trail, so the team can see what happened and reverse it. The experience is quieter weeks before quarter-end.

A Head of Real Estate Data's scorecard

Targets to set against your own baseline, not results:

• •Layout change to verified model: targeting minutes, from about a day.
• •New county or MLS feed onboarded: targeting a day, from about two weeks.
• •Address and parcel exceptions older than a week: targeting none, each with a cause.
• •Rent roll units tied to the ledger each morning: targeting every unit tied or flagged with a cause.
• •Valuation inputs with source, date and lineage: targeting all of them.
• •Catalog and docs upkeep closed autonomously: targeting 88% as the deployment matures.

Where this goes next

Analyst copilots will answer more questions about rents, comps and exposure, so the governed definitions beneath them matter more each quarter. If the receipts in one domain stay clean, its owner can choose to move it a rung up the ladder: a decision made on evidence, domain by domain, and reversible.

The climb: from assisted to autonomous to agentic

Our thesis is that the data platform climbs the way analytics did, in stages, and that the hard part of data work was never knowing what to do but doing it. For real estate and proptech data teams:

• •Assisted. Agents work alongside your team and propose every fix with a receipt. Valuation inputs, covenant figures and investor numbers always go to a named approver.
• •Autonomous, under your governance. Routine work runs on its own within the level you set. Your team governs the agents instead of doing the upkeep.
• •The agentic enterprise. One trusted property and lease record, and valuation inputs the team can defend. People set direction; the platform carries it out.

You choose the altitude, every step is visible and reversible, and the pilot is the first rung. Neighbouring teams in the finance, insurance and investment data teams group share many of these sources and approvers.

The pilot: how real estate and proptech data teams start

The pilot is how your team proves the value on its own data before committing.

• •What we connect. County and MLS feeds, property management and rent roll sources, warehouse, dbt, orchestrator and BI tool, over MCP, inside your infrastructure. Nothing migrates.
• •Scope. Feed onboarding and layout-change mapping for your county and MLS sources, plus rent roll normalisation.
• •First week. Agents run at L1 across the scope, map each feed, definition and lineage path, and show the fixes they would have made, with receipts, before anything changes.
• •By week two. Layout mapping and ledger tie-outs run at L2: applied after a named person approves, with a rollback point. Valuation inputs, covenant figures and investor reporting stay held for their approvers.
• •At day 30. We review the metrics against your baseline:

• •New county or MLS feed onboarded: targeting from about two weeks to a day
• •Changed feed layout mapped: targeting from about a day to minutes
• •Rent roll normalised and tied to the ledger: targeting from half a day to minutes
• •the share of catalog and docs upkeep closed autonomously, targeting 88% as the deployment matures

• •What you decide. Whether to expand to the next domain. The pilot fee is credited in full against the first year.
• •The guarantee. In a 90-day pilot, ten engineering hours per data engineer per week are recovered against a baseline both sides sign on day one, or the $7,500 fee is refunded.
• •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.