How CRE firms can build a capability spine, one workflow at a time
Last week I argued that the capability spine is the company.
By that I meant the combination of context, instructions, Skills, connections, workflows, evaluations, decision history and relationship memory through which a company gets work done and improves how it does it.
Easy to say.
But how does a CRE company actually build one?
First though, a question worth asking ourselves: how much genuinely distinctive capability does the average CRE company possess?
Because if the answer is “very little”, the implications are rather more serious than simply deciding whether to buy or build some new AI tools.
THE SHORT VERSION
A CRE company does not need a vast new technology platform before it can begin assembling its capability spine.
It can begin with one useful workflow. Write down how the work should be done. Connect the systems and documents it needs. Add the minimum context required to interpret and verify the evidence. Test it properly. Deploy it within clear decision boundaries. Record what happens.
That produces a Skill.
Build more Skills, allow them to share trusted context and feed the evidence from completed work back into them, and a capability spine starts to form.
This can happen now.
The harder question is deciding which capabilities are worth owning when PropTech vendors will increasingly offer pre-built versions of the same workflows.
A CRE company should buy capabilities that are becoming generic, while retaining control of the methods, evidence and learning through which it could genuinely become better than its competitors.
CLAUDEFORCE AND THE DISAPPEARING INTERFACE
The Claudeforce announcement on 26 August gives us an early view of how this architecture may work.
Salesforce and Anthropic (developers of Claude) are bringing Salesforce data, workflows, permissions and business rules into Claude. The first product, currently available to selected pilot customers with an open beta planned for September 2026, is a plugin containing 37 pre-built sales Skills.
These cover activities such as pipeline reviews, stakeholder mapping, account planning, call preparation and win-loss analysis.
The user can ask Claude what needs attention, request an account plan or investigate a struggling deal. Claude reaches into Salesforce, Slack, and other connected sources, then acts within the permissions and business rules already established by Salesforce.
Salesforce calls the architecture behind this AIForce. Its data, applications, workflows and governance are exposed as capabilities that an AI can call directly through MCP, the Model Context Protocol. The plugin bridges the probabilistic model (Claude) with the deterministic business logic (Salesforce), and inherits the existing role-based access control.
The user no longer has to navigate the traditional Salesforce interface. It becomes a governed utility.
This has prompted a good deal of commentary that Salesforce has effectively surrendered the user interface to Claude.
In the short term, this looks like astute defensive work. If users increasingly want to operate through an AI, Salesforce needs to make sure its data, workflows and business rules remain essential wherever that AI happens to sit.
Over time, though, one can imagine Salesforce becoming less visible: an extraordinarily valuable data, rules and permissions utility operating behind somebody else’s interface.
That does not necessarily make Salesforce weaker. Infrastructure can be both invisible and extremely powerful. But it does change where the relationship with the user sits and which part of the technology stack appears to be doing the work.
There is a second tension.
Claudeforce provides the infrastructure through which companies could assemble their own capabilities. Salesforce and Anthropic have also done the assembly for them by supplying 37 Skills out of the box.
The window is opening and closing at the same time.
It has become much easier for a company to make its own methods executable. It has also become much easier for vendors to turn common methods into products available to every customer.
Pipeline reviews and account planning may once have felt like company capabilities. They have now become entries in a vendor’s Skill library.
CRE should assume the same thing is coming.
HAVE CRE COMPANIES GOT ANYTHING DECISIVE?
Property companies often talk about their proprietary processes, investment discipline and unique ability to spot value. How different are they really?
Most companies screen acquisitions, select comparables, construct cash flows, review leases, monitor covenants, prepare asset plans and report to investors. The templates vary. The approval thresholds vary. The language and presentation certainly vary. Much of the underlying work is remarkably similar.
Specialist PropTech vendors are already productising important parts of real-assets investment and asset management, connecting fragmented systems and information to support acquisitions, portfolio analysis, reporting and decision-making. A capable vendor may build many of these workflows faster and better than an individual CRE company could.
So why build anything internally? There are two possible answers.
The first is that CRE companies possess rather less proprietary capability than they believe. As vendors absorb more of the analysis and workflow, a larger share of the value will accrue to those vendors. The real-estate company may still possess capital, assets, licences, relationships, local execution capability and access to transactions. Those remain significant sources of advantage. But claims of superior analytical or operating capability will become harder to sustain when every competitor is using much the same system.
The second answer is that companies need to create more differentiation.
Building an internal version of a generic workflow will not achieve that. If two firms encode the same method, use the same models and draw on the same market data, both have merely constructed their own commodity.
The opportunity lies in making the company’s judgement explicit, testing whether it is actually any good and connecting decisions to outcomes so the method improves. The starting Skill may not be distinctive. The learning loop around it could become so.
A company with no distinctive method cannot manufacture one by writing a Skill. But a company that never makes its method explicit may soon be unable to tell whether it has one.
WHAT IS A SKILL?
A Skill is a reusable, version-controlled description of how a particular piece of work should be performed.
It goes well beyond a prompt.
Depending on the workflow, it might define:
The objective and required output
The sequence of analysis
The data and documents to retrieve
The tools and systems it is authorised to use
The company’s definitions, assumptions and methodology
The tests and validation rules to apply
Permissions and approval boundaries
Circumstances requiring human escalation
Examples of good and unacceptable work
The evaluations used to measure performance
Take lease analysis. “Summarise this lease” is a prompt.
A lease-analysis Skill defines which clauses to extract, how the company describes them, which calculations to perform, how side letters and deeds of variation should be handled, what must reconcile with the rent roll and which inconsistencies require human review.
The Skill contains the method, not merely the request.
Related Skills could cover lease abstraction, rent-roll reconciliation, covenant checking, break-option analysis, comparable selection, asset-plan preparation and investment-committee reporting.
They could sit inside a plugin that provides controlled access to the documents, databases and tools required to do the work.
This is a very different form of internal development from the one most CRE companies remember. No eighteen-month roadmap. No attempt to replace every existing system. No vast requirements document followed by an application that is obsolete by the time it arrives. The company is encoding a method, connecting existing components and controlling how the work is performed.
THE TWENTIETH-FLOOR PROBLEM
A common argument says that using AI without first fixing the data foundation is like trying to build the twentieth floor of a building before constructing the nineteen floors below it. It is a neat metaphor. It is also increasingly unhelpful.
Of course a company needs trusted data, permissions, definitions and systems. An AI cannot reliably analyse a lease it cannot access, reconcile records that use incompatible identifiers or determine which of three conflicting figures is authoritative. But it does not follow that the entire enterprise foundation must be completed before anything useful can happen.
Build vertically.
Choose one worthwhile workflow. Give it the minimum complete foundation it needs: the relevant documents, identifiers, permissions, definitions, connections, evidence rules and evaluations.
The first working Skill creates value and lays a small piece of foundation. The next Skill reuses some of that foundation and extends it. This is slower than magic and dramatically faster than waiting for a perfect enterprise data architecture that may never arrive. You do need foundations. You can build them through the work.
THE MISSING LAYER IS CONTEXT AND EVIDENCE
Access to data is not enough.
A system might find a property called Riverside House, a tenant called Acme Ltd, a figure of £750,000 and a date of 14 March 2028.
What do those facts mean?
Does Acme occupy the entire building or one unit? Is £750,000 the passing rent, estimated rental value or annual service charge? Is 14 March 2028 a break, expiry or rent-review date? Did the information come from an executed lease, an old valuation report or somebody’s assumption?
The Skill needs a shared vocabulary and an evidence standard. It must know what an asset, unit, lease and counterparty are; where each fact came from; when it was true; whether it has been superseded; and which source takes precedence when records conflict.
That context might be held in a relational schema, structured files, an ontology, a validation layer or a knowledge graph. The technology is an implementation choice.
Knowledge graphs become particularly useful when the relationship is central to the question. Which assets are exposed to tenants owned by the same parent company? Which funds, loans and covenants are affected by a particular lease event? Which deed supersedes which provision in the original lease? How does one counterparty connect to multiple properties and obligations?
For a Skill dealing with those questions, a small task-specific or “baby” graph might be exactly the right answer. It only needs to model the entities, relationships and verification requirements relevant to that workflow. Other Skills will not need one at all. The architecture should fit the work.
HOW TO BUILD THE FIRST SKILL
1. Start with a decision or outcome
Do not begin with “we need an AI strategy”. Choose one piece of recurring work where quality matters and where the company can recognise a good result.
Lease-event verification for one portfolio might work. So might acquisition screening within one sector, covenant monitoring for one fund or quarterly investor reporting.
Avoid starting with the most complicated workflow in the business. Equally, avoid a trivial use case whose success would make no difference. The first Skill should be small enough to build and test quickly, but important enough for people to care whether it works.
2. Make the method explicit
Ask the people who currently perform the work:
What are you trying to establish? Which sources do you trust? What calculations do you perform? Which assumptions are allowed? What makes you suspicious? When do you escalate? What does a good output contain?
This may be uncomfortable. The company may discover that the method is not written down, varies between teams or relies heavily on individual habit. There may be four definitions of what should have been one common term.
That discovery is part of the value. You cannot make a method executable until you know what it is.
3. Connect only what the Skill needs
The Skill may need documents from SharePoint, records from Yardi, a rent roll from Excel, market data from an external provider and approval rights held in another system. Connect those sources. Do not begin by migrating every record into a new master platform. Existing applications can remain systems of record. APIs, connectors and MCP servers increasingly allow the Skill to retrieve or act on information where it already sits.
Permissions should travel with the connection. A Skill should see only what the user is authorised to see and take only the actions it has been authorised to take.
4. Add the minimum context required for trust
Define the relevant entities, relationships, terminology, source hierarchy, dates and validation rules. For a simple workflow, structured documents and a clear schema may be enough. For a relationship-heavy workflow, build a small graph. The objective is not to model the company. It is to prevent the Skill from guessing about the part of the company relevant to the work.
5. Evaluate it properly
A Skill is not a company capability because it worked impressively in a demonstration. It needs to be tested against representative work for which the correct answers are already known.
A lease Skill should be evaluated on ordinary leases, difficult leases, side letters, deeds of variation, inconsistent rent rolls and the jurisdictions in which it will operate. The evaluation must test extraction, calculation, reconciliation, source selection and escalation, and be performed by the people who own the work, not external consultants.
Failures need to be classified. Did the model misread the document? Did the Skill contain a poor instruction? Was the source data wrong? Did the validation rule fail? Was the task outside the authorised boundary?
Changes to the Skill, model, connected system or underlying data should trigger re-evaluation. Without verification there is no automation.
6. Give it bounded decision rights
The first version should probably assist a human rather than act independently. As its performance becomes better understood, its authority can expand. It might move from extracting evidence, to recommending an action, to executing a routine action subject to defined conditions. The boundary should depend on evidence, consequence and reversibility.
A wrong internal draft is irritating. A wrong valuation assumption, lease notice or external communication can be expensive.
7. Record what happened
The Skill produces an immediate output. The company should also record the decision, important assumptions, evidence used, human changes and eventual outcome.
Did the tenant renew? Was the acquisition thesis right? Did the comparable prove representative? Did the proposed capital expenditure generate the expected improvement?
That evidence becomes the capability-spine update. It changes the instructions, evaluations, source weightings, escalation rules or decision boundaries applied next time. This is the point at which repeated work begins to compound into institutional capability.
In CRE though, the feedback loop between an underwriting thesis and the final outcome (e.g. 5-year lease renewal, exit yield, refurbishment ROI) is notoriously long and noisy. So design learning loops that not only track multi-year macro outcomes, but also short-cycle proxy outcomes (e.g. IC question friction, broker response rates, tenant concession delta, audit reconciliation speed).
FROM ONE SKILL TO A CAPABILITY SPINE
One useful Skill is still only one useful Skill. The spine emerges as Skills begin to share common infrastructure:
Canonical identifiers for assets, funds, leases, units and counterparties
Agreed definitions of important business terms
Permission and access controls
Provenance and evidence standards
Effective dates and version histories
Interfaces through which Skills exchange validated information
Decision records and outcome histories
Evaluations and governance
This common core might be quite small but putting it together can be difficult. Master data, definitions and permissions are hard. The difference lies in sequencing. Each deployed Skill extends the shared core. It does not route around it, and the company does not wait for the entire core to be completed before deploying the first Skill.
Someone needs authority over this architecture. Otherwise each team will create its own identifiers, definitions and local version of the truth. That is the System Architect role I described last week: part domain expert, part technologist, able to translate how the company works into executable and testable systems while maintaining coherence across them. This is an emerging translation role in our industry, but one we need to acquire.
BUILD, BUY OR CONNECT?
Most CRE companies should continue buying most of their technology. They should buy generic software that every comparable company needs. They should connect to authoritative systems of record and specialist external data. They should use vendors with deeper technical capability where those vendors can build and operate the workflow better.
The decision becomes harder where the workflow touches the company’s competitive position.
A useful test is:
Buy where the method is broadly common and the vendor can perform it better or more cheaply.
Connect where somebody else owns the authoritative system, data or specialist component.
Build and own where the Skill captures judgement, evidence or learning that materially affects how the company competes.
Then ask:
How long is this likely to remain distinctive? The boundary will move. Today’s proprietary workflow may become next year’s pre-built Skill. Nor does “build” necessarily mean employing an internal software team. A PropTech company or specialist developer could build the Skill with you.
The important questions concern ownership and control. Can the company inspect and change the method? Does it own the evaluation set? Can it export its instructions, decision history and outcome data? Can it change models or providers? Is the vendor improving a capability belonging to the client, or using the client’s work to improve a product sold across the market?
Who writes the code is a secondary question. Who accumulates the learning is not.
THE ORGANISATIONAL IMPLICATION
None of this requires a five-person team to sit permanently around every workflow. Think of the requirements as hats, not headcount.
The first Skill might involve one CRE professional who owns the outcome, one crossover person able to turn the method into a working system, and a sponsor with enough authority to unlock access and approve the boundaries.
Data, integration, security, risk and legal expertise can be brought in where needed. The domain expert remains responsible for what good work looks like. The system builder makes that method executable and measurable. The sponsor prevents the experiment from dying somewhere between IT, compliance and a committee.
As the capability becomes more consequential, the governance around it should become stronger.
THE COMPANY AFTER APPLICATIONS
The emerging model is organised around the work, not the software. When the interface disappears into the agent, the company’s only remaining tech asset is the fidelity of its instructions and the integrity of its feedback loop.
The AI environment is where the user expresses the intent. Skills encode how the company performs the task. Plugins and protocols connect the required systems. Schemas, rules and selective knowledge graphs provide context and verification. Existing applications continue to supply records, transactions and specialist components.
Some vendors will adapt successfully, as Salesforce is attempting to do. They may become extremely valuable infrastructure operating behind the AI interface.
Others will build complete Skills and workflows for CRE customers. In many cases, buying those capabilities will be entirely sensible. But every CRE company will need to understand what remains inside the firm when the vendor provides the method, performs the analysis and learns from the results.
Capital, assets, relationships and execution capability may be sufficient.
Claims of superior judgement will need stronger evidence.
START NOW
A company does not need to wait for years of data remediation before beginning.
Choose one recurring task small enough to complete in a morning. Map the inputs, method, evidence, decision boundaries, good and bad outputs, live-system connections and success criteria.
Build the smallest complete version.
Test it against real work.
Record what goes wrong.
Improve it.
Then decide whether the capability is generic enough to buy, important enough to own, or dependent on a vendor whose incentives and rights need to be understood.
The first Skill will probably be copied.
The outcome-labelled history of how the company improves it will be much harder to copy.
Last week I said the capability spine is the company. This is how one begins:
One workflow. An explicit method. Connected evidence. Proper evaluation. A recorded outcome.
Then again.
————————————
This is part four in a series.
The PropTech Paradox: AI is opening a much larger market, and making the resulting value harder to capture.
Human Judgement has a Timestamp: which judgement, doing what, verified how, and as of when?
The Company After the Pyramid: what a future CRE company needs to look like.
The Capability Spine: How to Build One: How CRE firms can build a capability spine, one workflow at a time