Clara as a coworker, by text

Leasing agent first. Clara gets stuck, texts one person, gets a plain answer back, and replies to the prospect herself.

Built and proven at the Willows on 2026-09-22. Not turned on for any customer. 2026-09-22. New page because the Camellia-era coworker hub is a release record of what shipped; this is the reviewable plan, and it grows into tonight's walkthrough with mocks.

Why, in Fede's words

Jason's worry is the reason this is not an email: "if Clara is just trying to ask for help on the leasing email, I'm afraid it's gonna get drowned." The shared inbox is a noisy catch-all. One named person on one phone is not.

The two loops

What Kat sees

Her whole product is her text thread. No login, no app, no buttons. Prospect names below are invented.

Mock A is Loop A. Mock B is Loop B. Both arrive from the property line Clara already uses, so Kat only ever has one Clara number.

What the website shows

The same conversation, with the human turn shown in line with Clara's. Nothing new is claimed here; it is the turns we already record, put on one thread.

This was the sketch. Tonight's section has the real page, built and screenshotted.

Assumptions to confirm

Each one has a default. Strike any you disagree with and we build the rest.

• One named person per company takes leasing asks. At Western Slope that is Kat.
• The text comes from Clara's existing property line, not a new number.decided 09-22
• Kat answers in plain words. Clara does the interpreting. No keywords, no codes.
• Kat's number never reaches the prospect. Clara always answers the prospect herself.
• The guest card is assigned to Kat when Clara asks, and back to Clara when Kat answers.later, long-term vision
• One nudge at 2 hours, then fall back to the leasing email. No reminder ladder: Camellia's was turned off because it was noise.
• The post-tour ask fires at tour start plus 90 minutes.
• The note reads "Kat (via Clara): …" because AppFolio notes carry no author field.later, long-term vision
• Tonight's proof uses a bench phone we own as "Kat" — never anyone's personal cell.decided 09-22
• Nothing turns on at a customer until Fede says so.

What we reuse vs build

Do not build

• No approve-and-send queue. One already exists at /review and it is the exact shape the 08-14 rule forbids. We name it so it stops being invisible; we do not extend it.
• No promise-ledger nagging. Fede: "i dont want the continued nagging with temporal."
• No second record type and no parallel notification path. The existing ask record gets a text leg; nothing gets cloned.

What actually happened tonight (Willows)

Everything below is a real text message between four numbers we own, sent through Clara's own line at the Willows. Kat is a bench phone we bought, never anyone's personal cell. The prospects are bench phones too. Nothing touched a customer.

Four loops ran end to end: Clara stuck → asks → answers; the same question a second time, answered from memory; the after-tour ask; and the two things Kat can start herself. Message ids and the full run log are at the bottom.

Loop A — Clara is stuck

Kat's number never reached the prospect. The answer came back in Clara's voice, on the prospect's own thread.

She only asks once

The moment Kat answered, the answer became the property's own knowledge, through the same path that already captures staff answers today:

A second prospect asked the same question a minute later. Clara answered from that entry and texted Kat nothing — checked against Twilio itself, not against the script's own counter.

Loop B — after the tour

Those notes were saved against the tour on our side. Writing them onto the AppFolio card was deliberately left out tonight, per the ruling below — the run logs exactly what it would have written.

Loop C — the two things Kat starts herself

This is the offshore-assistant job: the calendar and the follow-ups. Kat types like a person, and Clara works out the rest from the clock and Kat's own calendar.

Kat never named a tour when she said she was running late. Clara picked the next one on the calendar and said out loud which one she assumed, so a wrong guess is one word away from being corrected. The times she offered for the reschedule came from the same calendar we use to offer prospects tour times — open slots only, never invented. If that calendar cannot be read, she says so in one line instead of guessing.

The wall-clock time for this loop was set to the middle of a work day; the run itself happened at 10:07 PM. The tours, the calendar read and the open slots are real.

And on the website

This is the app, not a drawing of it. Same conversation page the team already uses, running against the data this proof wrote. Every step of the hand-off is a row on the prospect's own thread, so "what happened after Clara got stuck" is readable by someone who was never on the text thread.

Screenshots taken headlessly against the app running locally on the proof branch, with each card's details opened. The rows are six new message types, added to the existing list — nothing else about the page changed.

Flaws and gaps this found

