Building an AI Agent to Replace the Property Manager: A Field Report

There is a lot of commentary right now about AI agents "replacing jobs." Most of it is abstract. I want to do the opposite and get specific, because we have spent the last stretch actually trying to do it for one concrete role: the property manager. Not a demo, not a copilot that makes a property manager 10% faster—the whole job, at scale, at a price that changes the math for the owner.

So this is a field report. I’ll start by defining the market—what a property manager actually does and who pays for one today. Then I’ll walk through our approach, what we had to build ourselves and why, what we use models for, and finally where I think this whole slice of the labor market ends up. Fair warning: this is opinionated and written from inside the problem, not from a slide.

First, what is the market?

A property manager handles the full set of tasks an owner doesn’t want to: marketing and listing distribution, pricing, cleaning turnovers, maintenance, guest and tenant communication, and compliance. In practice it’s a coordination job. The manager is the person making sure the right pro shows up at the right property at the right time, the guest gets answered, the price is right, and the paperwork is handled.

Here’s the thing most people miss about the rental market specifically. Roughly 80% of owners don’t use a property manager at all. And generally it’s not because they love doing it—it’s the cost. A small number genuinely enjoy managing their property, but that’s rare, and even they usually only enjoy managing a small slice of it: meeting a tenant, messaging an Airbnb guest. The rest is a chore.

The other ~20% do pay for a manager, and they pay a ton—typically 20–35% of revenue for full service. (We broke down the full fee landscape in our guide to short-term rental management fees.) Our suspicion—and it’s the whole thesis—is that there’s a large unserved middle: maybe 70% of the market would happily take full property management if it were actually low cost. They self-manage today not because they want to, but because nobody has offered them full service at a price that makes sense.

Why we’re in an unusual position to do this

TIDY was founded 13 years ago, and for almost all of that time we were doing one unglamorous thing: automating cleaning and maintenance. That matters here, because the physical operations layer—getting real people to real properties reliably—is the part that has always been the hardest to scale. Vacasa, the largest at-scale vacation rental manager, raised an enormous amount of money trying to build this, went public via SPAC, and a few years later was sold in a distressed deal. That’s not a knock on the people—it’s evidence of how genuinely hard the physical-coordination part is. The cheaper "half-service" players (and Airbnb’s own co-host model, typically 10–15%) take the other route: they skip the physical operations and hand them back to the owner.

The way I’ve come to think about it: the hard questions are not fundamentally different between running an at-scale property manager and running an at-scale low-costproperty manager. Whether or not it’s "fully autonomous" is almost beside the point. What matters is that it’s both at scale and low cost at the same time. Get those two and most of the rest follows. We told the longer version of why this took over a decade in the announcement of our end-to-end AI property manager.

There are a bunch of products out there right now, some of which will even call themselves an "AI property manager." But what most of them are is a way to run an agent, or auto-assign a job to a pro, or answer a guest message. Those are useful features if you want to keep managing yourself. They don’t solve the whole stack. Demand for the whole stack is what’s high and unserved.

How we actually do it

It starts with committing to full service. After that, the operating rule is simple:

• What we can do with deterministic software, we do with software.
• What we can’t do deterministically but an LLM can, we hand to AI.
• What we can’t yet do with either, a human handles. We call this our concierge.

A few things make this work. Every owner has a knowledge base that improves over time, so the system gets more right on its own the longer it runs. And there’s an elaborate rules engine—owners can tweak essentially anything they want, because the whole positioning here is that you stay in control and the AI does the work for you, not to you. As an example of the depth involved, revenue optimization alone runs through about seven layers; one of those layers is rank-adjusted tracking, where price is tuned against where a listing actually lands in results, not just against the calendar.

The concierge: how the human layer actually works

The concierge is the most misunderstood part of a system like this, so it’s worth being concrete. It is not a call center sitting behind a chatbot. It’s a queue. When software and AI can’t fully resolve something—or shouldn’t, because the stakes or ambiguity are too high—the item is escalated into a queue that a human works.

Because we manage properties inside our own accounts, our concierge agents do that work directly in those accounts—and every action they take is captured, through a browser extension, as an audit log and history. That recorded history is an asset, not just a compliance artifact: it’s a faithful, step-by-step record of how a real expert resolved a real situation. Which is exactly the material you want when you go to automate that situation later.

