How Agentic Automation Is Changing Storage Portfolios

Software delivery has radically changed only a small number of times since computing began. Punch cards and mainframes gave way to software installed directly onto a desktop or a facility’s own file server. That gave way to the browser. The browser gave way to the cloud—software as a service, continuously updated, accessed from anywhere, with nothing to install. Each of those transitions looked, in the moment, like a technical detail: a new disc, a new login screen, and a new place to click. Each one, in hindsight, decided which vendors kept their customers into the next era and which quietly didn’t.

We’re at the start of the next one. Agentic AI—software that doesn’t just wait for a person to click through a screen but can plan and carry out a task on its own—is the next step in the change in how software gets delivered and used. It isn’t a feature update sitting on top of the way things work today. It’s the same kind of platform shift that mainframe-to-desktop and desktop-to-web already were.

If you’re a multi-facility operator or a third-party manager sitting on a facility management system decision right now, that’s the frame worth holding onto. The decision in front of you is no longer just a question of features and per-unit pricing. It’s a decision about which vendor is positioned to build the next layer of your operation on top of what they already have—and which vendor risks being left behind the way software is left behind every time the underlying platform moves.

Established software vendors with a real system of record and deep operating knowledge aren’t the casualties of this shift. They’re its most natural beneficiaries—but only if they successfully cross the chasm. History shows that only some vendors navigate a platform shift successfully, while others fail.

That’s the argument this piece makes, and it draws on a recent analysis from Cathay Capital’s private equity technology team, built from months of work with their B2B software portfolio and a week of conversations with software CEOs, hyperscalers, and AI infrastructure companies in San Francisco. Below, we retell their core argument in our own words—and then get specific about what it means for the FMS decision in front of you and where Monument already stands.

Key Takeaways

• Software Delivery Is Changing Again—and Self-Storage Isn’t Exempt: Mainframe gave way to desktop and file server, which gave way to the web, which gave way to SaaS. Agentic AI is the next step change in how software is built and used—not a feature update.
• Not Every FMS Vendor Will Make This Jump: Some genuinely dominant software failed to survive its platform’s next transition—WordPerfect never really made it to Windows. The real due-diligence question is whether your vendor has a published plan, not whether they say the word “AI.”
• The System of Record Underneath an FMS Isn’t as Uniform as It Looks: Structured data quality, portfolio-wide segmentation, and native dual-basis accounting vary enormously between vendors—and most legacy platforms have done very little deliberate work on the context layer that sits above it.
• Monument Has Been Building the Context Layer for Years, Not Months: Three-plus years of work on our Insights engine means Monument already had to define, consistently, what every key metric means across a portfolio—precisely the work an agent needs before it can act safely.
• Silence Is a Decision: A vendor without a published agentic AI plan hasn’t opted out of this shift. They’ve already chosen to let someone else build on top of them.
• Monument Is Committed to Building All Four Agent Types: Copilots, Wedges, Sentinels, and Orchestrators are all already part of Monument’s product roadmap for self-storage.
• We’re Labeling Roadmap as Roadmap: Every capability described below is marked as either shipped today or a direction we’re actively building toward—and we hold every other vendor you evaluate to that same standard.

Self-storage software built for
high-performance operators

See Monument in Action

Software delivery has gone through a handful of genuine step changes since computing began—not minor version bumps, but fundamental changes in how software was built, bought, installed, and used:

Each of those transitions looked, at the time, like a technical detail—a new way to install software, a new place to log in. Each one, in hindsight, decided which vendors kept their customers into the next era and which didn’t. What’s stayed constant across every one of those transitions is the underlying job: software still has to store a business’s data accurately, enforce its rules, and give someone a reliable way to act on it. What’s changed, every single time, is how directly a user—or now, an agent acting on a user’s behalf—can reach that system and act on it.

What is Agentic AI?

