Why replacing your IWMS is the wrong question

Directors of corporate real estate who ask "should we replace TRIRIGA with an AI platform" are asking the wrong question. Not because the answer is automatically no, but because the question assumes the IWMS and the AI layer are solving the same problem. They are not.

An IWMS is a database with workflows built around it. IBM Maximo Real Estate and Facilities (formerly TRIRIGA), MRI Software, and Planon are all good at storing structured data: lease payment schedules, space allocations, maintenance histories, capital project timelines. They are good at generating reports from that data, and reasonable at managing approvals and escalations through defined workflows. That is the work they were designed to do.

The work that sits alongside that database, reading a new two hundred page lease and extracting the material terms, comparing a first-quarter CAM statement to the lease's exclusions list, tracking four hundred option windows and flagging the ones that need action in the next ninety days, is not database work. It is document work and exception work. IWMS platforms handle it poorly not because of a design flaw but because it is a different category of task entirely.

What IWMS vendors have done with AI#

Every major IWMS vendor has introduced AI capabilities in the past two years. The initiatives are real and worth understanding, because they clarify what the vendor AI layer addresses and what it does not.

IBM's Maximo Application Suite integrates with IBM watsonx for analytics and copilot-style assistance. The AI assists with maintenance prediction, work order analysis, and conversational queries against the data the platform holds. It does not read external documents or process incoming landlord correspondence.

Planon has introduced AI-powered analytics and natural language queries within its platform. The features improve how users access structured data. They do not extend the platform's capability to process unstructured inputs.

ServiceNow, which operates in the adjacent ITSM space but is increasingly relevant to corporate real estate and facilities, introduced AI agent teams in its 2025 Yokohama release, preconfigured for CRM, HR, and IT functions. The real estate application is facilities workflow, not lease document processing.

The pattern is consistent: IWMS AI makes the structured data layer smarter. It improves retrieval, prediction, and analytics within the system. It does not do the document-level work that precedes data entry, reading the lease, validating the abstract, processing the CAM statement, or the correspondence work that follows decision-making.

The document layer that IWMS does not touch#

A commercial lease is a one hundred to two hundred fifty page legal document. Most IWMS deployments hold an abstract of that document: the key terms extracted into structured fields. The abstract is useful. It is also downstream of a process, abstraction, that is time-intensive, error-prone, and rarely kept current as leases are amended.

The gap between the source document and the abstract is where portfolios develop risk. A lease amendment signed three years ago may have changed the CAM exclusions, the renewal notice period, or the option exercise window. If the abstract was not updated, the IWMS holds incorrect data. Reports and alerts generated from that data are wrong, and the person relying on them does not know.

This is not a failure anyone designed. It is the operational reality of a system that requires accurate manual input at scale. For a team of five managing three hundred leases, keeping three hundred abstracts current through every amendment, renewal, and modification is not achievable at the quality level the decisions require.

An agent that reads source documents and validates them against the existing abstract changes the failure mode. Instead of hoping the abstract is current, the system confirms it, or flags the discrepancy for review. The IWMS holds the data; lease administration keeps the data accurate.

The reconciliation work that falls through#

CAM reconciliation is the annual proof point. Every year, across a large portfolio, hundreds of statements arrive from landlords. Each one needs to be compared against the lease terms for that property: the CAM pool definition, the excluded expenses, the pro-rata share structure, the gross-up provisions, the controllable expense caps.

That comparison is not a reporting function. It is a document function. The IWMS holds the abstract; the statement is a separate document. The comparison requires reading both, identifying discrepancies, and deciding which ones warrant a dispute. No IWMS workflow does that. A human does it, or, more often, does not do it because the volume exceeds the team’s capacity.

The financial consequence is direct: billing errors that go unchallenged get paid. The overcharged amount becomes next year's estimate baseline. A persistent overcharge across two hundred properties compounds over the remaining lease term into material P&L exposure. The specific mistakes to look for are in our CAM reconciliation errors checklist.

An agent that reads each statement and compares it against the abstracted lease terms does not replace the human decision on whether to dispute. It does replace the manual comparison step, which is where the time goes and where errors hide.

How the two layers work together#

The architecture that works for enterprise occupiers is not a replacement of the IWMS. It is a processing layer that operates on top of it.

The IWMS remains the system of record. It holds the structured data: payment schedules, space data, maintenance records, capital project tracking. It produces the compliance reports the accounting team needs for lease accounting under ASC 842. It manages the work order queue. It is the place where data lives.

The agent layer operates on the documents and tasks that feed the IWMS or require interaction with external parties. It reads new leases and populates or validates the abstract. It processes incoming CAM statements and surfaces discrepancies. It monitors critical dates and generates action items. It drafts responses to landlord inquiries. It flags remeasurement events that require accounting action.

Data flows up from the agent layer into the IWMS. Exceptions flow from the IWMS to the agent layer for document-level investigation. The humans on the team handle decisions, negotiations, and anything that requires judgment that context and precedent alone cannot support. This is the same division of labor examined in AI agents vs IWMS.

The evaluation question that actually matters#

For a director of corporate real estate evaluating this decision, the useful question is not "replace or keep." It is: what work is falling through in the current model, and which of those failures is a data-quality problem versus a document-processing capacity problem?

If the answer is "our IWMS data is stale and our team cannot keep abstracts current across four hundred leases," that is a processing capacity problem. An agent that reads documents and maintains the data layer addresses it. The IWMS does not go away; it becomes more accurate.

If the answer is "our IWMS is generating the reports we need but we cannot process CAM statements fast enough," that is also a processing problem, with a direct P&L cost. An agent layer addresses it.

If the answer is "our IWMS is too rigid, costs too much to configure, and does not support the way our team actually works," that might be an IWMS replacement conversation. But for most enterprise occupiers with a functioning TRIRIGA or MRI deployment, that is not the primary pain.