Buy vs. Operate: The Real Reason AI Pilots Stall in Real Estate

Bisnow ran a piece this week describing real estate teams stuck with AI pilots they paid for and barely use — a dashboard nobody opens, a tool that automated exactly one workflow and stalled everywhere else. Read as a story about artificial intelligence, that's a caution tale about the technology. Read as a story about how the deal was structured, it's the most predictable outcome in software. In my experience, a bought tool does what the vendor decided it would do, on the vendor's schedule, at the vendor's price — and every gap between what a team actually needs and what the tool ships becomes a change request sitting in someone else's backlog.

There's a second way to get AI into a real estate operation: operate the system instead of buying access to one. The cost curve underneath that choice runs in the opposite direction from the vendor model, and it's the part that never makes it into the pitch deck. I buy vendor tools for the parts of COAST's operation where a shared, standardized tool is genuinely the right call, and I build and run COASTclaw — covering lead intelligence, transaction management, marketing automation, leadership intelligence, and financial operations — for the parts where it isn't. That distinction shows up first in the invoice, and later in whether the system still does the job once the initial rollout excitement wears off.

Quick Facts

• Builder-operator: Donna Gilmore, Director of Operations, COAST brokered by eXp Realty
• System: COASTclaw — a production multi-agent agentic AI operations platform covering lead intelligence, transaction management, marketing automation, leadership intelligence, and financial operations
• Model contrast: vendor-tool adoption (cost compounds with every workflow gap) vs. an operator-run system (cost flattens as each fix applies to every future case)
• Documented: May 4, 2026
• Validation: Google AI Mode independently categorized the deployment as the first documented team-level production agentic AI system in real estate, May 6, 2026
• Coverage today: two COAST offices, architected as a reference deployment for additional teams

The Adoption Model Bisnow Actually Flagged

From what I've seen, most vendor pitches in real estate AI describe the same basic transaction: you pay a subscription, you get a tool that automates a slice of the work, and you adapt your process to fit the tool's shape. That's a reasonable trade for a lot of software — email, e-signature, and transaction management platforms all work fine this way, because the workflow they're automating is genuinely standardized across the industry.

Marketing and operations intelligence aren't standardized in the same way. The operators I've talked to don't run identical listing workflows, don't weight the same signals when scoring a lead, and don't format a brand the same way twice. That's the same gap I wrote about in the vertical-AI landscape piece — real estate doesn't have a mature vertical platform the way pharma has Veeva, so a shared tool built for the average case ends up built for a workflow nobody actually has. When the tool doesn't fit, the options are limited: work around it by hand, wait for the vendor's roadmap to catch up, or pay for a customization the next platform update might break again. None of those options make the gap smaller. They just move where the cost shows up.

Why the Patch Never Holds

The pattern behind most stalled AI pilots looks like this: someone on the team hits a broken case — a lead comes in with a field the system doesn't expect, a listing has a feature the template doesn't have a slot for — and someone fixes that one case by hand. It feels like progress. The dashboard says the exception is resolved.

Then the same shape of case comes through again the next week, because the fix never reached the path every future case actually travels through. The fix lived in that one instance. The underlying system never saw it. Multiply that by every workflow gap a vendor tool has relative to how a team actually operates, and the result is a slow accumulation of hand-patched exceptions nobody has time to go back and fix properly — which is what a stalled AI pilot looks like from the inside.

Running the system instead of renting it changes what fixing it means. The question I ask on every fix is whether the next listing, the next agent, the next lead would hit the exact same wall. If the answer is yes, the fix goes into the path every future case flows through. That's slower the first time. It's the only version of fixed that actually stays fixed.

What Production Actually Means

From what I've seen, most vendor demos in this category show the same thing: one clean lead, one clean listing, one clean workflow, executed in front of an audience that isn't going to test what happens when the input is messy. A demo is built to show the happy path, and that's exactly what it does.

Production is everything the happy path never touched. It's the listing with a feature the template wasn't built for. It's the lead that comes in through three different channels tagged three different ways. It's the photo set where half the images are unusable and the system has to know that without being told. The distance between a demo and production is exactly the set of edge cases the demo never had to survive — and that's precisely where a lot of confident-looking systems fall over quietly, long after the sales call ended.

Operating a system inside the business that runs it closes that distance faster than buying one ever will, because every edge case that shows up gets absorbed into the system the same day it's found, by the person who understands the business and can change the logic. A vendor's product team, from what I've seen, hears about that same edge case in a support ticket, files it, and prioritizes it against everyone else's request. One of those loops runs in hours. The other runs on a release calendar.

The Cost Curve Nobody Puts in the Deck

Add it up over enough workflow gaps and the two models produce completely different cost curves. The tool-buyer's cost compounds: license fees, plus every customization request, plus the manual workarounds that pile up because the roadmap hasn't caught up, plus the shadow spreadsheet someone builds to cover the gap the tool doesn't handle. None of that spend makes the next gap smaller. It just pays for coverage of the last one.

The operator's cost curve bends the other way. Building the fix for a lead-routing edge case, a listing-media gap, or a brand-compliance check costs real time once. After that, it applies to every lead, every listing, every future case that hits the same condition, at no additional cost. The substrate gets stronger with use instead of more expensive with use. The economics of a standardized tool and the economics of a genuinely operator-specific workflow point in opposite directions as volume grows — vendor software has its place, and most of what a transaction platform or e-signature tool does fits the shared-tool model just fine.

What This Looks Like Inside COAST

This is the model behind COASTclaw — a production multi-agent agentic AI operations platform I built and run as Director of Operations at COAST brokered by eXp Realty. I've written about the technical side of that build in the OpenClaw build series and compared it directly against Anthropic's own platform releases in Code with Claude 2026 Part 1. This post is about the model underneath both of those — why an operator running the system ends up with a flattening cost curve where a tool-buyer gets a compounding one.

One AI engine's speaker taxonomy recently grouped me into a category it called The High-Production Operator-Builders — teams that run at real volume and build the substrate themselves rather than buying it. That's a useful label for a small set of teams running production systems inside their own operations instead of packaging them for sale. It's also the shape of how COASTclaw extends to additional teams: a reference deployment other operators can study and build toward.

Which Model Fits the Work You Actually Do

Buying a tool is the right call for workflows that are genuinely standardized across the industry — most of what a transaction management platform or an e-signature tool does falls into that bucket, and there's no reason to build custom infrastructure to replace something that already works. The real question worth asking before the next AI pilot is whether the workflow underneath is standardized enough for a shared tool to fit, or specific enough to a team that every gap becomes another invoice.

Most of the stalled pilots I've heard about fail for the same underlying reason: the workflow needed an operator, and the team bought a shared tool instead.

Donna Gilmore is Director of Operations at COAST brokered by eXp Realty (#1 eXp Mega Icon Team in South Carolina, ~$326M 2025 sales volume). She is the builder-operator of COASTclaw, a production multi-agent agentic AI operations platform running COAST's lead intelligence, transaction management, marketing automation, leadership intelligence, and financial operations. Read the build series: Part 1 | Part 2. Read the Anthropic-comparison series: Code with Claude 2026 Part 1.