This is also where “agentic AI” needs a precise definition, because the term gets used loosely. Agentic AI is software that can autonomously plan and execute a multi-step task—not just answer a question, which is a chatbot, and not just suggest an action, which is a copilot, but actually carry the task through. In self-storage terms, it’s not a chatbot that tells a regional manager which facilities are underpriced, and not a copilot that drafts a rent-increase notice for a human to send, but an agent that reviews eligibility, drafts the notice, and moves it through the approval chain a human has set—without anyone touching a keyboard for the routine revenue management cases.

The shift from “assists” to “acts”—from a system of record to a system of action—is what actually makes this transformative. Not the word “AI” itself.

One more point worth being direct about: none of this makes an FMS’s own interface irrelevant. Someone still has to enter clean lease data, review a flagged delinquent account, and approve a batch of rent increases. The interface is what builds the habits and discipline that keep the underlying data clean enough for an agent to trust in the first place. The realistic shift isn’t from screen to no screen—it’s from a single screen as the only way in to a screen as one of several entry points, alongside the AI assistants, a team, its owners, and increasingly its tenants will reach for first.

Before getting into the architecture, it’s worth being blunt about something the architecture doesn’t answer on its own: not every vendor is going to make this jump.

That’s not a hypothetical concern. It’s a pattern with a name attached to it every time software has gone through a step change like this before. WordPerfect was the dominant word processor of the DOS era—genuinely dominant, not a close second. When Windows arrived and reset how software was supposed to work, Microsoft rebuilt Word natively for the new platform, while WordPerfect was slow to follow. By the time WordPerfect caught up, Word had already taken the category, and it never really got it back. The lesson isn’t that WordPerfect was a bad product. It’s that surviving one platform transition doesn’t guarantee surviving the next one, and the vendors who don’t make the jump rarely announce it in advance.

The question worth asking your FMS vendor isn’t whether they’ll say they have an AI strategy. It’s whether they’ll actually make the investments and shift in architecture needed to get there.

With that in mind, here’s the architecture behind the shift, and it’s the single most useful mental model for evaluating any FMS vendor’s AI story right now. The same three-layer structure shows up across most agentic AI frameworks, not just in self-storage software.

Picture a secure gateway to the outside world, called an MCP server, and behind it, three stacked layers:

• At the top an agentic layer that talks to the MCP Server, where agents plan, orchestrate, and execute;
• In the middle a context layer, which translates external requests for data into instructions for where the underlying data is stored; and
• At the bottom, the system of record as the foundation, where the underlying data itself lives;

Whatever AI agent an operator brings to the table—Claude, ChatGPT, Gemini, or a custom-built tool—it should interface exclusively with the MCP server. The MCP server then relies on the 3-layer architecture underneath to properly respond to the external AI agent.

MCP stands for Model Context Protocol, a documented, standardized way for an outside AI agent to securely connect to internal software and either query its data or, as this matures, take action within it, instead of relying on a one-off integration built and maintained separately for every AI tool a vendor wants to support. The MCP server isn’t bolted on next to the platform—it is the platform’s front door, and ideally its only one. Everything else sits behind it, out of reach from the outside.

Now let’s examine the three layers of the agentic architecture more closely.

1. The System of Record

At the bottom sits the system of record: structured data, an audit trail, and compliance. This is what an FMS already stores today—every lease, every ledger entry, every delinquency status, and every gate log.

But “the FMS already stores this” is doing a lot of quiet work in that sentence, and it’s worth pulling apart, because not every FMS stores it the same way—and the differences matter enormously once an agent, rather than a person reading a screen, is the one relying on that data.

A few honest questions worth asking about any system of record, including Monument’s:

• How well-architected is the underlying structured data? Is “delinquent” a real, timestamped, queryable field the moment a payment fails, or something reconstructed after the fact from notes and exports?
• Can you define a set of facilities—a region, a brand, a risk tier, an acquisition vintage—and take one action across that entire set? Or does every report, every rate change, and every automation rule have to be built and re-run facility by facility?
• Can the platform run cash-basis and accrual-basis accounting on the same underlying transaction at the same time natively—or does someone maintain a shadow ledger in a spreadsheet to satisfy an auditor once a quarter?
• Is a lien-processing timeline tracked as a structured, jurisdiction-aware field, or as a date someone has to remember to check against a state statute?
• Is churn sensitivity—how a specific tenant is likely to respond to a specific rent increase, based on tenure, payment history, and past response—captured as structured data at all, or does it live entirely in a regional manager’s head?

