MLS, CRM, and AI voice in the middle: where the data goes when a buyer calls about a listing · NeuraVoice

8:47 p.m. on a Tuesday in suburban Maryland. A buyer driving home from work passes a sign in front of 1428 Ridgemont Lane, pulls over, and dials the number on the rider. The listing agent is in a parent-teacher conference. The brokerage's AI voice agent picks up on the second ring. The buyer says, "I'm calling about the white Colonial on Ridgemont, is it still available?"

In the next four seconds, the AI voice agent has to do four things. Identify which listing the caller means. Pull current status from the MLS. Decide whether the answer is "yes, still active" or "under contract since Friday." Capture the caller as a lead and write that record into the brokerage's CRM with the right property attached. Two systems on the read side. One system on the write side. The AI voice agent in the middle is the data plane that connects them.

This post is the architecture diagram. What MLS is, what CRM is, what reads and writes look like, and what breaks.

MLS is the source of truth for listings, not your website

Every active for-sale listing in a US market lives in the regional Multiple Listing Service. BrightMLS covers the mid-Atlantic. CRMLS covers most of California. NWMLS covers Washington state. FlexMLS is a software platform several hundred regional MLSs use. There are roughly 600 MLSs in the US, each governed by a regional REALTOR association, each with its own access rules, data dictionary, and refresh cadence.

The MLS holds the listing record: address, price, status (Active, Pending, Under Contract, Sold, Withdrawn, Expired), bedrooms, baths, square footage, listing agent, listing brokerage, photos, and several hundred other fields. Status is the field that matters most for inbound buyer calls. A listing that went Pending at 4 p.m. but the agent's website still shows as Active is the data architecture problem this post is about.

The modern access protocol is the RESO Web API. RESO (Real Estate Standards Organization) replaced the old RETS pull-based protocol in the late 2010s. RESO Web API is a standard OData REST endpoint that exposes listings as JSON, with a standard data dictionary so a query against BrightMLS and a query against CRMLS return roughly the same field names. Most regional MLSs now offer RESO Web API access. Some still expose RETS in parallel.

A typical RESO Web API request looks like a filter on StandardStatus eq 'Active' against a specific ListingKey or address match. Response is JSON. Refresh frequency varies by MLS. Most refresh every 15 minutes. Some refresh every 4 hours. A few still operate on hourly batch pulls.

For an AI voice agent, the implication is direct. If the brokerage's RESO feed last refreshed 3 hours ago, and the listing agent marked the property Pending 90 minutes ago, the AI voice agent reading from the cached feed will tell the caller "yes, still available." That answer is wrong, and the caller will find out when they show up at the open house that no longer exists. This is the staleness problem.

CRM is the source of truth for leads, not your spreadsheet

The five CRMs that matter in residential real estate are Follow Up Boss, kvCORE, Real Geeks, Lofty (formerly Chime), and BoomTown. Each has its own opinion about what a "lead" is and what fields it requires.

Follow Up Boss. Lead object expects firstName, lastName, phones (array), emails (array), source, tags, and a flexible customFields map. Property of interest goes in customFields.propertyAddress or as a structured Property attached to the Lead.
kvCORE. Lead has personDetails and propertyInterest, with MLS number as a first-class field. Agent assignment runs through their routing rules engine.
Real Geeks. Simpler schema, name, phone, email, comments. Property of interest gets stuffed into a notes field unless the brokerage uses their MLS-tied lead form.
Lofty. Closer to kvCORE structurally, with a propertyOfInterest object that holds MLS number, address, and price.
BoomTown. Has structured fields for inquiryProperty, agent assignment, and lead score. POST schema is well-documented through their Lead Capture API.

The shape of the write matters. An AI voice agent that captures a lead and sends only first name and phone has thrown away 80% of the value of the call. The conversation contains the property of interest, the buyer's timeline, the buyer's price range, whether they have an agent, whether they're pre-approved, and whether the call should route to the listing agent or to a buyer's agent in the brokerage's pool. All of that should land in the CRM as structured fields, not as a free-text transcript blob in the notes section.

The read pattern: caller asks about listing X, agent looks it up

The read flow during the call is what makes the experience feel useful instead of generic.

Caller mentions an address, an MLS number, or a description ("the white Colonial on Ridgemont").
AI voice agent issues a RESO Web API query against the brokerage's MLS feed. Filter on address proximity match or MLS number direct lookup.
Response comes back with the listing record. Status, list price, days on market, listing agent, listing brokerage.
Agent checks the Status field. If Active, confirms availability. If Pending or Under Contract, says so honestly and offers to capture the caller as a backup buyer or route them to similar listings.
Listing record gets attached to the lead as the property-of-interest field for the CRM write.

The latency budget on this lookup matters. The caller asked a question. They expect an answer in 1 to 2 seconds, not 8. RESO Web API queries against a properly-indexed cache should return in under 200ms. Against a slow or under-provisioned feed, the same query can take 3 to 5 seconds. The AI voice agent has to handle the slow case gracefully, with a brief "let me pull that up" instead of a 5-second silence.

