Real estate data teams: land every county feed, report on time

Key takeaways

• •Who this is for. The team that owns property, lease and valuation data as a product, at a REIT, an investment manager, a brokerage, a lender or a proptech platform.
• •The problem today. Hundreds of county recorder, tax assessor and MLS feeds that each change layout on their own schedule, addresses that do not match parcels, rent rolls that arrive in a different format from every property manager, and comps that go stale between the pull and the committee.
• •What changes. A changed feed layout is mapped into the property record the day it happens, addresses and parcels are re-matched with the uncertain cases queued for a steward, and every valuation input carries its source, its date and its lineage.
• •What stays with your people. Valuation inputs, lender covenant figures and investor reporting numbers: they drive appraisals, loan terms and fund NAV, so a named approver signs each change with a before-and-after view. Appraisal conclusions stay entirely with people.
• •The result. A real estate data team that ships one trusted property and lease record, valuation inputs you can defend and reporting that lands on time, instead of fixing feeds and rebuilding rent rolls by hand.

The PRD for agentic real estate and proptech data teams

This is the requirements document we would write with you for your team. Everything below expands on it.

What going fully agentic and autonomous means for real estate and proptech data teams

• •Put your data pipeline on autopilot. County, assessor and MLS layout changes are mapped into the property record the day they happen, so a Friday format change never becomes a Monday gap in coverage.
• •Run the data back office without the busywork. The work that fills the week today moves to agents: re-mapping feeds, re-matching addresses to parcels, normalising rent rolls and chasing why a comp does not tie.
• •Scale data without scaling headcount. A new county, a new market, a new property manager or an acquired portfolio adds sources, not headcount, because onboarding, mapping and tie-out are routine work for the swarm.
• •Get the plumbing off your plate. A data team that ships valuation inputs, portfolio analytics and tenant-facing products instead of repairing the feeds underneath them.

Who this is for

The team that owns property, lease and valuation data as a product. At a REIT or an investment manager, it sits between asset management, acquisitions and finance, feeding underwriting, portfolio reporting and investor and lender packages. At a brokerage or a listings marketplace, it runs the MLS and public-record pipelines behind search, pricing and agent tools. At a lender or servicer, it supplies collateral, rent roll and tax data to credit and surveillance. At a proptech platform, it runs the property graph and valuation models the product is built on.

The titles: Head of Real Estate Data, Director of Property Data, Data Product Manager (Valuation or AVM), VP of Data and Analytics for an asset manager, Director of Portfolio Analytics, and the data platform leads who report to them. These leaders often run several platforms at once, each feeding reporting, models and, increasingly, AI agents that analysts and asset managers ask about rents, comps and exposure.

This playbook is one of the finance, insurance and investment data teams pages; the rest of that group covers the neighbouring teams you share data with.

The product you ship

• •The property record: parcels, addresses, buildings and units as one governed identity, with deeds, liens, tax assessments and permits attached.
• •Listings and market data: MLS listings, sold records, rents and days on market, mapped to one set of field definitions regardless of source.
• •The lease and rent roll record: leases, rents, escalations, tenants, occupancy and arrears, normalised across property managers and systems.
• •Valuation inputs: comparable sets, cap-rate and rent assumptions, AVM features and the source trail behind each number.
• •Portfolio and asset reporting: NOI, occupancy, leasing activity and debt metrics for investment committees, investors and lenders.
• •Building and ESG data: meter, sensor and utility data rolled up to the asset for energy, emissions and sustainability reporting.
• •Analyst and agent products: governed context so an analyst copilot answers rent, comp and exposure questions from the same definitions as the reports.

Where the week goes

• •Feeds change without notice. A county moves its assessor export to a new layout, an MLS adds fields, a vendor renames a column, and parcels quietly stop updating.
• •Addresses and parcels do not match. The same building appears as three addresses, a unit number moves into the street line, and a parcel split leaves two records where there was one.
• •Rent rolls arrive in every shape. Every property manager and system has its own columns, charge codes and date conventions, and each acquisition adds more.
• •Comps go stale. The set was pulled last week, a sale has since been recorded or reclassified, and nobody can say which inputs fed the number in the committee deck.
• •Definitions are contested. Asset management, finance and the lender each have a version of occupancy, NOI and square footage.
• •Reporting dates do not move. Investor reports, lender certificates and fund valuations land on fixed dates, whatever happened to the feeds the week before.
• •Access is mixed. Tenant personal data, licensed MLS content and unreleased deal data need different rules.

Add it up and upkeep is most of the team's week. Here is how a typical week splits today, and once agents own the back office:

Time spent on new data products moves from 14% of the week to 46%. Most of the rest becomes review: people steer and approve agent work instead of doing it by hand.