Monument’s answers to these are architectural choices, not afterthoughts. Navigator exists specifically so a portfolio segment—not a single facility—is the set an operator can report on and act on. Native accrual accounting runs alongside cash accounting on the same transaction, not as a parallel reconciliation project. Lien compliance stages are structured by state inside the platform, not tracked separately in someone’s calendar. And a lot of what most FMS platforms treat as tribal knowledge—churn sensitivity, delinquency-linkage concentration, and ECRI eligibility—is exactly the kind of thing Monument’s system of record was built to capture as structured data from day one, because a reliable KPI can’t be built on top of a note field.

These questions also highlight the gap most legacy platforms haven’t closed—not because they couldn’t, but because nobody needed a machine to read that data directly until now. A report a person reads can tolerate a little inconsistency; a person fills in the gaps without even noticing. An agent can’t. Structured data that’s ninety percent clean is unusable to an agent in exactly the situations where being wrong is expensive: a lien notice, a large ECRI batch, and an investor report.

Self-storage software built for
high-performance operators

See Monument in Action

2. The Context Layer

In the middle layers of the agentic architecture sits a context layer: who the user is, what they’re permitted to see, and what the business rules actually mean. This is the layer that turns raw data into something an agent can act on safely—and it’s the layer most FMS vendors, including some very established ones, have done the least deliberate work on.

This happens to be where Monument has spent the most deliberate effort of any part of the platform, and for longer than “agentic AI” has been a phrase anyone used. Monument’s Insights module—more than 100 business graphs that interpret raw data into actionable analytical insights, spanning operations, leasing, revenue management, and investor reporting—took more than three years to build, and building it was never really a reporting project. It was a context-layer project that happened to produce reports as a side effect. Every one of those 100+ graphs required Monument to answer a question: 

• What does this number actually mean?
• How is this calculated? 
• Whom rolled up across which segment, consistently, across every facility and every ownership structure in a portfolio? 

That’s not a data-visualization problem. That’s the definitional work—user identity, permissions, business rules, domain knowledge—that any serious agentic architecture needs underneath it, except Monument was doing it years before anyone called it a context layer. The semantic layer that now sits underneath Monument’s MCP Server, giving any connected AI assistant a consistent read on the data, isn’t a new project bolted on for AI. It’s the same context-layer work insights already required, now exposed to a different kind of user.

3. The Agentic Layer

A system of record stores what happened. A system of action determines what happens next.

Data flows up through the layers of the agentic stack: the system of record feeds the context layer, which feeds the agentic layer on top. Action flows back down: the agentic layer acts on the context layer, which acts on the system of record. It’s a closed loop, not a one-way replacement of what came before.

This 3-tiered closed loop communicates with the outside world through the MCP server, whose job is to create a secure, authenticated connection between the internal systems and an outside AI agent—in Monument’s case, between Monument and whatever AI assistant an operator connects, whether that’s Claude, ChatGPT, or Gemini. The operator’s login credential is never handed to the AI itself: Monument’s MCP server holds that credential and manages authentication on the operator’s behalf, which is what makes the connection secure in the first place. It also means the AI agent can only ever see that operator’s own portfolio data—never another customer’s, and never a shared pool of data across accounts. It’s a direct, secured line between an operator’s AI agent and their own data, and nothing more.

