Run Your Own AI Maintenance Team

Alright I’ve been abstract about how AI can work with your team in a shared workspace. Now we need to nail it home with a real example of an AI maintenance team we have been running in our monday.com workspaces.

I want to walk you through a single maintenance ticket, end to end, from the moment a resident submits it on a Friday afternoon to the moment the work is complete on a Saturday morning. At every step I will name which agent picked it up, what they did, and what you, the operator, saw on your monday board.

One important thing before we start. None of this happens in a separate AI app. The agents work directly inside the monday workspace your team already uses. There is no new tab to open. No new dashboard to learn. The AI lives on the same boards your operations team has been working on for years.

OK. Friday, 4:47 PM.

A resident at one of your buildings, Sarah, opens the maintenance chat on your resident portal.

Troy picks it up.

Troy classifies the issue. Plumbing. Leaking faucet. He pulls the troubleshooting tree for that specific case. Then he asks one question at a time, conversationally. Which faucet, kitchen or bath. Single handle or two. He suggests firmly closing the handle. Then tightening the packing nut a quarter turn. She tries both. Still dripping. He has her check whether the water is coming from the faucet itself or from the pipes underneath the sink. She looks. It's the pipes. Troy escalates.

A few seconds later, a new item appears on your maintenance board. It is already classified as Plumbing, Urgent priority, with the linked unit and lease pre-filled. The work order description includes Sarah's original problem and a clean log of what she already tried. The full chat transcript is posted as the opening Update on the item.

What you saw: a fully triaged ticket showed up on your board. The resident has already been told someone is on the way. The vendor, when she's looped in, will know exactly what was tried so she does not repeat the same two steps.

What you did: nothing.

Status ticks to "Initial Dispatch (Awaiting)." That triggers Penny, our Communications agent.

She drafts a dispatch email to Mike at Acme Plumbing. Property, unit, resident contact, what Sarah reported, what Troy walked through, what she already tried. Initial Dispatch Sent. Posted as an Update on the item. The ticket is now waiting on the vendor.

What you did: nothing.

Mike replies two hours later from his phone.

His reply hits your maintenance inbox. Echo picks it up.

Echo is the inbound-email parser. She watches every reply that comes back to the maintenance mailbox, matches it to the right work order by the subject prefix on the thread, classifies the sender (vendor, resident, owner, auto-reply, or unknown), and extracts the structured pieces - dollar amount, schedule date, completion date, work-complete signal, owner intent. Then she writes them to the columns.

This particular reply is from a vendor on a ticket sitting in "Initial Dispatch (Awaiting)." Echo recognizes the pattern - vendor responding with an estimate - and pulls the amount and the date. She writes $750 to the Approved Amount column, June 13 to the Schedule Date column, and posts an update with the extraction so you can see how she read the message.

But $750 is above your client's $500 on-site reserve. That means the work cannot proceed on the vendor's say-so alone - the owner has to approve. Echo flags the next status (Estimate Approval Needed) into the Suggested Status column and creates an Approve action in your Inbox: "Apply Suggested Status: Estimate Approval Needed."

What you saw: an Inbox card waiting on a one-tap confirm. The vendor's full reply is right there. Echo's parse is right there. The proposed next step is right there.

Echo's parse: $750, June 13, she changes the workflow status to "owner approval required"

That status change is Penny's trigger again. This time Skill 05 - the owner approval email. It is the only skill in the workflow that is gated (our client wanted to review anything that goes to the owner before sending). Penny drafts it, but does not send. The draft lands on the item as an update with the full email body, addressed to the owner, with a one-line note at the bottom:

This gate exists because owner emails carry weight. Approving a $750 expense on someone else's property is the kind of move where you want a human to glance at the draft before it goes out. Even if it is one second of glance.

You reply on the Update with the single word approve. Pilot is watching.

The email goes out to the owner. The work order leaves your Inbox. No further action required by your team.

A few minutes later, the owner clicks the Approve button in their email. The webhook lands on your board, sets the Owner Approval column to Approved, and Echo posts a parse update on the item showing OWNER → APPROVE, HIGH confidence. Suggested next status: "Approved / Dispatching."

Penny sends Skill 06 to Mike: owner approved, please proceed, schedule confirmed for Saturday 11.

What you did: nothing

Saturday morning. Status ticks to "Scheduled." Mike arrives, takes a photo of the cabinet area before he touches it, and uploads it to the Pre-Work Pictures column on the item.

That upload is Iris's trigger. Iris is the photo agent. She watches the file columns and validates what gets uploaded.

Iris confirms the photo shows the right fixture, notes any condition flags worth recording, and runs a safety pass - exposed wiring, mold staining, structural concern, anything that would change the severity. If she sees a safety issue she ticks the Safety Hazard Suspected checkbox on the item and posts an update flagging it for your review. In Sarah's case there is none. She stamps the item with a "Pre-work documented" verdict and moves on.

Mike replaces the cartridge, tightens the supply-line fitting, tests under pressure for ten minutes, takes a post-work photo, and uploads it.

This is where Iris does her second job. She doesn't just look at the post-work photo on its own. She pulls the pre-work photo too, sends them both to Claude vision, and compares them. Same fixture? Yes. Was the dripping visible in the pre photo? Yes. Is it gone in the post photo? Yes. Is there any new damage that wasn't there before? No. Iris writes the verdict to a column on the item: "Work verified. Replacement cartridge installed, supply line tightened, no visible drip."

