"AI-native" has had a big year as a term. It's gone from shorthand for products built around AI to a default piece of marketing language appearing on practically every CRE platform's homepage, regardless of what's actually built underneath. The label sounds foundational, it promises a different category of product, and it’s becoming increasingly applied to platforms that don’t come close to earning it.
What does it actually look like to be an AI-native platform, as opposed to one that says it is? The two have started to look identical in marketing copy and very different in how they're actually built. Being AI-native isn't something a vendor can declare into being; it has to show up in the data, the workflow, the way the platform learns, and how AI tools can plug in. These are the four questions we'd bring to any vendor evaluation to find out — and yes, that includes ours.
1. Structured data
Ask: Does your platform structure deal data when it comes in, or does it extract it fresh each time an AI feature runs?
What this tests: Whether the platform was designed around organized data from the start, and whether the AI continues to build on what it already knows each time a new deal comes in, rather than starting over.
Why it matters: A platform built on structured data gets smarter with every deal that passes through it, while one that extracts on demand stays generic regardless of how long you've been using it.
This question is really two questions in one.
The first is about how the platform was originally built. An AI-native platform is designed to capture structured data from the start, not convert documents on the fly each time someone runs a query. Each deal enters the system as hundreds of specific, searchable data fields, not as a PDF the platform has to interpret every time someone runs a query. Most CRE platforms started life as deal trackers in the spreadsheet era. Adding AI extraction features on top of that is useful, but it isn't the same as being built around structured data from the start.
The second is about what happens the longer you use it. Because the data is structured when it comes in, the platform isn't starting from scratch each time an analyst runs a query or a new deal arrives. Every deal that moves through adds to what the platform already knows. Screening criteria sharpen, comps get richer, and the AI gets better at anticipating what the firm is looking for simply because it has more to work with each time.
In practice, this looks like a system that captures every incoming deal email, OM, rent roll, and T12 as a structured deal record the moment it comes in. The data is extracted once and stored permanently as searchable fields, rather than re-processed on demand each time an analyst needs it.
Altrio's data extraction process recently handled over 1,500 unique deals in a single month, capturing hundreds of data fields from each one. Every deal enters the platform as structured information, immediately available for screening, underwriting, and reporting. It also becomes part of a market database the team can search across forever. That structured layer is also what makes closed-loop learning possible, because you can't compound learning across deals if the data never settled into a consistent shape.
2. Closed-loop learning
Ask: Does the platform actually get smarter the longer we use it, or will it give the same outputs regardless of how our firm works?
What this tests: Whether the platform learns from how your team operates, or just runs the same static AI outputs no matter what.
Why it matters: A platform that doesn't learn from use will be as generic on day 500 as it was on day one. The value of AI compounds over time, but only if the platform is built to learn.
AI-native means the system improves with use, learning from how deals move, what gets passed on, and what criteria the firm applies. Engagement, pass reasons, and outcomes turn into inputs for the next deal instead of artifacts buried in someone's inbox.
This is the hardest piece to retrofit, because it requires the data, the workflow, the CRM, and the AI to all be tightly connected in one record. A bolt-on AI feature can't learn from a workflow it doesn't touch. Adam Dermer's closed-loop piece makes the case in detail. The short version: closed-loop learning isn't something you can layer on after the fact, it's a consequence of how the data and workflow are designed together from the start. When a counterparty's pass reason updates their profile, when engagement signals feed targeting on the next deal, when outcomes flow back into the comp set, the platform gets sharper as a byproduct of normal work.
3. Agentic execution
Ask: Can your platform actually complete tasks in our workflow, or does it surface recommendations and leave the doing to us?
What this tests: Whether the AI is passive in that it reads, summarizes, recommends. Or is it active, meaning it takes actions on your team's behalf.
Why it matters: Passive AI gives your team more information. Agentic AI gives them back time.
Surfacing a suggestion is not the same as taking an action. AI-native platforms can do work: sign a CA, get into a data room, score an inbound teaser, push a deal to an underwriting model, draft a follow-up.
Most "AI-powered" CRE features today are passive: they read, summarize, and recommend, and then leave the actual work to the analyst. That's helpful, but it's the same kind of help Excel has been giving analysts for the last thirty years. Agentic AI is different, because the platform does the work, the analyst reviews the outcome, and time gets returned to the part of the job that actually requires judgment.
Our CRE-trained AI agent for inbound deal capture, is one example of what this looks like in CRE: it captures every inbound deal, signs CAs, gets into data rooms, and scores teasers against the firm's criteria, so the analyst spends time on what matters while the agent handles what shouldn't have required a person in the first place.
One clarification worth making explicit, because the language around agents tends to slide toward autonomy: agentic doesn't mean autonomous. The platform serves the analyst's judgment, not the other way around, and the goal is to clear the routine work so they can focus on what actually requires a person.
4. Open Source AI integration
Ask: Can our team connect their own AI tools like Claude, ChatGPT, or whatever they use, directly to your platform, or are we limited to the AI you've built in?
What this tests: Whether the platform is open to AI agents through open standards like an MCP, or walled off to the vendor's own AI features.
Why it matters: A platform that only works with its own AI limits your firm to whatever the vendor has built. Open integration means the platform was designed with AI as a first-class user, not bolted on at the end.
The last piece of the test is the one most platforms haven't begun to address. An AI-native platform is accessible to AI tools through open standards, not just through the chatbot the vendor decided to ship.
Raj Singh's, Altrio's CEO, framing in the whitepaper is the right lens here: AI agents are users, not systems. Claude, ChatGPT, and the next generation of AI tools aren't software to be integrated with, they're a new category of user, one that needs to be designed for the same way human users are. A platform designed for AI as a first-class user is built differently from one with a chat box bolted on, with intentional controls around access, permissions, and accountability.
Model Context Protocol is the open standard for this. A platform with an MCP server can be queried from Claude, ChatGPT, or any AI tool your team uses. A platform without one is a walled garden.
Altrio's MCP server launched in May for exactly this reason. Customers can connect Altrio to any MCP-compatible AI tool and query years of their proprietary deal and market data the way they'd query a colleague. Everything stays within the permissions, audit trail, and governance the platform enforces. The AI tool operates as a user, while the platform stays the system of record.
This is the piece that separates "we built an AI feature" from "we built a system AI tools can actually work with." It's also the one most vendors will skip, because it requires giving up control over how AI gets used inside the customer's workflow.
Analysts in, not analysts out
Across all four questions, one principle holds: AI-native is not the same as AI-autonomous. Structured data, closed-loop learning, agentic execution, and open integration are all scaffolding for the team to spend more time on the work that actually requires their judgment.
What Raj framed as the "shadow workforce" problem is the risk on the other side. When AI outputs live outside any system of record, the firm has built a layer of work that no one can audit, govern, or learn from. Those gains will evaporate the first time an auditor or a regulator asks where a number came from. The platform is what makes AI work institutional rather than individual, and the analyst's judgment is what makes it good.
Why this matters
The CRE platforms that win the next cycle won't be the ones that bolted AI on fastest, but the ones whose data, workflows, governance, and integration points can actually support AI as a first-class capability. That's the result of years of foundational decisions, whether or not those decisions were originally made with AI in mind.
AI-native isn't a finish line, and this checklist works best as a periodic check, not a one-time bar to clear. The closed-loop piece, the build-vs-buy piece, and Raj's whitepaper all build related arguments worth reading alongside this one.
The shortcut a lot of vendors are reaching for, which is to ship a few AI features, rename the category, and claim the label, is going to age badly in front of customers who eventually run the test. AI-native is about how a platform is built, not what it's called in the pitch deck, and anyone using the term should be willing to show their work.
.png)