It’s tempting to assume every established FMS vendor already owns the bottom two layers by default, simply by virtue of having been around a while. That assumption doesn’t survive contact with how most self-storage software was actually built. A lot of legacy platforms have a system of record that’s structurally shakier than it looks from the login screen—occupancy figures that don’t reconcile cleanly across facilities, delinquency tracked partly in free-text notes, one calculation for a single-facility report and a slightly different one for a portfolio rollup. And on the context layer specifically, most FMS vendors have done very little deliberate work at all. What context they do have is almost always implicit—logic baked into a report template that one engineer understands, rather than defined once, documented, and applied consistently everywhere. Implicit context that lives in someone’s head, or in a decade-old report query, isn’t the finish line. It’s step one of what has to be a ten-step process before an agent can be trusted to act on top of it.

Owning the bottom two layers of the agentic architecture isn’t a historical inevitability that comes with tenure. It’s a body of work—and not every vendor has actually done it.

Every established software vendor now faces a choice, whether they make it consciously or not.

Path one is to leave the top layer (the “agentic layer”) open. If an FMS vendor doesn’t build its own agentic capabilities, a third-party AI overlay will build them instead—sitting between the operator and the application, capturing the user relationship, and gradually reducing the underlying FMS to invisible, swappable “headless” software that anyone can pull out from behind it. Self-storage has effectively run this experiment once already: legacy platforms that treated remote access as a login screen rather than a rebuilt operating model are exactly the ones that left room for a whole new category of centralized, hub-and-spoke operators to grow up around them. The agentic shift is a second version of the same test, on a shorter clock.

Inaction here isn’t a neutral third option, even though it can feel like one. A vendor who hasn’t published an agentic AI plan hasn’t opted out of this fork; they’ve already taken path one, whether they’ve said so out loud or not. Not having an answer is the answer.

Where is your FMS vendor’s agentic AI vision plan? If nobody at the company can point you to one, you already know which path they’re on.

Path two is to build the agentic layer directly. Four kinds of agents tend to show up wherever this happens:

The vendors that choose to build agentic layers don’t just defend their existing position. They expand what their product can be sold to do—because an agent can take on work that was previously done manually or not done at all.

Monument has chosen path two and not selectively. All four agent types above—a Copilot, a Wedge, a Sentinel, and an Orchestrator, each purpose-built for a distinct job in self-storage operations—are already part of Monument’s product roadmap. We’re not picking one flashy agent to announce and calling it an agentic strategy. Building toward all four, deliberately, is the strategy. The Copilot is real today. The other three are what Monument is actively building (not a someday idea).

Not every software vendor is equally positioned to win this fork, and the reasons come down to five accumulated assets that a new entrant — whether a startup or an operator’s own internal AI project — cannot easily replicate.

1. Proprietary data

   Years of structured occupancy, delinquency, ECRI, and lead-conversion data across a real portfolio of companies. A new entrant can build a sharper-looking interface. It cannot start anywhere but zero on the data that makes an agent’s recommendation reliable instead of generic. But “years of data” isn’t automatically a proprietary-data advantage in the sense that matters here—it only counts if it was captured and organized well enough to be useful. A decade of occupancy numbers that don’t reconcile across facilities, or delinquency history buried in free-text notes rather than structured fields, isn’t a data asset an agent can build on. It’s a data-cleanup project. An FMS that never bothered to structure churn sensitivity, lien-stage timing, or portfolio-level segmentation doesn’t actually have the proprietary-data advantage this describes, no matter how long it’s been in business. Data age isn’t the asset. Data architecture is.

2. Deep context

   Knowing which regional manager can see what, across which facility, under which state’s lien-processing rules. Without this, an operator cannot deploy agents safely at scale. This is the asset Monument has spent the most deliberate time building anything in the platform. Three-plus years went into Monument’s Insights module specifically because getting from raw facility data to 100+ reliable, consistent business insight graphs meant defining, once, what every core metric means—physical versus economic occupancy, delinquency aging buckets, ECRI effective dates, and lien compliance stages by state—and applying that definition the same way everywhere, for every customer, every time. That work is what Insights actually is, underneath the dashboards; the dashboards are the visible output of it, not the point of it. The semantic layer powering Monument’s MCP Server today is a direct extension of that same body of work, which is why any AI assistant connected to Monument data already interprets it exactly the way Monument’s own product does, rather than through a generic, best-guess reading of the numbers.

