← Back to blog
Artificial Intelligence

Getting Results with AI in CRE: Culture, Organization and Strategy

Raj Singh
Raj Singh
Co-Founder & CEO · October 23, 2026 · 8 min read
Getting Results with AI in CRE: Culture, Organization and Strategy

Key takeaways

  • A cultural change must often precede the technology change, and that it must be driven from the top
  • Firms should not allow people to delegate work to AI when they are not able to judge the quality of the result. Doing so would be akin to inverting the org chart and asking analysts to supervise associates.
  • Advantage comes from a large body of well-organized data, a governance model that ensures the quality of what goes into and comes out of these systems, and people with the right skills to direct the work and judge the results.
  • Firms need to sustain focus on the projects that are hard work and need time to succeed; the most valuable initiatives (those that are foundational or that cut across teams) are rarely the quickest to show results.

Earlier this week I had the pleasure of moderating a panel on AI at CRETech in New York. “Another AI panel”, some might say, and it would be a fair observation. However, the fact that the topic continues to fill conference agendas tells us something: misconceptions about what AI can and cannot do remain widespread, and the questions people in our industry are grappling with now go well beyond the technology roadmap. Firms are asking what AI means for how they are organized and, increasingly, for their core business strategy.

Many of the most experienced people in our field are asking a more personal question as well. Which of the things they have spent their careers learning are still relevant, and which must be rethought from the ground up?

One way to approach that question is to treat AI as simply the latest in a long line of tools. Tools have augmented human labor since someone first used a rock to crack a nut, and we have lived through many technology revolutions since. But we believe AI is different in two important ways.

It is the first tool we have created that can itself use tools, and it is the first system that makes decisions in a way that resembles how humans make them (that is, both opaque and subjective). Because of these differences, it is reasonable to expect that the impact of AI will surpass that of the PC, the internet and social media.

The panel

I was joined by Joseph Dow, Executive Director, Global Business Enablement at PGIM Real Estate, and Griffin Humphreys, Principal at Palatine Capital Partners. At Altrio, we have the privilege of working with many of the world's most respected real estate investors. All of them are using AI in some form, but PGIM Real Estate and Palatine Capital Partners stand out for the thoughtful, strategic approach they have taken and for the investments they have made in technology and processes to get the most out of it. That made Joseph and Griffin ideal guides to the questions being asked inside so many firms today: how to approach adoption, what to build and what to buy, where competitive advantage will come from when everyone has access to the same models, and how far to trust AI agents.

Culture before technology

We opened by asking each panelist to describe their firm's approach to AI adoption: the goals they have set, whether the effort is centralized or decentralized, whether they aim to move first or follow fast, and whether they think of AI primarily as a tool their people use or as a user in its own right. We also asked what AI has fundamentally changed, and what has stayed the same that is important to remember.

The clearest point of agreement was that a cultural change must often precede the technology change, and that it must be driven from the top. Software can be procured in a matter of weeks; a shared willingness to rethink how work gets done takes much longer to establish, and without it even well-chosen tools tend to sit underused.

Leadership commitment does not mean that every initiative should be designed in an ivory tower, though. Nor does it mean letting individual contributors run wild with their own experiments. The model that emerged from the discussion is a balance between the two. Experimentation at the grassroots is encouraged, and when an experiment shows promise, or starts to grow and become more impactful, it is transitioned into a formally managed, enterprise-wide initiative. This approach captures the energy and practical knowledge of the people closest to the work, while giving the initiatives that matter most the resources and governance they need to scale.

Build what is core, buy what is at the edge

Building software has become dramatically easier. With modern coding assistants and "vibe coding" harnesses, a small team can produce a working tool in days rather than months.

However, the fact that building has become easier does not mean firms can afford to build everything. The constraints are still real (people, time, the ongoing cost of maintaining what has been built, and the attention of the colleagues who must adopt it), so deciding what to build and what to buy requires as much discipline as ever, and arguably more now that the barrier to starting a project is so low.