Then and now

These are the impact metrics we move for real estate and proptech data teams, stated as targets:

• •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

Across the routine work in this domain:

The biggest change is onboarding a new county or MLS feed. Work that waited in queues finishes in minutes or hours, because agents detect, fix and verify in one pass. For a fuller treatment of how new sources get landed, see agents onboard new sources in days.

Use cases, in depth

A county changes its assessor export

Today. A county moves to a new layout. Nobody notices until coverage for that county drops or assessed values stop updating, and an engineer spends a day working out which columns moved.

With Data Workers. The Connectors agent sees that the feed changed, the Schema Evolution agent maps the new layout to the property record and checks it against the old one, the Pipeline Building agent updates the staging model with tests, and the Quality Monitoring agent proves coverage and value ranges still hold. The work is a schema change handled before it reaches a report, not after.

What changes. Coverage never dips, and the change arrives with a record of what moved and how to reverse it.

Rent rolls from every property manager

Today. An acquisition closes and the portfolio arrives as a dozen spreadsheets and system exports. Analysts map charge codes, date formats and unit identifiers by hand, then reconcile to the ledger before anyone trusts occupancy.

With Data Workers. Connectors land each rent roll, the Pipeline Building agent builds a mapping to the one lease record with tests, Data Context Wizard records the governed definitions of occupancy, in-place rent and arrears, and Quality Monitoring ties rents to the ledger and flags the units that do not tie.

What changes. The acquired portfolio joins the same trusted record in days, and the next property manager is configuration, not a project.

Valuation inputs you can defend

Today. The committee asks where a rent assumption or a comp came from. Answering means finding who pulled it, from which feed, on what date, and whether a sale was recorded afterwards.

With Data Workers. Data Context & Catalog traces each input back to its source records with end-to-end lineage, the Quality Monitoring agent checks freshness and flags comps affected by later recorded sales, and a valuation input change is proposed with its diff and held for the valuation lead.

What changes. Every number in the valuation pack answers "where did this come from" in seconds.

For lenders, servicers and credit teams

Lending teams use the same property record for collateral, rent roll and tax data, and add covenant and surveillance reporting on fixed dates. The same swarm applies: rent roll and operating statement tie-outs run daily, collateral changes are traced to the source record, and covenant figures are proposed with their diff and held for a named approver. The related credit risk data use case shows how exposure and collateral data are kept consistent through system releases.

Measure the product, not just the pipeline

Real estate data leaders are judged on valuation accuracy, reporting timeliness and the speed of onboarding a new market or portfolio, not table counts. The Autopilot dashboard shows how much of each data product's upkeep runs on its own and at what token cost, so the team can show asset management where its time now goes: new sources, better comps and portfolio analytics instead of feed repair.

Agents working together: Quarter-end, when a county feed changes layout

Every real estate data team knows the week before quarter-end. Valuations refresh, investor reports and lender certificates are due, and the property record has to be right. The risk is a feed that changed quietly three weeks ago. This is the same week run by Data Workers.

The setup

The property record runs on Snowflake and dbt, orchestrated by Airflow. It feeds a quarterly valuation pack, a lender covenant certificate, an investor report and an analyst copilot. Autonomy in Autopilot:

• •Feed layout mapping and staging: L2 today; a candidate for L3 on evidence.
• •Address and parcel matching, rent roll normalisation: L2 for routine matches, with uncertain matches queued for a data steward.
• •Valuation inputs, covenant figures and investor reporting numbers: L2, held for the valuation lead and the asset management controller.
• •Appraisal conclusions and valuation sign-off: L0.

The team scheduled one mission the week before: "Refresh valuation inputs for quarter-end and tie them to source."

06:00 - the feed changes

The assessor export for one county arrives with renamed columns and a split owner field. Three counties' recorded-sales files arrive the same morning, and one property manager's rent roll lands late with a new charge code.

06:03 - map the change

Connectors agent flags that the county feed no longer matches its last known layout.

Schema Evolution agent maps the renamed columns and the split owner field to the property record and checks backward compatibility with the history already loaded.

06:15 - update the model and test it

Pipeline Building agent updates the staging model for the county and adds tests for the new fields. It reprocesses the last 30 days from raw so nothing between the change and today is missing.

06:40 - prove it ties

Quality Monitoring agent runs the checks the team relies on:

• •Parcel counts and assessed value totals for the county tie to the previous load, within the county's normal range.
• •Every address in the new loads resolves to one parcel, except 41, which it queues for a steward.
• •Rent roll units tie to the ledger, except six, which it flags.

06:52 - find the cause