3. Domain expertise

   Self-storage isn’t generic property management. Delinquency lifecycles, lien law that varies by state, auction timing, and churn sensitivity to rent increases are specific, consequential knowledge—get the lien timeline wrong and the result is a wrongful-sale lawsuit, not a bad customer review. A generic large language model doesn’t know any of this by default. A vendor that’s spent years encoding it does.

4. Installed distribution

   An existing base of multi-facility operators and third-party managers already running their operations on top of a real system of record. That’s the same advantage a large software suite has when it ships an agentic update to its entire installed base overnight, versus a startup selling one account at a time.

5. Proven trust and compliance

   GAAP-compliant accrual accounting, audit trails, and jurisdiction-aware lien processing. When an agent is going to touch delinquency notices, lien timing, or investor-grade financials, an operator needs to know the vendor has already been through that compliance work—not that it’s improvising it on this account for the first time.

None of these five assets can be improvised by a third-party overlay or built from a blank canvas in a single product cycle. They’re accumulated—the same way Monument’s own Insights module and semantic layer were.

Some larger, institutional operators will be tempted to build a connective layer like this in-house, especially as AI development tooling gets cheaper. It’s a reasonable instinct and worth naming plainly rather than waving away: the same questions that have always dogged custom in-house software don’t disappear just because a prototype got cheaper to build. Who’s liable when the agent makes a mistake? Who maintains it as the underlying model changes? Who keeps it compliant as lien law shifts state by state? Those questions get harder, not easier, once an in-house tool touches money and legal deadlines.

Put together, these five assets are why Monument is positioned as the future-proofed choice for an FMS decision made today—not just a vendor with a promising AI roadmap slide. A vendor can announce an agentic strategy in a press release. It cannot announce three-plus years of context-layer work retroactively, and it cannot manufacture a portfolio’s worth of structured delinquency and lien data it never captured in the first place. Monument’s advantage here isn’t that we said the word “agentic” before a competitor did. It’s that the specific, unglamorous architectural work—Navigator’s portfolio segmentation, native dual-basis accounting, a semantic layer built over years rather than retrofitted in a quarter—happened to be exactly the prerequisite work this transition turns out to need. An operator choosing an FMS today isn’t just buying software for today’s job. They’re choosing which vendor already has the foundation this transition requires and which vendor is starting that foundation from zero at the same moment as everyone else.

Self-storage software built for
high-performance operators

See Monument in Action

Two broad strategies have emerged for building this top agentic layer, and they’re worth understanding in enough detail to tell which one a vendor is actually pursuing versus which one they’re just describing in a sales deck.

1. The Comprehensive Bottom-Up Approach: Unify the Data First, Then Deploy Agents Across It

A bottom-up vendor starts by connecting every siloed source of facility data—leasing, revenue, delinquency, gate access, accounting—into one platform with one consistent set of definitions. Only once that foundation exists does it start layering specialized agents on top, because every agent it builds afterward can reuse the same unified data instead of solving data integration from scratch.

Here’s what that looks like in practice. Imagine two FMS vendors, both starting to build agentic capability today. Vendor A has spent years unifying facility data into one queryable system—every occupancy figure, every delinquency status, and every ECRI eligibility flag defined once and calculated the same way across every connected facility, regardless of when that facility was acquired or which brand it operates under. When Vendor A builds a collections agent, it works the same way on facility one and facility two hundred on day one, because the data underneath it was already unified before the agent existed. Vendor B never did that integration work. Every facility in Vendor B’s system is still its own island, each with a slightly different version of what “occupied” or “delinquent” actually means. Vendor B can still ship an agent—but it will only work reliably on a single facility at a time, or it will need months of data cleanup, facility by facility, before an operator can trust it across a portfolio.

A few concrete advantages compound over time for the vendor that takes the comprehensive bottom-up approach:

• Consistency. One definition of every metric, everywhere, means an agent’s answer doesn’t drift depending on which facility, which region, or which report it’s touching. That consistency is what makes an agent trustworthy enough to act on, rather than just interesting to query.
• Compounding value. Every new agent built afterward reuses the same unified foundation instead of re-solving data integration each time. The tenth agent, a bottom-up vendor ship, is cheaper and faster to build than the first, because the hard part—the unified data layer—was already done.
• Auditability. A single, consistent audit trail across the whole portfolio matters enormously once an agent is touching lien timelines or investor-grade financials. A fragmented system of record makes that audit trail fragmented too.
• A durable moat. Whoever owns the unified, contextualized data controls the value of every agent built on top of it—a much stronger competitive position than any single agent feature, because a competitor can copy a feature far more easily than it can replicate years of data unification.

2. The Bolt-On Narrow Wedge Approach: Ship a Narrow Wedge, Expand From the Edge Inward

The alternative is to launch a narrow, low-friction agentic product that requires almost no integration to start, let it build its own proprietary data over time by observing a specific behavior, and expand its footprint deeper into an account from there.

Picture a point solution that starts as a lightweight AI assistant for a call center—it connects only to the phone system, auto-logs calls, and summarizes them for a manager. It’s genuinely useful on day one, and because it asks for almost nothing from an operator’s IT environment, adoption is fast and frictionless. That’s the real appeal of the narrow wedge: speed and a low bar to try it.

The same narrowness that makes it easy to adopt also limits what it can become:

• The data it builds is narrow by design. A call-summarization agent learns a lot about calls. It learns nothing about occupancy, delinquency, or ECRI eligibility—the data that actually drives portfolio performance—because it was never connected to that data in the first place.
• Expansion means solving the same problem the incumbent already solved, just later. If that vendor later wants to correlate call outcomes with lease conversions or delinquency risk, it needs occupancy data, ledger data, and lease terms—the same unification work a real FMS already had to do, except now from outside an account it doesn’t already run, under competitive pressure, one customer at a time.
• It can recreate the exact problem it’s supposed to solve. A narrow agentic tool bolted on next to a real FMS is, functionally, one more disconnected island—the same fragmentation self-storage operators have spent years trying to escape, just wearing a newer coat of paint.
• It hasn’t earned the same trust. A wedge product is, by definition, newer and narrower than an established system of record. When it eventually wants to touch lien notices or investor-grade financials, it’s asking for that trust for the first time, on the clock, rather than presenting a track record already built over years.

A few direct questions surface about which path a vendor is actually on:

Monument has been on the comprehensive bottom-up path from the beginning, out of necessity rather than as an AI strategy. Solving self-storage’s “islands” problem—the way legacy, per-facility software leaves every location running as its own disconnected system—was the reason Navigator and the Insights module exist in the first place, long before “agentic” was the word anyone used for it.

Put plainly: the question worth asking a vendor isn’t “do you have AI?” Every vendor will say yes to that question by the end of this year. The more useful questions are about the layers underneath.

That fourth question is worth pausing on, because it’s the one that most exposes whether a vendor actually understands its own advantage. “Who owns the automation engine” is really asking about dependency risk: the automation engine is the infrastructure that already executes triggers and actions today, and it’s the substrate any future agent will plan and act across. If that infrastructure is a bolted-on, third-party component, the FMS vendor doesn’t fully control its reliability, its roadmap, or its survival. If that third party changes its API, gets acquired, or shuts down, the vendor’s entire automation layer—and everything agentic that’s meant to sit on top of it—is exposed to a dependency it doesn’t own. A native, in-house automation engine means the vendor controls this layer end-to-end and can build an agentic layer on top of infrastructure that’s provably solid rather than borrowed.

And what should a genuinely reassuring answer to the last question actually sound like? A vendor with a real answer will say something specific, not defensive. A few examples of what that might sound like in practice:

• “We’re not worried about that, because the value was never really the login screen. It’s the years of self-storage-specific business logic—lien timing by state, ECRI churn modeling, and delinquency aging—that a generic model has never seen and would have to rebuild from scratch.”
• “A general-purpose agent could technically query anyone’s data export. But it still needs someone to define what ‘economic occupancy’ means for a specific portfolio, consistently, and that definitional work is exactly what we’ve already done and a generic model hasn’t.”
• “If anything, a capable AI agent querying our data makes our semantic layer more valuable, not less—because that layer is what makes the agent’s answer correct instead of just plausible.”

If the answer instead pivots back to talking about the interface or never mentions data, domain rules, or compliance at all, that’s the red flag.

Here’s the question worth sitting with before signing a multi-year FMS contract: if an AI agent asked a management platform for a portfolio’s true, portfolio-wide economic occupancy this afternoon, would it get a straight answer—or would it have to guess?

Some of this is already real, not aspirational. Monument’s MCP Server gives any connected AI assistant—Claude, ChatGPT, or Gemini—secure, live, read-scoped access to a portfolio’s data today, at no additional cost. Underneath that connection, a semantic layer defines what physical versus economic occupancy means, how delinquency aging buckets are calculated, when an ECRI effective date applies, and which lien compliance stage applies in which state. Because of that layer, any AI assistant querying Monument data interprets it exactly the way Monument’s own product does—not through a generic, best-guess reading of the numbers.

Worth naming directly: the architecture recommendation showing up across the industry right now is to expose a product’s capabilities through an open standard like MCP so other agents and systems can interact with it directly. That’s not a line item on Monument’s roadmap. It’s the name of a feature Monument already shipped.

What follows isn’t a hypothetical brainstorm. It’s the direction Monument’s product roadmap is actively headed in, and we’re already doing the foundational work required to get there responsibly. None of the four examples below are available in an account today—but they aren’t speculative either. They’re the direct extension of the infrastructure Monument has already built: the semantic layer, the Automation Rules engine, and the MCP Server. Turning that foundation into full agentic execution is now an active part of our product vision, not a someday idea, and it comes with real groundwork already underway: extending the semantic layer’s coverage further, defining the approval and guardrail architecture agents will operate inside, and sequencing which of the four agent types ships first. What’s ahead is a commitment we’re building toward on purpose, not a maybe.

Revenue management

Monument’s Automation Rules engine and Revenue Management pillar already model churn sensitivity and calculate ECRI eligibility across a portfolio today. Imagine a regional VP asking a connected AI assistant, in plain language, which segments in Navigator (Lease-Up Facilities, facilities in Tier-Two Cities, Facilities of Brand X, etc.) are running more than eight points below street rate and safe to push this quarter. Because the semantic layer already defines street rate, in-place rate, and churn sensitivity consistently company-wide, the assistant’s answer matches Monument’s own Insights dashboard rather than approximating it. As agentic execution matures, that same conversation moves from recommendation to action—the agent drafting and queuing the rent increases for approval, inside the same churn-ceiling guardrails the automation engine already respects.

Delinquency and collections

Monument’s delinquency lifecycle—already automated today from the first missed-payment reminder through the day-30-plus lien notice—throws off a steady stream of structured, timestamped data. Imagine a third-party manager’s regional director asking an agent to identify every facility where delinquency exposure has concentrated in a small number of accounts and to draft the owner-facing summary for this month’s review. Today, that means pulling the 3PM Dashboard and writing the memo separately. Where we’re building toward puts both in one pass, because the underlying delinquency data, KPI definitions, and white-labeled reporting format already live in the same system.

Leasing and marketing

Speed-to-lead and abandoned-cart recovery are already automated triggers inside Monument’s Automation Rules engine. Imagine an agent that continuously watches every facility’s speed-to-lead time across a Navigator-defined segment, flags any facility whose response time has drifted past the point that historically predicts lost conversions, and—with an operator’s standing approval—fires the recovery sequence itself rather than waiting for someone to notice the drift on a dashboard.

Investor and executive reporting