What makes this more than "hire people to cover the gaps" is that the queue is the roadmap. Every item that lands in front of a human is, by definition, something the system couldn’t do yet. So the queue is a continuously ranked, real-world list of exactly what to automate next, weighted by how often it actually comes up. We’re not guessing at an automation backlog in a planning meeting; we’re reading it directly off the work humans are doing today.

That creates a one-way ratchet. A category of task starts fully human. We watch how humans resolve it, capture the decisions, and move the deterministic parts into software and the judgment parts into an AI step—usually with a human still approving at first, then spot-checking, then out of the loop for the common cases while still catching the long tail. Each task type tends to graduate from human → AI-with-review → AI → software over time. The concierge never fully disappears, because the bleeding edge always generates new edge cases—but the mix shifts relentlessly toward automation. (This is also why we think "set and forget" still needs oversight: the oversight layer is what feeds the automation.)

The surprising part: how much we had to build ourselves

A real shock of this project was how little we could buy. There are two reasons, and they compound.

1) The needs of this market are unusual. We genuinely tried not to rebuild the features of existing PMS systems. The problem was they didn’t have the knobs we needed. Take booking and discount settings across platforms. To run pricing and promotions the way we want, we need to edit those settings programmatically—and none of the APIs we researched let us do it. Length-of-stay discounts, last-minute rules, weekly and monthly factors, the platform-specific promo levers—all of it is reachable in the web UI and almost none of it through an API. Since programmatic control is core to what we do, we built our own way of driving these settings on top of the platforms, inside accounts we manage, where we have far more control.

And here’s the thing that surprised me: once you’ve done that deep integration work anyway, the case for paying a PMS to do the easyincremental stuff mostly evaporates. The hard part is getting the main integration going. Once you’re already in there managing the complicated booking settings, responding to a guest message programmatically is comparatively trivial—so why pay a PMS for it? You back into rebuilding more than you expected, not because you wanted to, but because the boundary of "what’s left to buy" keeps shrinking once you’ve crossed the hard line.

The same story repeated everywhere we looked:

• Compliance. Third-party options existed, but ran into the same issues—no API access, or the underlying laws weren’t even accessible in a usable form. We ended up building laws.sh as part of our toolset to scrape and manage the relevant laws on behalf of owners. We literally had to go do the low-level law work, which is a little wild for a property-management company. (We’ve argued for a while that compliance is more central than people think.)
• Restocking. We place a lot of orders—Walmart, Home Depot, Lowe’s, Amazon. The hard requirement is the delivery window: a turnover has a clock on it, so "sometime in the next few days" is useless. Most purchasing APIs didn’t support delivery windows, didn’t work with something like DoorDash, and were designed for large business procurement—not for getting toilet paper to a specific door before check-in and deciding, in the moment, whether Walmart or DoorDash is the better call for this order. So we built our own purchasing layer that reasons about timing, source, and cost together.

2) The economics of buying are misaligned. This is the deeper reason, and it falls straight out of our price target. We backwards-planned from pricing. Default full service is around 30%, and the very lowest at-scale full-service offerings get down to maybe 18%. That 18–35% band isn’t low enough to really change the game. So we asked: what number makes this a no-brainer—something an owner barely thinks about, the way people don’t agonize over credit-card processing fees? We landed on 3.9%.

The trouble is that 3.9% breaks the usual buy-vs-build calculus. Consider a software roll-up like Inhabit, which owns a whole portfolio of property-tech products. If you bought their full suite, you could easily be paying more than 3% of revenue on tooling alone—and that’s before pricing optimization (PriceLabs, Beyond), rank tracking, the PMS itself, a guest-messaging tool, and so on. In a 30% world there’s plenty of room for a dozen nice vendors each taking ~1% of revenue—I’m rounding, but you get the shape. Stack a few and you’re already past 3%. That’s fine if you’re charging 30%. It’s fatal at 3.9%. You simply cannot buy best-of-breed across the board when each best-of-breed wants ~1% and your entire take rate is 3.9%. The world at 30% and the world at 3.9% are just different worlds. Providers can exist in ours, but they have to be very low cost.