Incident Debugging agent traces the six rent roll differences to a new charge code that the property manager uses for a parking fee, and proposes mapping it to ancillary income. It traces 12 of the 41 address queue items to a parcel split recorded last month.

07:10 - update meaning, then verify

Data Context Wizard records the governed definitions of ancillary income and the split parcels with provenance. Data Context & Catalog refreshes lineage for every valuation input that read the changed feed, so the comps set shows which inputs moved.

Autonomous Data-Conductor checks the outcomes: the comps set picks up the recently recorded sales, in-place rent ties to the ledger, and the analyst copilot reads the updated definitions. Because valuation inputs sit at L2, Conductor sends one decision to the valuation lead: the full diff, the tie-out results and the changed comps.

08:20 - approved

The valuation lead approves the inputs and rejects two comps as non-arm's-length sales. A steward resolves the remaining address items. Conductor applies the decisions and publishes.

10:00 - the packs run

The valuation pack, the covenant certificate and the investor report read the refreshed inputs. Every number carries its source and date. Nobody files a ticket.

What stays behind

• •A versioned mapping for the county's new layout, with tests, so the next change is caught the same way.
• •A receipt for every change: who proposed it, who approved it and how to roll it back.
• •Updated Spellbook pages for every affected property data product.
• •A reusable mission. Next quarter's refresh runs the same way, and the team can move more of it to L3.

Minute by minute

This is an illustrative example. The property record runs on Snowflake and dbt under Airflow; the valuation pack, covenant certificate and investor report read it at 10:00. Valuation inputs are at L2.

The agents on the job

Data Context Wizard holds one governed definition of occupancy, in-place rent, NOI, net and gross area and every level of the property hierarchy. Reports, valuation models and the analyst copilot answer from the same definitions, so the copilot and the committee deck never disagree. Autonomous Data-Conductor verifies the numbers that matter before the valuation pack and before agents read them. Spellbook Data Catalog makes each property data product discoverable for analysts, asset managers and finance, in plain English.

What goes on autopilot

Once a domain has earned it, this work runs on its own, and each item removes a problem your team deals with today:

• •County, assessor and MLS layout changes are mapped into the property record the day they happen, so coverage does not dip while someone finds the cause.
• •Addresses and parcels are re-matched on every load, so the same building stops appearing as three records and the uncertain cases go to a steward instead of the pile.
• •Rents are tied to the ledger every morning, so occupancy in the asset report and in finance stop disagreeing.
• •Catalog pages and lineage refresh as sources change, so "where did this come from" has an answer without a search.

Where your people stay in charge

Agents never get blanket access. Each domain has its own autonomy level, set by you, and it only rises when the receipts show the agents are reliable. Everything starts at L1, observing only; reversible upkeep such as reruns, staging fixes, documentation and cleanup is usually first to run on its own.

• •Valuation inputs always go to a named approver: they feed appraisals and fund valuations, so the valuation lead approves each change with before-and-after values.
• •Covenant figures and investor reporting numbers go to the asset management controller with the full diff and tie-out.
• •Non-arm's-length and special-case comps stay a judgement call for the valuation lead.
• •Appraisal conclusions and valuation sign-off stay entirely with people.

Once a deployment has matured, here is how that ladder plays out across task classes:

Catalog and docs upkeep closes autonomously 88% of the time, as a target. For valuation inputs and reporting figures, autonomous closure is 0% by design: every change is proposed with a full diff and approved by a named person.

What happens when an agent is wrong

• •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the blast radius and how to roll it back. Unanswered requests expire and escalate.
• •L3 and L4 are where a domain can go next, on its own review record: acting on its own, with a rollback point on every change. Only the domain's owner raises its level, and if people start reverting the agents' changes, the domain pauses itself.
• •No agent approves or promotes its own work. Autonomy only grows on evidence, domain by domain, and repeated reverts pause the domain.
• •One org-wide stop halts all autonomous dispatch, and every action lands in a tamper-evident audit trail you can export with generate_audit_report.

How it fits your stack

Data Workers connects to what you already run: county recorder and assessor feeds, MLS feeds over the RESO Web API or older flat files, property management and lease systems, Snowflake, Databricks or BigQuery, dbt, Airflow or Dagster, and your BI tool. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Nothing migrates. For the wider picture, see AI for real estate data infrastructure, and for catching a county feed that changes layout, schema drift detection on Snowflake.

• •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows.
• •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged.
• •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set for that domain.
• •Fits the standards you already use. Field mappings can follow the RESO Data Dictionary for listing data, so a new MLS maps to the same definitions as the last one.
• •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers can read exactly what the agents call.

Governance and regulation