An executive buyer preparing for a board meeting or a refinance conversation needs a trailing-twelve-month NOI bridge for a specific ownership segment, formatted the way their investors expect. Monument’s Insights module already assembles the underlying business graphs on demand. Imagine asking a connected AI assistant to produce that exact bridge in board-ready language the night before the meeting—and getting an answer that reconciles with Monument’s own GAAP-compliant, REIT-level accrual ledger, because it was never a separate calculation to begin with.

None of this means removing a person from decisions that carry real legal exposure. Lien notices, large ECRI batches, and lease terminations—these are exactly the decision points where getting it wrong is expensive and exactly where any credible agentic capability should queue actions for human review rather than execute them unattended. The lower-stakes, higher-volume work is where full autonomy makes sense first.

That’s also why, when these capabilities do roll out, they’ll roll out the way everything else does at Monument: white-glove, with our Client Success team—not as an untested feature dropped into an account overnight. We Own The Outcome applies here too.

Self-storage software built for
high-performance operators

See Monument in Action

Is any of Monument’s agentic functionality available today, or is this all a roadmap?

Both, and we’ve tried to be specific about which is which throughout this piece. The MCP Server, the Copilot in the Agentic Layer, and the Semantic Layer are shipped today and already give any connected AI assistant read-scoped access to a portfolio’s data. The action-taking examples above (Wedge, Sentinel, Orchestrator)—an agent drafting ECRI notices, assembling owner memos, or firing recovery sequences autonomously—are part of Monument’s active product roadmap. They aren’t a feature available in an account right now, but they aren’t a distant hypothetical either.

Will agentic AI mean self-storage operators need fewer staff?

The mechanism is the same one behind Monument’s existing automation: decoupling facility count from headcount, not eliminating people. Today’s automation already lets a lean regional team run a large portfolio without adding headcount proportionally. Agentic AI extends that same operational leverage further up the value chain—into recommendations and, eventually, supervised execution—rather than replacing the judgment calls that still need a person.

Will my current FMS become obsolete because of agentic AI?

Not the system of record itself—that becomes more important, not less, because an agent that can’t see clean, structured, permissioned data can’t act safely on a portfolio. What’s at risk of becoming obsolete is a vendor that treats “AI” as a chatbot bolted onto the login screen, rather than building the context layer and agentic layer on top of the data it already holds.

Does Monument’s pricing need to change for an agentic future?

Less than most B2B software, because Monument’s pricing was never seat-based to begin with. It’s priced per self-storage unit, because that’s where self-storage revenue actually comes from—a structure that’s already closer to the outcome—and usage-based pricing the rest of the software industry is only now shifting toward.

What should an operator actually ask a vendor before signing a multi-year FMS contract right now?

Start with the questions in the tables above. In short: ask about standards-based AI connectivity, how and how thoroughly a semantic layer was actually built, who owns the automation engine that will carry out an agent’s actions, and what happens to the vendor’s business if a general-purpose agent can query a competitor’s data just as easily as theirs.

Software has changed how it reaches its users a handful of times before—mainframe to desktop, desktop to web, web to cloud—and each time, the vendors who made the jump kept their customers, and the ones who didn’t, eventually didn’t. Agentic AI is the next jump, not an exception to that pattern, and self-storage is not exempt from it. The FMS decision an operator makes this year is really a decision about who’s going to be building that next layer for their portfolio three years from now.

Monument’s answer to that question isn’t a promise about the future. It’s a description of what’s already shipped—an open, API-first architecture, a native automation engine built and maintained in-house, an Insights module built on more than three years of context-layer work and close to 100 business graphs, and a semantic layer and MCP Server that already let AI assistants interpret Monument data the way Monument’s own product does. The agentic layer described in this piece is where that foundation goes next, and it’s already part of our product roadmap, not a someday idea. We intend to build it the way we’ve made every jump so far—white-glove and honest about which parts are shipped and which parts are still ahead of us.

• Ready to see what Monument looks like for your portfolio? Book a demo today.
• Still have questions? Check out our FAQs.
• Want to see how Monument compares to other platforms? Take a look at our software comparisons.

Self-storage software built for
high-performance operators

See Monument in Action