• Production answers Kat as if she were a prospect. Her texts really do land on the live line, and tonight production replied to her with "6-month leases don't cost extra here" — wrong, and aimed at the wrong kind of person. The staff-text door exists now in the code, but nothing on the live inbound path opens it yet.
• The ask does not name the home. Clara's text to Kat gave the question and the caller's number but not the unit. Kat had to know which 2BR. That is one line of the message.
• It gives Kat the prospect's phone number. Fine for staff, but it is a decision nobody made on purpose.
• "I'll remember that" reaches Kat by email, not by text. The confirm-back leg is still email-only, so on a text-only loop she never hears it.
• Two open questions to the same person collide. A text carries no reference to what it answers, so Clara matches the newest open question for that phone at that property. One at a time is fine; two is a guess.
• The review-before-send gate only understands email. A held ask would try to hold an email that was never composed.
• Intent is read by rule, not by judgment. Tonight "running late" and "need to move" were matched by their words. Production should read them the way the maintenance reply-by-text already does.
• The second prospect's thread is nearly empty. The texts in run 2 and in the reschedule went out through the proof script's own send, which does not write to the thread the way the product's send path does. Real code would leave the whole exchange there.
• Fairhaven could not take part. Its line is voice-only — inbound texts are switched off on it. It needs texting turned on before it can run this, and that is a third-party config change nobody has approved.

What production-ready would take

1. Open the staff-text door on the live inbound path, so a recognised staff phone reaches the open question instead of the prospect handler.
2. Put the home, the person and the reason in the ask, and keep the prospect's number out of it.
3. Move the "I'll remember that" confirm onto whichever channel the ask used.
4. Read Kat's intent with the same classifier the maintenance reply-by-text already uses, and write the tour note and the card move through the AppFolio path.
5. Six new message types carry these rows (coworker_ask_staff, coworker_staff_reply, coworker_relay_to_person, coworker_knowledge_saved, coworker_tour_notes, coworker_schedule_change). They were added to the existing list, change nothing already there, and never send anything — they record a text that already went out. They stay.
6. One company setting, default off, per property on the property page, and the nudge at two hours falling back to the leasing email.

Practice rounds: how sharp is the ask?

Before this ships we ran the "should Clara ask Kat?" decision against every real prospect message we have — 4,875 turns from Western Slope (2,079), Situs Group (2,460) and Camellia (336). Each one was replayed inside the thread it actually arrived in, with the earlier messages from the prospect and from the real leasing team, and with the property and company knowledge that is on file in production today. A stratified sample of 1,657 turns was graded; every rate below is weighted back to the whole set. This was a measurement, not a fix: nothing was changed to make the numbers look better.

Of the 299 asks she did make, 109 — more than a third — were on homes where there is no knowledge on file at all. An empty knowledge base is the single biggest driver of noise.

Top five tune-ups, ranked by how many messages each one moves

Six real examples

Names, numbers and exact dollar amounts are replaced. Asks that were noise:

Asks she should have made and did not:

Does an answer actually stick?

We replayed 150 escalations with a staff answer attached — 74 of them the real answer the real team gave in that thread. Sixteen were genuine policy questions worth remembering; the other 134 were about one person and correctly were not stored. Thirteen of the sixteen were answered, remembered, and stopped escalating on the re-run. So the learning flywheel catches roughly one escalation in ten, which is what you would want — but two holes showed up: nothing checks that what gets stored is actually an answer (one case filed a personal apology as property policy), and nothing marks an answer as seasonal (a "swamp coolers start later this week" reply was filed as standing policy).

What the real humans did

Reading 4,539 messages across 1,034 real conversations at Western Slope and Situs: 94% of prospects got a human reply, median 19 minutes, 81% same day — but the person had to chase 378 times. A real question is almost never ignored; only 36 of the 269 unanswered threads contained one. Co-signers get a condition, never a no (26 out of 26). Pets and short leases are priced, not debated — "the month-to-month fee will be $150 on top of your recurring fees." Nobody negotiates rent. Voucher answers flip by property, which is exactly why they have to live in each home's knowledge. The only thing a human genuinely chewed on was eviction and credit: median 13.3 hours to reply, forty times slower than everything else — that is the shape of the small subset Clara should hand over.

Twelve knowledge entries were drafted out of those replies, and one conflict surfaced that the client has to settle: one thread says there is no application fee, another quotes $50 per applicant.

Western Slope and Situs inbound email is not captured anywhere — their turns above come from the AppFolio messaging panel, which only holds texts. Camellia's 291 email turns come from our own records. The grader was checked with a planted case: an obvious escalation labelled "she can answer this" came back as an ask, and an obvious tour-time question came back as an answer.