The framework the panel arrived at distinguishes between the core and the edge. Firms should build things that are unique to them, that are foundational, or that cut across processes and teams. They should buy solutions where they need deep, specialized functionality that is not a source of competitive differentiation. The logic is simple to state, if not always to apply: the capabilities that make a firm different, or that everything else depends on, are the ones it most needs to control and shape to its own needs. Elsewhere, the depth that a specialist vendor has built up over years is rarely worth replicating.

Pacing change

Building faster has not removed the constraints on change, and the discussion surfaced two that deserve particular attention because they do not ease as building gets faster. The first is how quickly users can adapt to the changes we are now able to deliver at an ever faster rate. The second is how long it takes to be sure that we are going in the right direction.

On the first, being able to ship a new tool or workflow every few weeks does not mean that the people expected to use it can adapt at the same pace. Each change asks users to set aside familiar habits, learn new ones and build confidence in the results, and changes that arrive faster than people can absorb them tend to meet resistance rather than adoption.

When software took longer to build, the length of the build itself created time for course correction: there was room to revisit requirements, test early versions with users and catch a project heading in the wrong direction before too much had been invested in it. Today, a team can finish building something before it has realized that it chose to build the wrong thing.

Speed of delivery is no longer the binding constraint, so firms need to manage the pace of change deliberately. That means releasing changes at a rate users can absorb, and giving important decisions enough time to prove themselves before committing to them, even when the technology would allow the team to move faster.

Where advantage comes from

Every firm in the room has access to the same foundation models and the same coding harnesses, and any lead one model holds over another has tended to be short-lived. In that environment, what creates an advantage?

The answers we explored had less to do with the technology itself than with what surrounds it: a large body of well-organized data, a governance model that ensures the quality of what goes into and comes out of these systems, and people with the right skills to direct the work and judge the results. None of these can be downloaded, and each takes sustained effort to build.

How far to trust agents

Our final question asked how much the panelists trust AI agents today: what they can do autonomously, what they can do under supervision, and what they are not yet trusted to do at all.

The panel's answer came down to a combination of impact and volume. Work that is high in impact but low in volume, such as the decision to commit capital to a deal, should continue to be owned by humans. Work that is high in volume but low in impact, such as extracting data from offering memoranda or triaging inbound deal flow, can and should be a candidate for AI. The reasoning is that the cost of an occasional error is tolerable when each individual task carries little weight, and the productivity gains are greatest where the same task is repeated hundreds or thousands of times.

The discussion also brought us back to one of our opening questions, about what has stayed the same. If we think about AI agents as teammates, then we cannot forget the importance of a good org structure. Firms should not allow people to delegate work to AI when they are not able to judge the quality of the result. Doing so would be akin to inverting the org chart and asking analysts to supervise associates. The principles that have long governed how investment teams are organized, including who reviews whose work and on what basis, apply just as much when some members of the team are agents.

Focus as the common thread

If one theme ran through the entire discussion, it was the importance of focus, both in choosing which initiatives to pursue and in sustaining the effort to see them through.

First, firms need to concentrate their efforts on initiatives that create real, meaningful value, rather than becoming distracted by a large number of pet projects, none of which really moves the needle. The ease of building makes this harder rather than easier. When anyone can produce a prototype in an afternoon, the number of candidate projects grows much faster than the organization's capacity to see them through.

Second, firms need to sustain focus on the projects that are hard work and need time to succeed. The most valuable initiatives (those that are foundational or that cut across teams) are rarely the quickest to show results, and they are the most likely to be set aside when the next promising experiment comes along.

I want to thank Joseph and Griffin for their time and for sharing what they have learned. What struck me most was how much of their advice concerned the organization around the technology rather than the technology itself: the culture that has to come first, the structure that determines who can judge whose work, and the discipline to choose a few important things and see them through.