So when we evaluate buying something, the bar is roughly ~$1 per unit, not ~$10, and it has to do exactly what we need. The second we’re in there hacking around a tool’s limitations, the value evaporates. I’ve worked on enough of these to know that a solution requiring a ton of work on top of it usually means you end up doing all the work you would have done anyway—so you might as well build it directly and own it. We do still buy where it makes sense, and we integrate happily with the PMS and tooling ecosystem our customers already use. The build-it-ourselves list just turned out much longer than we expected.

What we use models for

Because we’re dealing with real-world, relatively high-stakes actions—replying to a vendor, making a tool call that books or cancels something, dispatching a pro—a lot of the work needs state-of-the-art intelligence. We use a good number of Opus-class models for that tier: the complicated, consequential, tool-use-heavy decisions where a confident wrong answer is expensive. For narrower jobs, including a lot of classification, we run Sonnet- or Haiku-class models. It’s a deliberate mix—route each decision to the cheapest model that can actually do it reliably, not the most capable one available.

Fine-tuning has worked well for us, and this is where it gets interesting economically. We’re currently rolling out fine-tunes of Kimi to replace some of our Opus-class usage. In our evaluations they match our general Opus-class performance on our specific tasks, and we can run them on our own infrastructure at something like a tenth of the cost. When you’re trying to deliver a whole service at 3.9%, the difference between a frontier API call and a self-hosted fine-tune on the highest-volume decisions is not a rounding error—it’s part of how the unit economics close.

The bigger point, and the one I’d push for builders: we do not think we need significantly more raw intelligence than Opus-class to finish automating this. As far as we can see, what’s left is scaffolding and work—tools, context, guardrails, evals, and yes, fine-tuning—not waiting on the next frontier model. The raw intelligence wouldn’t have been enough in the GPT-4 era; it is enough now, given the right scaffolding. And that scaffolding—the digital twins, the provider data, the rules engine, the years of operational decisions to fine-tune on—is exactly the thing you can’t shortcut, which is the whole reason this took us as long as it did. If you want the agent-facing surface of all that, see our MCP server and API.

Software vs. AI vs. humans, today

It’s genuinely hard to attribute exactly how much of the work is done by software vs. AI vs. humans, but our rough estimate today is about 60% software, 30% AI, and 10% human. Our roadmap is basically two things:

1. Look at what’s taking humans time today, and solve it.
2. Handle the long tail of edge cases that simply come with building a business at the bleeding edge.

Now that the bulk is automated, incremental gains matter a lot in the long run but less in any given week. My expectation: we’ll likely get to ~95% automation soon—in other words, the human work needed to serve a customer roughly halves over the next six months, and probably keeps halving every six months after that, with diminishing returns over time. We’re already at the point where the unit economics work at the prices we charge, because we’re deeply integrated and most of the traditional manager’s work is automated. From here I see a fairly clear path to software-like margins at our low rate within about two years. That’s the plan at a high level.

What this does to the job—and the market

I think there are reasonable people on both sides of the "will AI cause mass unemployment" question, and I’ll mostly sidestep the economy-wide version. But I can speak to this one slice with some confidence, because we’re living it.

My expectation for property management specifically: it goes from something like 50,000 high-cost boutique firms down to maybe 10–100 larger, highly automated, vertically integrated operators —mostly automated, not 100%, but serving far more properties each. At the same time the market itself grows. If that unserved 80% comes online, that alone is a big multiplier; serve consumers (not just landlords) and you add more on top. Plausibly you grow the market something like 10x—classic Jevons paradox—while cutting the labor per property by maybe 90%.

The jobs that remain reorganize around the things humans are still best at: crafting great guest experiences, working with owners so they feel comfortable and understood, and overseeing the AI—monitoring it, correcting it, developing it. So you might go from roughly a quarter-million people in the role today down to something like 50,000, generally better paid. Fewer of them, more valuable each. That’s roughly what I expect to happen here. We’ll see how it actually shakes out—but that’s the honest version of where I think this goes. For a direct comparison of the old model and the new one, see AI property manager vs. traditional property manager.

If there’s one takeaway for other builders, it’s this: the interesting question for automating a role usually isn’t "is the model smart enough yet." It’s whether you’ve done the unglamorous decade of work—the integrations nobody wants to build, the data, the scaffolding, the human queue that tells you what to automate next—that lets a merely-very-good model actually finish the job. That’s where the property manager is going. I suspect a lot of other roles are closer to it than they look.