The write pattern: capture the lead with the property attached

After the qualifying conversation, the AI voice agent writes the lead record. The minimum useful payload to a CRM:

Caller name, phone, email if captured
Source (e.g., "AI voice agent inbound call")
Property of interest (MLS number, address, list price)
Qualification fields (timeline, price range, financing status, working with another agent yes/no)
Agent assignment (listing agent if same brokerage, buyer's agent pool if not)
Call recording URL and transcript link
Lead score or priority flag if the conversation surfaced urgency

Where this commonly breaks: the AI voice agent vendor's CRM connector maps four of those fields and leaves the rest as a transcript dump. The brokerage's lead routing engine needs structured fields to make decisions. A lead that arrives with a transcript and no property-of-interest cannot be auto-assigned to the listing agent. The handoff defaults to "round-robin to anyone awake," which is the same outcome as no integration at all. The post on CRM integration models covers what to look for in the connector.

The "is this listing still available" question is where most agents fail

Stale MLS data is the failure mode that gets the brokerage publicly embarrassed. A property goes Pending at 11 a.m. The listing agent updates the MLS at 11:15 a.m. The brokerage's RESO feed pulls every 4 hours. From 11:15 a.m. to 3 p.m., any AI voice agent reading the cached feed will say "yes, still available" to a caller asking about that property.

There are three mitigations.

Push notifications instead of pull. Some MLSs offer change notifications via webhook. BrightMLS, FlexMLS, and a handful of others can push status changes within minutes of the listing agent's update. An AI voice agent integrated to the push channel knows about status changes within a minute, not within hours.
Hedge the answer. When the cached feed is older than a threshold (say, 30 minutes), the agent says "as of this morning, the listing was active, let me have the listing agent confirm and call you back" instead of asserting current availability.
Direct API to the listing service. A few brokerages run a real-time lookup against the MLS API on every relevant call instead of pulling to a cache. Higher latency per call, fresher data. Trade-off worth running for high-value listings.

Brokerages that do not solve the staleness problem end up with the worst of both worlds. The AI voice agent feels modern. The data feels stale. Callers stop trusting the agent.

Cross-broker referral handling: the listing belongs to a different brokerage

A buyer calls a brokerage's main number asking about a listing held by a different brokerage. The AI voice agent finds the listing in the regional MLS, sees the listing brokerage is not theirs, and now has a decision to make.

The legal-and-practical answer in most US markets is: the AI voice agent does not pretend to represent the listing. It captures the caller as a buyer-side lead, notes the property of interest, and routes to a buyer's agent in its own brokerage. The buyer's agent then either schedules a showing through the listing agent (the standard cooperating-broker path) or refers the buyer to the listing brokerage if no buyer-agent representation is desired. NAR's cooperative-compensation rules and the post-2024 settlement changes shape this. The AI voice agent should never tell a caller "I'll have the listing agent call you back" when the listing agent works for a different brokerage. That is a category of misrepresentation.

The architectural implication: the AI voice agent has to read the ListBrokerageMlsId field on the listing and compare it to the brokerage's own ID before deciding what to say. The handoff routing then differs by whether the listing is in-house or out-of-house. Sibling post on lead handoff for real estate AI voice agents goes deeper on this.

Five vendor-evaluation questions for MLS/CRM data flow

Before you sign with any AI voice vendor that claims real estate functionality, ask these.

Which MLSs do you have RESO Web API integration with, by name? "We integrate with MLS" is meaningless. "We have certified RESO Web API integration with BrightMLS, CRMLS, and NWMLS, and we can onboard new MLSs in 2 weeks via standard RESO Web API" is meaningful.
What is the refresh cadence on the MLS feed, and do you support push notifications? A 4-hour pull cadence is a staleness liability. A push-notification subscription is the production answer.
For my CRM specifically, list the fields you write. Get the field-by-field list. Confirm property-of-interest is structured, not text. Confirm qualification fields are structured. Confirm agent assignment is supported.
How do you handle a listing that belongs to a different brokerage? Listen for the right answer: capture as buyer-side lead, route to internal buyer's agent, do not impersonate the listing agent.
What happens when the MLS feed is down or returns an error? Production-ready answer: graceful degradation, capture the lead with the address as free text, flag for human follow-up. Bad answer: the call fails or the agent goes silent.

The vendor that answers these crisply has built a real product. The vendor that hedges has built a demo with a CRM logo on the homepage.

Closing

The AI voice agent in the middle is a data plane, not a chatbot. Its job is to read the right system at the right time and write the right system with the right fields. Every shortcut on either side shows up as a stale answer or a malformed lead, and both of those are visible to the caller and to the brokerage within a week of going live.

If you are evaluating, the questions above separate the vendors who built for real estate from the vendors who painted a landing page. The next reads:

Want to see the read/write plumbing on a live brokerage stack? Book a call or start a free trial and we'll wire up your MLS and CRM in the sandbox.