Run it again: npm run escalation:bar on branch harness/escalation-decision-bar. Full results, the confusion table and 60 examples are in the branch at evals/replay-harness/escalation-bar/results/.

Direct emails: examples and the order we turn them on

On the 22nd Jason Fish asked a plain question: if someone emails the Western Slope leasing inbox saying they are interested in a home, does Clara find it, make the guest card, and answer? Fede said yes. Today that inbox only handles tour messages, so the rest of it is not on. We read every message in it from January 1 to September 22 — 10,887 — and found 59 people writing in about a home in their own words: about six a month, against roughly 150 leads a month relayed in from Zillow. Camellia looks the same from the other side — of its 95 email threads, 94 started as a listing‑site forward and one was a person writing in. Nothing was sent, moved or marked read.

We tested Clara on those real past emails — 57 of them still had a readable body — and graded every draft against the same bar we use for guest‑card replies. The point of this section is the order: which of these we can turn on now, and which needs a change first.

The five shapes

Groups C and D are really one problem seen twice: 17 of the 57 emails arrive with no home attached. Two of the 59 had nothing left to read and were not replayed.

Group A — asking to tour a named home

Group B — a question about a named home

Groups C and D — no home attached

The pattern across C and D is one thing said many ways: with no home, she has company policy and nothing else, so she either says what she is missing or pushes it to a person. Neither is what a leasing agent would do.

Tours first — and what one change bought

Group A is the class to turn on first, because it is the one the inbox already handles and the one that fails for a single, fixable reason. We tested exactly that: match the address in the subject line to the company's own property list, tell Clara what we found, and change nothing else. Same emails, same rules, same bar.

The wrong‑address failure is gone. The eight that still fail are not about the home: four are a tour time the test could not actually book, because this test runs her reasoning without a live calendar, and four name a home that is no longer on the company's property list at all, so there are simply no facts to give.

The order

1. Now: tour requests with a named home. The inbox already allows them. Add the home match, prove it at our test property, then turn it on for one customer.
2. Next: the no‑home conversation — groups C and D, separately, after tours are proven.
3. Later: questions about a named home (group B), which is mostly a length and tone problem once the home is known.

The no-home conversation, the way the phone line does it

On the phone Clara does not guess which home someone means — she asks, pins it down, and then answers. Email should work the same way. As a separate change, after tours:

1. Ask one short question. "Were you looking at a specific home, or an area?" Nothing else, no policy wall.
2. Lock the home from their answer, and write it onto their record so the rest of the thread has it.
3. Answer what they asked — now with that home's facts, not just company policy.
4. Then offer a tour.

Direct emails use the same coworker loop as everything else on this page: when one asks something Clara cannot answer from what is written down — a missing policy, an exception, a red flag — she texts the leasing agent the same short ask, relays the answer back, and saves the fact so she never has to ask twice. There is no separate path for email. The practice rounds above should grade these emails too, so the sharpness of the ask is measured on this channel and not just on guest cards.

Same rules for every client, and the card writing we already have

None of this is Western Slope‑specific. The home match reads whatever property list the company has on file, so Situs Group gets the identical behaviour the day their mailbox is connected.

The AppFolio side — making the guest card, assigning it to Clara, putting a note on it, logging that an email went out — is not new work. It is the same guest‑card writer the rest of Clara already uses; a direct email is just another way a prospect arrives. Creating a card is already one of its jobs, so nothing is missing there. The one thing it needs from us is the home, because AppFolio will not accept a card that is not attached to a property.

We prove it at the Willows, our test property, with the guest‑card test we already run there:

1. Send a test email asking to tour a named Willows home; confirm it matches to that home and not to the office.
2. Confirm a guest card is created on that home, and assigned to Clara.
3. Confirm the reply goes out, and that the card shows the email was sent.
4. Read the card back from AppFolio and check all of it landed — the same read‑back step the existing test already does.

Worth fixing, not urgent — six emails a month. The reason to fix it is the shape of the failure, not the count: a prospect sent to the wrong address is worse than a prospect who waits for Bev.

Plan

Tonight. A local proof of the loop, no pull requests, quick iterations. Then this page grows into the walkthrough: real texts and real card screenshots pasted in.

After your feedback. Roughly six small changes, one concern each, all dark: the text ask leg; the reply-to-ask matcher; automatic card assignment; the per-company staff map; the real reason on the note; and the tour-happened signal with a note author. Proven at the Willows and at Fairhaven. Then a company setting you flip.

