Listings analysts scrape MLS or broker portals for new properties, often across a few ZIP codes, so inventory is ready before showing calls. The portals and fields don't change much from day to day.
Claude can read a listing. Pulling a full result set on a recurring crawl, including logins and pagination, is a different kind of work.
- Claude reads and reasons well about a single listing, but extracting real-estate listings at scale is a repeated, login-gated workflow, not a one-off question.
- The failure points are structural: authentication persistence, pagination across thousands of properties, anti-bot defenses, and non-deterministic output between runs.
- Computer Use adapts to a screen but re-reasons every step, and state-of-the-art computer use models still produce unexpected behavior 20 to 60 percent of the time on complex tasks, according to Airtop's research on Computer Use error rates.
- The pattern that holds up is deterministic: compile the login-paginate-extract flow once, and reserve the model for judgment calls, like classifying a relisted property or matching a buyer's criteria.
- Teams can describe the listing pipeline to Mark or compile it in Agent Builder and get a schedulable agent instead of a fragile prompt loop.
Where Claude is helpful for extracting real-estate listings
Claude is genuinely good at reading a listing page and telling you what matters. Paste in a property description and Claude can summarize square footage or flag a below-market price. Ask it to judge whether a listing fits a buyer profile, and it reasons through the tradeoffs the way an analyst would. That's exactly the kind of judgment work a language model is built for.
The divergence starts when the task stops being "read this page" and becomes "get this page, and the next 400 like it, every day, from a site that requires a login." Claude in chat has no persistent browser. Claude with Computer Use has a browser, but no memory of yesterday's session, no built-in way to handle a CAPTCHA, and no guarantee the DOM it screenshots today matches the one it reasoned about an hour ago. Extracting real-estate listings needs a live web session that logs in once, stays authenticated, and behaves the same way on the hundredth run as it did on the first. That's a runtime problem, not a reasoning problem, and it's the same tension as reaching a site through the page when there's no API.
Why extracting real-estate listings breaks
Authentication and session persistence. Most valuable listing data sits behind MLS or IDX logins, or inside a broker portal that requires SSO. Claude can type a username and password once, but chat sessions don't persist a logged-in browser between runs. Every new session starts from zero, which means every run risks re-triggering a login challenge or getting flagged for unusual sign-in behavior.
Pagination and scale. A single ZIP code can return hundreds of active listings across dozens of pages, often behind infinite scroll or a map-based interface that loads results as you pan. Asking a model to click "next page" 40 times in a row, reading and re-reading the screen each time, is slow and prone to drift. Miss page 12 and nobody notices until a buyer asks why a listing never showed up.
Anti-bot defenses and CAPTCHAs. Real-estate listing sites are scraped constantly, so many carry rate limits, IP-based blocking, and CAPTCHA challenges specifically to slow down automated pulls. Chat-based Claude has no mechanism to solve a CAPTCHA or rotate a proxy. It either stalls or returns a blocked page and reports partial success as if it worked.
Non-determinism. Run the identical extraction prompt against the identical listings page twice, and Claude can return different field names, different formatting, or a different subset of listings. That's fine for a one-time summary. It's a problem when downstream systems expect the same schema every time, and a silent format change breaks a pipeline nobody is watching in real time.
Can't we just use Computer Use?
The first Computer Use demo for extracting real-estate listings usually works. Claude takes a screenshot, clicks the login button, types credentials, clicks through a few listings, and returns something that looks like a clean table. It's easy to conclude the problem is solved.
The hidden cost shows up at volume. Computer Use re-reasons from a screenshot at every step, which means every click, scroll, and page load costs a model call. Multiply that by thousands of listings across multiple sites, and the run gets slow and expensive fast. Airtop's own research on the agency spectrum found that even state-of-the-art computer use models produce unexpected or incorrect behavior 20 to 60 percent of the time, depending on task complexity, the same reason extra agency helps the first run more than the hundredth. For a nightly listings pull that has to be right, that error rate compounds into missing rows, duplicate entries, and extraction runs that quietly fail without raising an alarm.
What works for extracting real-estate listings
The pattern that holds up separates two kinds of work, similar to the split described in code-first agents vs. LLM-first agents. Claude keeps the intent and the judgment: which markets to track, how to classify a listing as new versus relisted, whether a description matches a buyer's stated criteria. A managed browser runtime owns the interactive web steps: logging in, paginating, clicking into each listing, and returning structured data in the same shape every time.
This is deterministic AI: reason once at build time, then run the compiled artifact. You describe the workflow once, in plain language, and Airtop compiles the login, pagination, and extraction steps into reusable code. The model gets called only where the work is genuinely variable, like deciding whether a listing description matches a buyer's criteria. On a comparable multi-step task, a compiled Airtop agent ran in 1 minute 21 seconds for $0.063, against 7 minutes 58 seconds and $6.26 for the same task run step-by-step with Claude Code on Opus 4.7, according to Airtop's own benchmark, and compiled agents are up to 100x more efficient than traditional AI Agents, with the same result on every run instead of a fresh guess each time.
The compiled steps also self-heal. If a listing site changes its layout, the self-healing browser actions use a small amount of model reasoning to adapt, rather than breaking the whole pipeline. Session persistence and a built-in password vault mean the login only needs solving once, and Airtop supports up to 100 simultaneous sessions when a pipeline needs to cover multiple markets at once. For teams already building with Claude, the handoff doesn't require abandoning the tools already in place: you can run Airtop agents directly from Claude Code, or connect Claude Code to Airtop so Claude keeps planning while Airtop executes the browser steps, one conversation replacing a multi-tool stack.
Listing use cases that deterministic agents can solve
MLS and listing sites are session plus pagination plus a schema that marketing still has to interpret. Claude writes the narrative. The listing grid needs a compiled browser.
Capture new inventory from an MLS or IDX login
Broker portals paginate, throttle, and expire cookies. Claude can describe a property once you have the record. It cannot stay signed in and walk 40 pages of results overnight. A compiled agent can, then return structured rows.
Watch a geography for price cuts and status changes
A listing that goes pending, or drops $15k, is a judgment trigger. Detecting it requires the same search, rerun, with stable fields. Compile the scrape. Let Claude decide which changes are worth a note to the team.
Extract photos, remarks, and facts into a common schema
Every portal labels beds, baths, and HOA a little differently. Mapping those labels is reasoning. Clicking through the detail pages to collect them is repetition. Airtop does the clicks. Claude does the cleanup.
Keep an off-market or pocket-listing sheet in sync
Some inventory only appears after login, or only for a saved agent view. A chat session will not be present when that view updates. A compiled agent signs in, reads the view, and writes the sheet. Claude still drafts the client email.
Turning listing extraction into a durable pipeline
Extracting real-estate listings is a browser-reliability problem wrapped around a judgment problem, and Claude only solves half of that split. Keep Claude for reading listings, classifying them, and deciding what matters to a buyer or a market report. Hand the login, pagination, and repeat extraction to a runtime built for it, whether that means describe the listing pipeline to Mark or building it directly in Agent Builder.
Start extracting real-estate listings that don't break overnight
Stop rebuilding your listings pull every time a login expires or a page layout shifts. Start building your extraction agent for free and spin up your first agent in five minutes to get an MLS or broker-portal pipeline that logs in, paginates, and returns the same schema every run.
FAQs
Can Claude log into an MLS or IDX portal and stay signed in between runs?
Not reliably. Claude in chat has no persistent browser session, and Computer Use starts fresh each run, which means credentials, cookies, and any CAPTCHA challenge have to be handled again every time. A compiled agent with session persistence and a password vault logs in once and reuses that authenticated state, which is the core difference explained in browser automation vs. API-based tools.
Why does Claude return different results extracting the same listings page twice?
Chat-based extraction relies on the model reasoning fresh over what it sees each time, so field names, formatting, and even which listings get included can shift between runs. That non-determinism is fine for a one-off summary but breaks any pipeline expecting a stable schema. Deterministic AI solves this by reasoning once at build time and running the same compiled logic afterward.
What's the difference between Computer Use and a compiled agent for listings?
Computer Use re-reasons from a screenshot at every click and scroll, which is slow, expensive, and prone to the 20 to 60 percent error rates Airtop's research found on complex tasks. A compiled agent runs the login, pagination, and extraction steps as code, calling the model only for genuine judgment calls, which is why compiled agents are up to 100x more efficient than traditional AI Agents.
Can a listings extraction pipeline run on a schedule to catch new inventory daily?
Yes. Once a workflow is compiled rather than re-prompted each time, it behaves like software and can run on a schedule without a person babysitting each session. That's the same shift: the first build takes reasoning, and every run after that shouldn't.
Does this approach work on MLS/IDX sites that sit behind broker logins?
Yes. Because the browser session persists and credentials are stored securely, a compiled agent can authenticate once and keep pulling listings across sessions without re-triggering login challenges. This matters most on JavaScript-heavy, UI-only sites where there's no API to fall back on, which is exactly the case when listings only live in the page itself.
How do I keep Claude in the loop for judgment while Airtop handles the browser work?
You don't have to choose one or the other. You can run Airtop agents directly from Claude Code or connect Claude Code to Airtop, so Claude keeps planning and classifying listings while Airtop executes the login, pagination, and extraction steps reliably.
What happens when a listing site changes its page layout mid-pipeline?
Compiled Airtop actions carry a degree of self-healing, using a small amount of model reasoning to adapt when a site's DOM changes, instead of failing the entire run. That's part of what compiling a workflow means, rather than hardcoding brittle selectors.
Is it faster to just build this myself with Claude Code and a scraping library?
You can, but it costs more in reasoning steps and dollars than it looks like at first. On a comparable task, a compiled Airtop agent ran in 1m21s for $0.063 versus 7m58s and $6.26 for the same task run step-by-step in Claude Code, and code-first agents vs. LLM-first agents require meaningfully fewer reasoning steps than JSON-based tool-calling approaches.
