SiZoan AI concierge and property-manager agent for Airbnb hosts

Facts on this page come from the SiZo build notes and status files dated 2026-09-22 (build status, agent status, SMS test debug, concierge host notes). The project is ongoing, so the current state may have moved on since then. There are no customer, revenue, or time-saved figures on this page because none are recorded.

Problem

Short-term rental hosts answer the same guest questions all day: check-in time, WiFi, parking, the thermostat, where to eat. Those answers live in the host’s head or in a welcome book nobody reads. The messages that actually matter (a refund ask, a lockout, a noise complaint, a bad-review threat) get buried under the routine ones.

The goal: let software answer the routine questions from facts the host has confirmed, and make sure a human handles anything that can cost money or a review.

Stack

• Property fact files. One markdown file per property. The agent may answer only from what is in the file. Unknown fields stay marked [FILL] rather than guessed.
• A Node/Express agent (v0.3) with routes for guest messages from a rental channel manager (Hospitable), SMS through Twilio, a no-login mobile turnover board for cleaners, a live activity dashboard for the owners, and a monthly owner report per unit.
• A six-step pre-arrival sequence scheduled per booking: confirmation, check-in info 48 hours out, day-of access, mid-stay check-in, checkout reminder, review ask.
• A small keyword SMS webhook that answers a handful of confirmed facts for the pilot unit and escalates everything else.
• Airtable (optional) for logging, with a setup script that creates the tables.

Steps

How it is designed to work:

1. Guest asks. A message comes in from the channel manager or by text.
2. Look it up. The agent checks the property’s fact file. If the answer is there and confirmed, it replies.
3. Escalate the rest. Refunds, review threats, lockouts, neighbor noise, and anything not in the file go to a human. The software drafts and flags; it never decides.
4. Hard rules in every file. Answer only from the file, never discuss money terms, never share owner names, and point to the welcome book instead of sending door codes or passwords.
5. Show the run. The dashboard lists every message, who answered it, and what escalated, so it is not a black box.

Real numbers

Source: the build files, 2026-09-22. Counts of what exists, not results.

• 1 short-term rental pilot unit with its own fact file. The longer-term rental units have fact files too, but that offer is paused and is not covered here.
• 6 scripted keyword replies on the pilot SMS webhook (WiFi network name, check-in, checkout, parking, thermostat, quiet hours), plus an escalation reply for anything else.
• 6 smoke tests of the webhook, all returning HTTP 200 with the expected reply (2026-09-22, about 10:45 PM ET).
• Guest messages handled in production: 0. The full agent has not been deployed and live texting is blocked (see Misfires).
• Customers, revenue, time saved: not recorded, so none are claimed.

Misfires

1. Carrier registration blocked every reply. A real test text reached Twilio, the webhook answered correctly, and Twilio sent the reply. The phone never got it: error 30034, meaning the number’s US A2P 10DLC campaign was not registered. Everything on our side worked; the carrier refused delivery. Lesson: register the messaging campaign before you build the bot.
2. The live bot was answering for a different property. The concierge that was actually running sat on another machine behind a temporary tunnel, and it still had demo data for a different unit. It gave that unit’s details, not the pilot unit’s. It could not be patched from where the new facts lived. Lesson: know exactly which machine serves your live endpoint, and keep demo data out of anything a real guest can reach.
3. Temporary tunnels as production. Both the old and new webhooks ran behind quick tunnels whose URLs change on restart. A more durable setup was staged, but the cutover waits on the carrier fix.
4. Fact files are mostly blank. Most operational fields (entry details, vendors, pet policy) are still [FILL]. That is safe, because the bot escalates instead of inventing, but it means few questions get answered automatically yet.
5. Escalations are held in memory. Pending human approvals live in memory and would be lost on a restart. A persistent store is on the fix list.
6. Two channels, one brittle path. Guest messages (channel manager) and text messages (Twilio) share code that assumes one channel’s conversation IDs. They need separate end-to-end tests before cutover.

Copy-paste template

A starting fact-file outline for one property:

# [PROPERTY NAME]
Check-in: [TIME]          Check-out: [TIME]
Parking: [WHERE]           Thermostat: [MODEL / WHERE]
Quiet hours: [AFTER TIME]  WiFi network: [NAME] (password: point to the welcome book)
Entry: [FILL]  (never send codes by text; escalate)
Local picks: [3-5 PLACES]
Escalate always: refunds, damage, lockouts, noise, review threats, anything not in this file.

Rules to give your own agent: answer only from the file, leave unknowns as [FILL] and escalate them, never send codes or passwords, never decide money, and log every message with who answered it.

What’s next

• Finish carrier (A2P 10DLC) registration, then cut the SMS number over and re-test with a real phone.
• Add a persistent escalation store.
• Fill the pilot unit’s fact file from confirmed details only.
• Run on the pilot unit and record real numbers: messages handled, share answered without a human, escalations.

Live link or demo

No public live link. The recorded demo at the top of this page shows it end to end. Screen recording of the agent running locally in mock mode with sample guests and a sample property. 39 seconds, no sound.