One person, several homes

Where it stands

How it works

Clara keeps one record and one conversation per person. A second home is a new turn in the running thread (“You also asked about Oak St. It’s open; want to see it with Elm on Saturday?”), never a second first email. Most second homes arrive days later, so this turn is the normal case, not the edge.

Follow-ups are wakes, not timers, as on the vision page: when the clock fires or a new home arrives, Clara is woken with the whole picture and writes the next message, or waits.

The job is to narrow to one: answer about every home, ask one question that splits the set, get at least one tour (several are fine), then send the application for the home they chose.

The model is ours, not AppFolio’s: Clara’s records hold the state and each property system is a mapping, so it works with any PMS and any lead source.

Retro 10/10: the first same-moment case

What happened

Saturday 10/10, 12:49 PM MT, Western Slope. Clayton Barnfield’s Rent.com card arrived in AppFolio with two homes: 2841 Morningside Ct and 2978 Emerald Cir. Clara made one person and one conversation, as designed. But she sent two first emails 55 seconds apart (12:51:48 and 12:52:43). The second opened “good to hear from you again” and offered different tour times.

Two follow-up clocks started; they fold into one at the first wake, as designed. Nothing went unanswered. Fede: “the first time we get two interests it breaks.”

Why the design missed it

The design assumed the second home arrives days later (“most second homes arrive days later, so this turn is the normal case”). The number that would have tested that was asked for on 10/9 and not delivered until 10/10.

Gap from the first home’s inquiry to the second home’s, by AppFolio Received minute, same 9,443-person history. Within ten minutes it is the same AppFolio card 148 of 237 times.

Reading: the right bet for Western Slope’s scattered homes, the wrong one for a centralized company like Situs, where one in four second homes lands within ten minutes. There, same-moment is the normal shape, not the edge.

Why the harness missed it

The replays (1,703 inquiries) and live runs graded what Clara says, how many people and cards she makes, and the follow-up clock. No test case had two homes arriving together on one card, and no check said “one outbound per person per arrival.” The first email’s content was right (it named both homes); the count was never checked.

Where Clara still speaks per home

“Isn’t it the same Clara?” No. The first reply fires per home from a lead event. When a second home arrives as its own event, that reply is written by a separate first-email writer, not the engine that writes every later reply. The context is the same (every home); the trigger, and sometimes the writer, are not.

No existing rule would have stopped email 2: the 12-hour cooldown covers only timed paths, the first-touch claim only blocks the other path, the “already answered” check is same-home only, and duplicate protection is per inquiry.

Name rule, checked

Bow (10/8, 3:55 PM) and Anna Neil (10/3) were not auto-joined because both arrived before the rule merged (10/8, 8:17 PM); replayed, it would have joined both. The rule fires only on a new listing-site email lead, never on card sync, and never revisits existing records, so Anna stays split until a merge rule exists. Not a bug.

Fede’s ruling, 10/10 (supersedes the proposal above)

“If someone inquires about a home we do want to reply within 30 seconds. If that person submits another inquiry it should be the same person, same conversation; it’s fine to do another email, ‘you’re also interested in this.’ Clara knows there are two homes, the follow-ups know there are two homes, but there is one per person. That was the whole point. The hard-coded 12-hour thing makes no sense. Back to the test harness, extend it with this use case, try again. This is a failure.”

• The first reply stays fast. No settle window before it. A second home arriving later gets its own short turn in the same conversation.
• Follow-ups: exactly one per person at all times, keyed to the person. Not per-home timers that fold a day later.
• No hard-coded time windows as guards. The 12-hour per-person cooldown was never approved and goes away in the redesign; other windows (the ~20-hour gap, the 30-minute first-touch claim) are listed and reviewed the same way.
• The second email to Clayton was acceptable. The two timers were the failure.

Order:

1. Extend the multi-home harness with Clayton’s real case (two inquiries on one card seconds apart): assert one person, one conversation, at most one first email per home, and exactly one follow-up track per person that names both homes, with a planted control; must be RED on today’s code.
2. Redesign the follow-up clock to be per person, reviewed by Fede.
3. Build.