If Iris had spotted anything off - a different fixture in the post photo, new damage, the original problem still visible, the photo too blurry to tell - she would set an Action in your Inbox that says "Vendor work failed verification - re-inspect" and you would see it the next time you opened your morning queue. Quietly catching the cases where a vendor said the job was done but the photo says otherwise.

In this case the work is clean. No action needed.

Status ticks to "Complete - Awaiting Invoice." Penny sends Skill 07 - a short invoice reminder to Mike.

Mike sends the invoice. Echo parses, ticks the Invoice Available checkbox, suggests "Closed (Work + Invoice)." You tap. The Workflow Status column moves to closed.

That final status change triggers two parallel sends.

Penny fires Skill 08 - the resident closeout to Sarah:

And Iris assembles the full PDF report. Cover page. Resident block. The issue as reported. The triage classification. The pre/post verification with both photos labeled. The full chronological activity log. Footer with the timestamp. She uploads it to the Work Order Report column on the item, then emails it to the owner from your maintenance address.

The item collapses into the closed-tickets view on your board.

You open the app on Monday morning. There is nothing in your inbox about Sarah's faucet. There is a clean, complete record on your board. Your owner already has the report in their inbox.

That is one ticket. Five agents. Six outbound emails. Nine status transitions. One typed approve from you, and two tapped status confirmations.

Not much.

The whole interaction reduced to three nudges. You typed approve to release the gated email to the owner. You confirmed the Suggested Status when Echo flagged it. You confirmed it once more when the invoice came in. None of those took more than a second. None of them required you to remember any context - the item told you what to confirm and why.

The override toggle from the last post is still right there, on every step. Reject Penny's draft. Decline the suggested status. Pause Pilot. The agents work for you. You do not work for them.

I want to come back to the framing I opened with, because it's the part that matters most.

None of this happened in a separate AI tool your team had to log into. It lived in their ops workspace.

Every move you just read about - Troy on the chat, Penny on the drafts, Echo on the parses, Pilot on the sync, Iris on the photos and the final report - happened on or against the same monday board your operations team has been using for maintenance all along. The agents filled in the same columns your dispatcher uses. They posted in the same Updates panel your vendors post in. They attached to the same item your QA team would have attached to. The PDF report landed in a column right on the ticket. The owner email went out from your real maintenance address. There was no new app. No new login. No second source of truth to keep in sync with your first one.

This is the practical version of the "AI as team member" idea I wrote about in April. The new team member sits at the same desk as the rest of your team. She uses the same workspace. She just does her share of the work without being asked, and she leaves a tidy record of everything she did, in the place you would have looked for it anyway.

The walkthrough above is the system running cleanly. To get there, three real bugs surfaced during the end-to-end test the day before I wrote this. I'm putting them in the post because most posts about AI workflows skip this part, and the failure modes between agents are where these systems actually break - not in the LLM calls themselves.

All three are now fixed and the screenshots above were captured after. If you're evaluating this kind of system, the seams between agents are where things break. The agent industry papers over this. We are shipping in production and that means we hit it.

The harness is everything I just walked you through. The agents (Troy, Maxine, Penny, Echo, Pilot, Iris). The credit ledger. The monday hooks. The Gmail integration. The retry logic, the cost caps, the alerting when something goes sideways. It is built, it is running in production..

For a 1,000-door PM running roughly 300 maintenance tickets a month, every one of those tickets is some mix of drafting the resident reply, chasing the vendor for a schedule, reading the estimate, drafting the owner-approval email, eyeballing the post-work photo, writing the closeout. Call that 20 to 30 minutes of operator time per ticket on a good day. Across 300 tickets, it is the better part of a full-time coordinator's week, every week.

That is what the harness gives back. Not "AI tokens at a discount." The hours your team spends today on the choreography around the work order - the drafting, the chasing, the matching, the documenting - most of those hours stop. The few that remain are the moments that genuinely need your judgment, surfaced in the inbox waiting for a one-second confirm.

The harness is the engine. What makes it work for your business is the refinement. Your voice in Penny's drafts, not mine. The way your vendors actually write back, not the way a model expects them to. Your PMS in the loop. The skills only your team would think to ask for. The dispatch rules you've spent ten years getting right.

You can think of it like this. The harness is the truck. The refinement is the route, the loadout, and the rules you don't let anyone else drive by. Same engine for everyone. Different vehicles when we're done.

If you want to see your own actual tickets move through this, grab a time Here. We will set up a 15-minute walkthrough on a board cloned from your workspace, in simulation mode, with one of your real recent tickets as the input. You will see the same move-by-move I just described, on your data, on your boards.

From there it is two decisions, in this order.

Turn the harness on. Credit pack, hosted by us, running in your monday workspace. Within a day. This is the cheap, ongoing cost we just walked through.

Then scope the refinement. We sit down with the things only your business does, and we tune the harness to match. Penny's voice. Echo's parser. The vendor and PMS quirks that would otherwise eat the system. Scoped, transparent, ours to do.

You do not have to commit to both on the call. Most PMs start with the harness, run a hundred or two tickets through it, see exactly where the friction is, and then we scope refinement against the real friction instead of guesses.

- Rob