Real estate data touches several kinds of control. Listing data carries MLS and vendor licence terms that limit who may see and redistribute it. Rent rolls hold tenant personal data. Valuations feed fund reporting and lending decisions, and ESG figures feed disclosures. Data Workers keeps access scoped with provision_access, holds valuation and reporting changes for a named approver, detects personal data in tenant files and records every change in a tamper-evident audit trail.

Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.

The alternatives real estate data teams weigh

Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt. The work is everything around it: routing approvals to the valuation lead, blast radius, rollback, receipts, and current context about every other system.

Data vendors and property data providers. Vendors sell cleaned parcels, listings and valuations, and they are a good source. They do not own your lease data, your rent rolls or the tie-out between a vendor number and your ledger, and each vendor still changes its feed. Data Workers sits under them, keeping what lands correct.

Observability, catalogs and point tools. Observability alerts, catalogs document, and quality tools test. Data Workers takes their signals, diagnoses, proposes the fix, verifies it and leaves the receipt. See how a self-maintaining catalog differs from a static one.

Platform-native agents. Snowflake made its managed MCP server and Cortex Agents generally available on Nov 4, 2025, and Databricks made Genie One generally available on Jun 16, 2026. They are excellent inside their platform; this work crosses county feeds, MLS, property managers, the orchestrator, warehouse and BI, and Data Workers works across all of them.

In this space specifically. Property management, lease abstraction and valuation software hold their own records well; Data Workers keeps the data between them consistent and traceable, so the property record the models read matches the one finance reports.

The case for your CTO

What this replaces. Feed repair after every county and MLS change, rent roll mapping for every property manager, and the scramble to explain a comp before quarter-end.

What your team gets back. A data team that ships valuation inputs, portfolio analytics and agent products instead of repairing feeds and answering "which number is right".

Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the warehouse, orchestrator, dbt project and source systems you already run, under the roles you already govern, inside your own infrastructure. Your engineers can read every tool the agents call in the open-source core.

Risk and control. Autonomy is set per domain. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; valuation inputs, covenant figures and investor reporting stay at L2 with a named approver; and one org-wide stop halts all autonomous work.

Why now. More of the questions about rents, comps and exposure are being answered by AI agents, and an agent will repeat a stale comp or a mismatched address with confidence. The record underneath has to be right before they read it.

The first win. Feed onboarding and layout-change mapping for your county and MLS sources. The pilot below lays out the scope, what you see each week and the cost.

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, the climb looks like this:

• •Assisted. Agents work alongside your team. They read the whole stack, show what needs doing and propose every fix with a receipt; valuation inputs, covenant figures and investor reporting always go to a named approver.
• •Autonomous, under your governance. Routine work runs on its own: layout changes are mapped the day they happen, addresses and parcels are re-matched on every load, rents are tied to the ledger every morning. Your team governs the agents instead of doing the upkeep.
• •The agentic enterprise. A real estate data team that ships one trusted property and lease record and valuation inputs it can defend. People set direction, and the platform carries it out.

You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.

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. Your 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, starting at L1, with staging work at L2.
• •First week. Agents run at L1 across the scoped domain. They map every feed, definition and lineage path and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
• •By week two. Layout changes mapped the day they happen and rents tied to the ledger every morning start running on reversible work. Valuation inputs, covenant figures and investor reporting stay at L2 with a named approver.
• •At day 30. We review the impact 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.
• •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.

The pilot is the start of a longer curve:

By month 12, more than 42% of agent actions run fully autonomously and manual work falls below 10%, while valuation inputs and reporting figures stay with a named approver.

FAQ

Does it work with MLS feeds that use the RESO Web API? Yes. Agents connect to the feed like any other source, and field mappings can follow the RESO Data Dictionary.

Can it match addresses to parcels? Agents build and test the matching in your own pipeline and re-run it on every load. Uncertain matches go to a named data steward rather than being guessed.

Will agents change a valuation input? Valuation inputs are L2: proposed with a full diff and approved by the valuation lead.

Can it ground our analyst copilot? Yes, through governed definitions in Data Context Wizard, so the copilot and the reports use the same occupancy, rent and NOI.

Where do the agents run? In your infrastructure, with your credentials and model key. The hosted Conductor sees workflow metadata only.

Do we have to migrate anything? No. Your warehouse, dbt project, orchestrator, catalog and BI stay where they are.

Sources

• •Data Workers pricing: https://dataworkers.io/pricing/
• •RESO, Data Dictionary (standard field names and definitions for real estate listing data): https://www.reso.org/data-dictionary/
• •Snowflake, managed MCP server and Cortex Agents GA release note (Nov 4, 2025): https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp
• •Databricks, Genie One launch (Jun 16, 2026): https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team