Why Generic AI Keeps Getting Commercial Real Estate Wrong

I have been selling technology to commercial real estate firms for more than twenty-five years. In that time I have watched a lot of tools get bought on the strength of a demo and abandoned six months later. The pattern is almost always the same: impressive output in a controlled environment, then a gap opens the moment the tool meets how the firm works. AI has made that gap harder to see before it opens, because the output still looks right even when it is wrong. 

Generic AI fails in commercial real estate in a specific way. It fails fluently. The formatting is clean, the language is professional, and somewhere in the lease abstract or the investment committee figure, the model has guessed where a trained professional would have known. Nothing in the presentation signals that something is wrong.  

Why Generic Tools Give Confident Wrong Answers 

Only 5% of commercial real estate professionals trust AI enough to inform an actual deal decision, according to the 2026 CRE Industry Pulse Check by First American Data & Analytics and DealGround. The same people use AI daily for market summaries and first-draft emails. They keep it away from the lease abstract and the investment committee figure. 

Ask Claude or ChatGPT a question about your portfolio, and it answers from its training data, not from your records. It does not know which tenants are active, which leases are rolling, or which investors passed on a similar asset last quarter. It knows what a lease looks like. It does not know what this lease means inside your business. 

Generic AI knows documents. It does not know deals. That is the gap, and the name for it is grounding. 

What Grounding Actually Means 

Grounding is connecting an AI model to your live data, so its answers come from your records rather than its general training. The technical mechanism that makes this possible is MCP (the Model Context Protocol), an open standard that lets an AI assistant reach into an outside system, query it, and act on what it finds. Without grounding, Claude or ChatGPT is reasoning from everything it has ever read. With it, the same model reasons from your pipeline, your lease data, your client history. 

The difference in output quality is not marginal. A grounded model can tell a broker which of their active tenant requirements have a target move-in inside six months. An ungrounded one can explain what a tenant requirement is. One is an analyst who has read your files. The other is a capable generalist who has never seen your business. 

This is why MCP connectors matter for CRE specifically. They are the layer that turns a general-purpose AI into something that knows your deals, your clients, and your data as it stands right now. But connecting MCP to a CRE data model is where the domain problem begins. 

Connecting MCP to CRE Data Is Not a Technical Problem 

Standing up an MCP connection to a CRM or any org is a straightforward admin task. Let’s take Salesforce as an example. Their MCP servers reached general availability in 2026, and a basic connection can be configured in under an hour. What the connection gives Claude out of the box is generic access to standard objects (Accounts, Contacts, Opportunities). It has no idea what a lease comp is, what NNN means in context, or how your firm’s custom objects relate to each other. 

Getting the model to reason correctly over CRE data requires building the layer that most vendors do not mention. That means mapping your data model so the model understands which field holds which concept, writing the field-level documentation that tells the model what each value means in practice, and defining the tools that encode the CRE-specific query patterns your brokers need. A prompt can teach Claude what NNN stands for in minutes. Teaching the system to apply NNN correctly in the context of your specific lease objects, your specific expense recovery logic, and your specific reporting requirements is a different project. 

This is where domain depth becomes the deciding factor. A team that has been building for CRE for decades starts that mapping work from a different place than a team learning the domain on your engagement. The vocabulary is already known. The edge cases are already anticipated. The data model decisions have already been stress-tested against how brokers work. 

The gap between a connected system and a useful one is built entirely from that domain knowledge. And it is a gap most vendors underestimate, because the technical connection looks finished long before the useful work is done. 

What We Learned Building It Ourselves 

Before we took any of this to a client, we built it into our own product. The AscendixRE AI Suite is the result of Ascendix going through the full deployment journey ourselves, connecting our own CRM to Claude and ChatGPT, learning where the model produced plausible but wrong answers, and redesigning the context layer until the outputs were trustworthy enough for a broker to act on. 

In the early stages, the workflow looked like what most CRE firms are doing right now: manually copying records into Claude, pasting in email threads, uploading documents, asking questions. Useful, slow, and dependent on whoever was doing the copying. That is the first version of AI in most firms, convincing enough to continue but not connected enough to scale. 

The shift to a fully connected system revealed where the real work was. Getting CRE terminology into the system was quick. Mapping our data model so the model returned answers from our records rather than its training, defining what a trustworthy output looked like for each use case, and building the human review step into every workflow before anything was saved to the CRM took sustained effort from people who knew both the technology and the domain. 

Two decisions came out of that process and have not changed. The AI works only from the firm’s own records, so every output is traceable to a source the broker can defend. Nothing saves to the CRM without a broker reviewing it first, so the human stays in the loop while trust between broker and system builds over time. 

The Data Problem Underneath 

The grounding problem is not only about the MCP connection. It is also about the state of the data the connection reaches. At most CRE firms, property records are scattered across spreadsheets, email attachments, and aging CRMs. Rent rolls arrive in inconsistent formats. Deal notes live in email threads. No single source of truth exists for the firm’s key relationships. 

A model connected to incomplete or inconsistently structured data produces incomplete and inconsistently structured answers. The MCP layer surfaces whatever is in the system. If what is in the system is fragmentary, the outputs will be too. This is the part of the grounding problem that does not get solved by better tooling. 

It gets solved by a partner who understands how CRE data actually behaves before they touch your systems. Who knows where it breaks down, where it is undocumented, and what needs to be resolved before the AI can reason over it reliably. That knowledge does not come from a discovery call or a scoping document. 

Some vendors offer a shortcut: a configurable platform where you buy the shell and build the context yourself. What that means in practice is an integration project measured in months, a data model nobody owns, and a maintenance burden landing on an internal team that has never produced a lease abstract. The domain work moves off the broker’s calendar and onto the IT backlog. 

How to Pressure-Test a Vendor’s Domain Claims 

None of this argues for waiting. It argues for changing the evaluation. Instead of asking what a tool can do, ask questions that expose whether the domain knowledge is real: 

• Read one of my rent rolls, live. Your document, your messy format, in the demo. A walkthrough on the vendor’s clean sample data proves nothing about your portfolio. 

• Where did the domain rules come from? Listen for named document types, named workflows, and people with CRE backgrounds on the team. Vague answers about industry data are the signal. 

• What happens when the tool is unsure? The right answer involves flagging for human review. Anyone claiming the tool is always right has not watched it work. 

• Can every output be traced to its source? If a broker cannot click a number and land on the page of the lease it came from, that number will not survive scrutiny. 

• Who maintains the domain logic as the industry changes? Lease structures evolve and someone has to keep the rules current. Be clear on whether that someone works for the vendor or for you. 

• What does my data model look like after go-live? If the honest answer is a months-long integration owned by your team, price that into the decision. 

 After more than two decades in this industry, my read is that the AI conversation in CRE is asking the wrong question. The question is not which model to buy. It is whether the people helping you deploy it already understand how CRE data behaves before they touch your systems. 

That understanding takes years to build. It cannot be acquired in a scoping document or a discovery call. When it exists, the grounding work gets done faster, the mapping is more accurate, and the outputs are trustworthy sooner. 

When it does not, you are paying for someone to learn your domain on your time. The AI is ready for this industry. The question is whether the people deploying it are.