Two Fairhaven facts before tonight. Its line is voice-only, so it cannot receive a text yet. And it has no staff person on it at all, so one has to be created.

Willows proof, 2026-09-26

This is the fourth and final proof run before Kat's own switch-on. Real texts, real production, the Willows test property only (org_sandbox). Staff tester's own phone stood in for Kat; every prospect was a bench number we own. Nothing in this run touched Western Slope, Camellia, or Riley Chen's real card. Run window: 12:29–13:07 MT (booking scenarios) plus 11:30–11:45 MT (the post-tour check-in, same afternoon).

Before → after

The real conversation

Every message below is a real text between the staff tester's phone and Clara's Willows number, in Mountain Time. The small text under each bubble is the Twilio message id, for anyone who wants to look it up directly.

1 · Book on an existing card, with a unit — Alex Rivera, unit 204

2 · New prospect by email only — Casey Bench, unit 105

3 · "Which unit?" with a bad answer — Drew Bench, unit 203

4 · Reschedule — Alex Rivera to 2:00 PM

5 · Add a note — Casey Bench

6 · Cancel — Drew Bench

7 · Continuity check — "is Alex's showing still on?"

8 · Near-term booking, same day — Riley Bench, unit 201

9 · The post-tour check-in — Riley Bench, 30 minutes after the 10:30 AM tour

A second, older check-in for a different Riley (Riley Chen, card 112 — never touched by this proof, banned from every run) was open in the same window and was correctly left alone. Clara attached the "loved the natural light" reply to the right Riley.

Screenshots

Scorecard

Also checked and confirmed clean this run: no invented "that slot just got taken" excuses, no wrong unit ever named for a real showing, no leftover turnover disclaimers, and the wrong-person mix-up from earlier runs did not come back once.

What's still open

• The Willows' test units aren't real AppFolio units. Units 105, 106, 201, 203, 204 and 305 only exist in PropFlow's own test data — AppFolio's real property only has units 101, 102 and 412. So every showing booked on one of those test-only units can never sync to AppFolio, no matter how well the booking itself works. This is a test-setup problem, not a customer problem: Western Slope has zero of its 234 real units missing an AppFolio id, and Camellia has zero of its 120. The fix is simple — run the next test round on units 101, 102 or 412 instead.
• The AppFolio connection ran out of capacity this morning — and that's also why the post-tour note hasn't reached AppFolio yet. Starting around 1:16 AM MT, AppFolio stopped accepting new writes because a background sync job was re-checking the same roughly 57 guest cards about 110 times an hour and used up the shared connection's hourly allowance. Riley Bench's post-tour note is saved and visible on her PropFlow timeline, but as of 11:48 AM MT the copy meant for her AppFolio card was still failing — same cap, not a problem with the note itself. Every AppFolio action returns a blank, unhelpful error while the cap is over budget; the note will go through on its own retry once the cap is lifted. The re-check bug that burned the quota is already fixed and merged. Fede separately approved paying for a bigger allowance, and another session is putting that in place now. A related fix, PR #12609, is about to merge — it makes these failures show the real reason instead of a blank one, so the next time this happens it's obvious at a glance instead of needing this kind of digging.

Decisions for Fede

Marked Proposed — pending review.

1. Turn Kat's switch on Wednesday 9/30?

• A. Yes, go live Wednesday 9/30 as planned.
• B. Wait until the AppFolio guest-card and showing-sync failures above are fixed and re-proven.
• C. Push the date out further.

Recommendation: A. Every failure this run was on the AppFolio side, and Clara was honest about every one of them instead of claiming a write that didn't happen — nothing in this run put a wrong answer in front of a person. Fede's own test week (starting 9/28) is the last check before Kat's Wednesday go-live either way.

2. Which calendar do desk-booked tours land on — the property's, or Kat's own?

• A. The property's calendar (same calendar every other tour already uses).
• B. Kat's own personal calendar.

Recommendation: A. Keeps one calendar per property regardless of who booked the tour, so nothing has to be reconciled between two calendars later.

3. Does texting consent carry over for a prospect that staff hand to Clara by text (not the prospect texting in themselves)?

• A. Yes — treat staff's introduction as consent to text the prospect directly.
• B. No — confirm by email only, until the prospect texts Clara first themselves.

Recommendation: B. This run confirmed the code already does this (no SMS consent was recorded off a staff text for any new prospect) — keeping it this way means Clara never sends a first text to someone who never agreed to receive one from us.