Status: harness extended and RED on today’s code (10/10 afternoon, branch fede/multihome-harness-same-moment, npm run harness:person-first, case 10). Red check: right after the second home arrives, the person has two follow-up clocks instead of one, for about a day until one folds into the other. Green on today’s code: one conversation, at most one first email per home, one follow-up per touch naming both homes after the first wake. Correction: the 12-hour cooldown is not what blocks the second follow-up; the fold at first wake is, and the harness shows the same output with the cooldown at zero. Finding: the 10/9 PRs (#18286, #18305) were proven with unit tests and one-off replays, not a committed harness; this case is now the first committed one. Redesign build in progress on a local branch; no PR until Fede reviews before/after.

Day-two check, 10/11, 12:52 PM: the renter got exactly one follow-up. Both per-inquiry clocks woke within a minute; the home A clock sent one text and the home B clock saw it and closed. So the fold held in production. The wording is the weak spot: the text said “that home is no longer available” without naming which of the two, offered home A plus a third home the renter never asked about, and went by text although the whole conversation had been email. This is the live example for Fede’s question about follow-ups being shaped around one home; the redesign’s follow-up text must name every home the person asked about by name.

Hard-coded windows on the follow-up path (none approved by Fede)

Why a separate first-reply path exists (history, 10/10)

Short answer: yes, Clara still has a separate first-email path. Since 9/24 the regular engine writes the words for most first emails, but about 13,000 lines across 13 modules still run only around the first email, and the old 4,100-line writer still writes the whole email in three cases: a second or third home on the same card (118 of 908 Western Slope cards), a redraft when the planned tour time is gone, and every draft at a company that is not live.

What is separate today

How it came to be

No PR gives a design reason for keeping per-inquiry on the old writer beyond “the engine turn doesn't do it yet.”

Bugs on the first-reply path since 9/19

Score: 11 of 18 would not have existed as a normal engine turn, 4 would have happened anyway, 3 partly. “Didn't offer a tour the next day” is a recurring symptom, not one incident: it hit the old writer (9/19, 9/23), the engine (9/29) and the shared slot finder (10/9).

What is truly first-reply-specific and must survive a fold: exactly one first email per person (today per inquiry); the system-cards-only guard; hold-or-send decided before any conversation or tour exists; book at release and cancel if never sent; the AppFolio “Email Sent” record and assigning Clara; never cold-email someone who already applied, toured or was answered; tell the team when drafting fails. The prompt rules (greeting, one sentence on a system card, the card's home wins, listing price only, never volunteer a gap, book a requested open time) already live on the engine.

Recommendation (Fede already ruled “one engine” on 9/24 and 9/30; the question is what is left to fold): 1) move per-inquiry and the no-tour redraft onto the engine and delete the old writer, which needs the engine thread to see every home on the person's card; 2) send the first email through the shared prospect-email sender so hold and branding come from one place; 3) have the AppFolio note and the engaged stamp listen to the “Clara replied” event. Structural risk: today the engine turn creates a conversation and books before the hold verdict, and the prep step undoes it; the 9/26–28 timeouts were cleanup failures of this kind. The real fold puts hold, checks and the one-per-person decision inside the engine's own send step.

Redesign 10/10: one follow-up track per person, restarted by a new home

Before: each home started its own follow-up clock; they merged a day later. After: the first home starts the person’s clock. A later home that arrives while that clock still owes a message restarts it from the top: the old clock stops, one new clock starts anchored at the new home, and the next follow-up is Day 1 after the new home’s first reply, naming every home. First replies are untouched: each home still gets its own reply in seconds (“you’d also asked about…”). No settle window, no switch.

Why restart rather than join: follow-ups sent 1–2 days after the person last wrote get a reply about 30% of the time; at 3–14 days it is about 7%. A new home is the person writing again, so the clock should count from there.

Restart, not “start a second clock and fold it later”. The track row is moved to the new home before anything is stopped (one row per person, first writer wins), then the old clock’s run is terminated with the reason “restarted: the person asked about another home” and its row is stamped done the same way the 10/9 fold stamps a folded home, so the old home is still named in every follow-up. Three cases do not restart: two homes in the same moment (the row is claimed but no clock is enrolled yet) join one clock; a repair of a dead clock joins the live one instead of killing it; a clock already in its final 48-hour reply wait is left alone and the new home starts fresh. The old fold stays only as a backstop.

Hard-coded windows: what still matters

Do follow-ups name every home?

The AI draft and the email subject already named every home. The fixed fallback text (used when a draft fails its checks) named one. Fixed:

Email and Spanish fallbacks changed the same way. Still one-home: “Clara with Home A” and per-home branding.

Every real person replayed, before vs after

Real arrivals, the real start/restart code, a simulated clock, nothing sent. The count of messages does not change; their timing does: every follow-up now lands 1, 2, 7 and 14 days after the person last wrote, and names every home. The real workflow was then replayed on a time-skipping server over the same people (200 multi-home people: 0 faults, at most one owing clock per person, 154 restarts, 1,392 messages, matching the simulation).

Three real renters (scrubbed)

Proof, rollout, risks

Running clocks drain as today: two still fold at their first wake, no double send.

Risks: two homes arriving in the same moment through two different consumers can still start two clocks, because the sibling list is read eventually-consistent (the fold catches it at the first wake; tracked as issue #18678); if the new clock fails to start after the old one was stopped, the daily repair job re-enrols the home; AI-written follow-ups were not regenerated (examples show fallback text).

Willows production run, 10/11

Setup. Sandbox company only: Home A = the Willows (guest card by the robot), Homes B and C = Yale 25 Station sandbox (Zillow-style lead email into its leasing inbox). Three test renters on our own test mailbox. No timer shortened; the reset is proven from the workflow history. Production was on commit 26f84cf686 (includes #18673).

Why C is a second renter. A property keeps one inquiry per renter, so a renter cannot ask about two Yale homes as two clocks. “Third home while the clock runs” is therefore Renter 1: Willows clock running, then Yale 3.5 minutes later.

Day-1 wording check, 10/12

Re-run started 10/12, 2:24 PM MT. One new renter, Yale email first (20:24:14), Willows guest card 214 second (engaged 20:26:00). One conversation, Willows holds the one clock, day-1 wake 10/13 20:26 UTC (2:26 PM MT), sent from the Willows mailbox. Nothing is closed until that text is read. Expected: the text names The Willows and Yale 25 Station and no other home.

Harness lesson: never close or mark inactive a test card before the last proof rung has fired; closing is correct engine behavior and ends the clock.

Why restart and not join for Renter 2. Join only happens when the first home has claimed the clock but not started it yet. Yale’s clock was already running 38 s before the Willows home engaged, so #18673 restarts. That is the intended rule.

One first email per home in every case. No texts: the test phones are fictional 555 numbers.

Finding, outside the clock change: when two homes arrive within a minute, each opens its own conversation, so the renter gets two threads. The clock is still single. Follow-up candidate for the conversation-joining code, not a #18673 defect.

Cleanup. Willows cards 209, 210, 211 marked Inactive (reason Duplicate) by the robot at 20:01; Yale has no AppFolio cards. The three test clocks are left running and will send their day-1 follow-ups to our own test mailbox around 19:55 UTC on 10/12. The older stray clock from the 10/8 test (person 2727b016) is also still running, untouched. All writes are in the production write ledger.

What’s next

Every step climbs the testing ladder: replay of every customer’s real book, byte-identical where nothing should change → Willows live run → Fairhaven sandbox.

1. PR 1, one conversation per person (today). Proof: full replay with one-home cases byte-identical, then Willows, then Fairhaven.
2. Task 2, repair the 10 split Western Slope people (done 10/9). Proof: each surviving thread’s message count equals the sum of its parts, and the Bowmuxlow and Tessa Adams pages read in date order.
3. PR 2, one follow-up clock per person. Proof: replay shows one nudge per person, never one per home, then Willows and Fairhaven.
4. PR 3, the “which home?” question and the application to the chosen home. Proof: the narrowing question well above 20 of 50 on the replay, one-home cases unchanged, then Willows and Fairhaven.
5. Task 3, duplicate AppFolio cards (later). Proof: a dry-run list of every card to touch before any write; we do it, never Western Slope’s staff.
6. No-show marked in AppFolio (from Jay, 10/9). Done 10/11 (PR #18697): a staff-recorded no-show now flips the AppFolio showing to No Show. Before: staff tells Clara “he didn’t show”, Clara stamps the tour as a no-show in PropFlow and writes the card note, and the AppFolio showing stays Completed. Design: the same staff reply also flips the AppFolio showing to No Show through the robot (the robot’s cancel-showing action already takes a no-show status, but AppFolio rejected its guessed value on 10/9; the real action must be captured first). No switch; a fix to live behavior. Proof: Willows showing #10 on test card 107.

Open for Fede

1. Merge on Western Slope cards: does AppFolio’s action menu show Merge on one of their cards? Recommend: check one card; if not, Mark Inactive plus a note.
2. Jay’s card 236: Mark Inactive by hand now, or wait for a robot action? Recommend: the robot action later, with the card cleanup.
3. New home mid-follow-up: Decided 10/11: restart. Restart from the top, anchored at the new home (Fede: “Build it and ship”). Shipping as PR #18673. See the redesign.
4. Staff on the phone line: handed to the vision page. Recommend: keep it there, out of this work.

Name rule, tested on every card we hold (10/9)

9,987 cards, all customers, all years. The 7 doubtful joins are old Situs cards from 2022–2023.

Replays of real Western Slope leads

Same-name collisions (2,993 cards, 2025 on)

Reply prototype (10/9, offline, 57 masked people)

Dataset (full AppFolio history)

Industry (research 10/8)

Not built, by ruling