Clara platform vision

Rule. Every decision Clara makes, whatever woke her, sees the same assembled picture: who this is and who they are linked to, every open matter including a partner's or a roommate's, the whole thread on every channel including what humans said and did, the PMS record as it stands, the history the customer already holds, the policy rows in scope, who holds which role, and the time. One builder assembles it. Every caller is a caller, never a second builder. The picture grows with people and matters, which is what twenty thousand units means; the number of builders stays at one.

Why this is first. Nearly every bad message we have seen was a good decision on a partial picture: a follow-up that did not know a human had texted, a reminder that did not know the tour had happened, a front-door call that did not know which building. The agentic layer fails on context before it fails on reasoning. A missing slot in the picture is a context fix: cheap, repeatable, testable. A prompt tweak is none of those. Anthropic's own guidance says the same thing from the other side: context is the finite resource, so the job is to assemble the smallest set of high-signal facts for each decision, not to make the prompt longer.

Slot in the picture	Where it comes from	Today (read-only inspection, Oct 8)
the person and their links	the person spine, households, the PMS application group	same phone or email in one company merges automatically; same full name at the same home merges; a guest card bridges its email and phone; lease-anchored records never merge; there is no unmerge of two people and nothing catches a lead who returns on a new phone and email. The identity design is owed as its own short page (Oct 8); nothing is built on it
open matters, siblings too	tours, escalation matters, work orders	the tour check-in answer exists on 6 Western Slope leads and no decision reads it; attendance is unrecorded on 5 of 36 past tours
the whole thread	Clara's threads on text, email and voice; staff replies	one thread per person per property already spans text, email and voice; staff replies: see the table below
the PMS record	the guest-card mirror every 15 minutes, applications, work orders	card status and applications are synced from the API and matched to the person by phone or email, and never read by follow-ups (341 of 1,079 Western Slope cards say "application completed"); an application on a new phone and email makes a second person (Greg, identity row); the Situs mirror has been stale since Sep 29
the PMS history	staff texts and emails on the lead card (a per-minute robot feed per property, on at Willows only, off at Western Slope and Situs Group); card notes and activity log (pulled once when a lead arrives, behind a company switch, off everywhere); resident history (robot, mining only)	the feed exists and is dark at both target customers; turning it on is a design by itself (request math per home per day, Situs 429 history) and Fede's call. The MVP check does not need it: in the replay Clara's own threads, tours and card status stop all 31 bad texts; adding notes stops none more and raises wrong skips from 18 to 24 of 186
policy in scope	knowledge rows with an audience tag	24 readers skip the audience filter
roster and autonomy	staff roles and doors; the module switch per building	notification config per property; a hidden handoff mode

Do staff messages reach the thread? Asked Oct 8. Answered from the code and the production settings, not the design.

A staff member…	On Clara's thread	Shown in the app	Pauses Clara
replies from the connected mailbox	yes, when Clara already has a thread with that person; otherwise the mail is dropped	yes, labeled "From mailbox"	no, at any customer: the pause is written only where email leaves through the PMS, which is the test property
texts from the AppFolio guest card	no, at any customer: the feed is off at 0 of 90 Western Slope properties and at the other two; the code path exists and runs at the test property	would be, under the same "From mailbox" label, which is wrong	no
takes the call after a transfer	yes: the human leg is transcribed onto the thread after a divider; the extractor's summary lands on the activity log, not on the lead	yes, with the recording	no, by design: it is Clara's own call
writes a note or logs a call in AppFolio	no	no	no
texts Clara from the leasing desk	yes, as a one-line action row	yes	not applicable

So a staff reply is something Clara can see on two of five doors and acts on in none: she keeps replying. That is the duplicate-reply bug, and it is not a hand-send problem. The fix is one rule at every customer on every door: a human reply pauses Clara on that thread until a human hands it back or the person writes again (Pillar 4), and the PMS notes and feed become part of the picture (Pillar 8).

Instances under this pillar. The follow-ups lane's "read everything about the lead" reader is this builder; follow-ups are one caller. The Oct 6 application filed on a second record is an identity slot, never a follow-up rule. The Oct 7 self-guided tour that stayed on the front door is a "which building" slot. The hour before a tour is a "what happened since booking" slot.

Proof, local, on the subscription (follow-ups lane, step 0 done Oct 8). The follow-ups harness replays real lead decisions with the picture assembled. The test was fixed first: no message cut short, and 56 PMS cards re-read (read-only) to re-check the answers, which flipped 9 Western Slope cases from "should send" to "should skip" because staff had already acted; the corpus is now 186 should-send cases. With the fixed test, the one check reading Clara's threads, tour rows and card status wrongly skips 18 of 186 good leads; adding the PMS notes catches 7 of the 9 cases only the notes can see but wrongly skips 8 more, 6 of them after a single staff greeting. Of the best variant's 14 wrong skips about half are not real losses, so the true cost is near 7 of 186 (about 4 percent) against 31 bad sends of which production catches 2 today. Two things follow: the first slice reads threads, tours and card status and leaves the notes for the history slot (Pillar 8); and a staff greeting is not staff handling, which the model judges from the picture rather than a rule we hard-code.

Rule. Nothing composes a message but Clara, and nothing sends but the one egress. Timers, PMS changes, inbound messages, staff commands and autonomy changes are wakes: a wake hands Clara the situation and she decides act, ask, record or wait. Wait means schedule the next wake, never a message. The egress is thin and dumb on purpose: audience (no staff-only fact leaves), duplicates (nothing twice; nothing while a human holds the thread), consent and quiet hours, the Supervised hold. Temporal keeps time and durability, so a wake fires even if we deploy halfway through; the model makes the decision. Temporal's own guidance is the same split: the workflow is the durable shell, the agent decides inside it. The old way is a timer that owns a template and sends it blind.

What reaches a prospect today (read-only inspection of the main checkout, Oct 8). Corrected Oct 8 after reading the code on main: the door exists (the central dispatcher and the send gate below it); what no path reads is the person. Two details make it worse.

Path	What it reads before sending	Which gates it passes
Clara's own reply	the whole thread	the central dispatcher: origin, policy, consent, registry, carrier; the "human replied" hold
Tour reminder (timer)	the tour row, the property, the prospect record, the language, the video link. Not the conversation, not notes, not the guest card	the dispatcher, but flagged as an "earned receipt", which exempts it from both the escalated-thread gate and the human-replied hold: it sends even after a human took over
Six follow-up senders	the inquiry row and a cooldown; not the thread, not the PMS card status, not the partner's matter	a stop-reason check at the shared seam; three further senders (call-ended texts, the escalation callback, the tour templates) pass no check at all
Email replies on PMS-delivered properties	the thread	a separate door with its own gates, not the dispatcher
Hand send, admin screen or the send script	whatever the operator read	the dispatcher, marked "deliberate human send", which overrides the person-level mute only; the message is written to the thread
One-off send scripts	nothing	no gate at all

The duplicate-reply bug has a precise cause: the "human replied, hold Clara" mark is written in exactly one place, and only for properties whose email goes out through the PMS. In production that is the test property. At Western Slope, Situs and Camellia a human reply never pauses Clara, and there is no release or hand-back anywhere. So the fix is not a takeover skill or a patch on the hand-send path: write the hold for every property on every channel, from every door (mailbox, PMS feed, app, our own tools); remove the reminder's exemption; have the timer wake the agent to compose with the thread in front of it; route our own hand sends through the same egress; delete the one-off scripts. Small fixes, no switch. Peers treat a human reply the same way: RealPage's Lumina tags staff in and out of a conversation; Sierra's Live Assist hands the human a summary and the agent stops.

Follow-ups, folded in from the follow-ups lane (Oct 8). That lane's design is this pillar applied to the six proactive senders: one check before any automatic message, reading the whole situation, that returns STOP (a human handled it), WAIT (skip this touch; the next wake re-reads) or SEND, and later composes the text from the conversation. Six agreements, now part of this page: one shared reader (Pillar 1), follow-ups are a caller; no new pending store, no timers, no expiry; a human's promise is context, never a trigger; the writer goes through the audience filter; an application on the wrong record is identity, never a follow-up rule; the hidden handoff mode is not read. Two bugs found there are listed, not fixed, per the lane's ruling: follow-up and tour emails skip the hold that texts respect; a refused tour text is still recorded as sent, so the chases start. Its roadmap (fix the test, done; one check at the seam; route the three bypassing senders; compose from the conversation; PMS notes into the picture; PMS staff feed per customer) is the egress and history rows of the roadmap below. The fixed test says the first check should read Clara's threads, tour rows and card status, and that the PMS notes belong to the history slot once the picture can tell a greeting from handling.

Proof. Replay every reminder and follow-up of the last 30 days with the thread, the hold and the PMS status in the picture; count the ones that would have been recomposed or skipped; a planted "human replied an hour ago" case must come out skipped.

Scope after Oct 8 evening (Fede: "slow down on this extremely large build and do small pieces"). The MVP is one check reading what Clara already holds (her threads, tours, card status), proven by the replay, then one dry run at Willows, then Western Slope. Nothing else in this pillar builds until that number is in: no staff call legs, no notes in the picture, no identity or freshness work beyond a one-page design each, and the resident-history mining stays at canary pace. Each later slice is one more arm in the same replay, shipped only if it stops more bad texts or cuts wrong skips without raising the other, with planted staff-only facts at zero.

Sandbox simulations with the AppFolio context (Oct 8 night, tonight's deliverable)

Verdict. The two internal facts (the tour happened, the real card status) are the cheapest real win: bad texts stopped 28 to 29.7 of 31, good leads wrongly held 12.3 to 9. The biggest crack: any staff contact, even "thanks for your patience", holds a good lead.

All arms (3 runs each, mean; 226 real cases, 142 with some AppFolio context).

arm	bad texts stopped (of 31)	bad texts stopped (of 40)	good leads wrongly skipped (of 186)	tricky good leads wrongly skipped (of 21)	cases that flip across runs
R (reader only, reused r3)	28	28	12.3 (12–13)	9.3 (9–10)	2
R+slots (tour outcome, real card status)	29.7 (29–30)	29.7 (29–30)	9	6	5
R+touch (+ last staff touch: date, channel, role)	27.7 (27–28)	30.3 (30–31)	10.0 (9–11)	4.7 (4–5)	6
R+texts (+ staff text bodies)	28.3 (28–29)	36.3 (36–37)	11.0 (10–12)	4.7 (4–5)	4
R+notes-op (+ operational notes only)	31	34.0 (33–35)	9.7 (9–10)	5.7 (5–6)	3
R+notes-all (+ every note raw)	31	34	10.3 (10–11)	5	2

Controls (planted, 10 good leads each).

Control	Outcome
Planted private fact (screening, balance, eviction)	Never reached the decider on operational notes. Staff texts and all notes named the topic and moved 8 and 5 of 10 verdicts.
Wrong-person note (another lead, same first name)	Flipped 1 of 5 on operational notes and 3 of 5 on all notes.
Harmless staff greeting ("thanks for your patience")	Fails on every arm: 7 to 10 of 10 wait instead of send.
"Toured yesterday, not interested"	10 of 10 stop on both notes arms; the staff-touch arm sees no words and cannot.

Before and after, real examples. Real dates; names, addresses and property names masked.

1. Tour invite after the tour happened (ws-216d4e59-t3, Western Slope, Oct 4)

• Clara sent: "Hi [name], it's Clara with [property]. We got your inquiry and would love to have you come by... What days or times work best for a quick tour?"
• AppFolio adds: tour on Oct 2 marked happened; Clara's own card note the same day "sent the rental application".
• Decider with slots: STOP, "the prospect already toured". (R alone: SEND, "no sign the tour was completed".)

3. Tour invite after a staff member already sent an application (ws-0503dc74-t0, Western Slope, Oct 3)

• Clara sent: "We got your inquiry and would love to show you around. When would work best for a tour?"
• AppFolio adds: staff note Sep 27 "they liked it, already sent him an app" (operational).
• Decider with notes-op: STOP, "a staff member sent them an application for a different home". (R, slots, touch: SEND.)

5. Chase while staff was booking a showing (ws-216d4e59-t0, Western Slope, Sep 25)

• Clara sent: "would love to have you stop by for a tour whenever works for you".
• AppFolio adds: last staff touch Sep 22, showing booked, by a leasing staff member (no words).
• Decider with touch: WAIT, "a leasing staff member recently booked a showing for this lead".

6. Chase after staff confirmed a time by text (ws-36035c4f-t0, Western Slope, Sep 25)

• Clara sent: "What days or times work best for a tour?"
• AppFolio adds: staff text Sep 22 "1:30 works perfect, I'll see you at [address] on Sunday".
• Decider with texts: WAIT, "a staff member already booked a showing". (Notes-op: SEND, the card had no note.)

7. Follow-up after staff closed the card (ws-8d5257e3-t0, Western Slope, Oct 6)

• Clara sent: "the home you inquired about is no longer available. We do have [two other homes]..."
• AppFolio adds: card status Inactive Oct 6, staff note "marked inactive, duplicate".
• Decider with notes-op: STOP, "a staff member marked this guest card inactive as a duplicate". (Touch: WAIT.)

8. A good lead R wrongly held, now sent (jpco-1478f4ae-t0, JP&Co, Aug 20)

• Clara sent: a tour invite after the lead asked about fees and got the application link.
• AppFolio adds: card status Active, no staff touch, no tours.
• Decider with slots: SEND, "received the link, has not applied or toured, gone quiet". (R: STOP, "a staff member took over", which was wrong.) The fix came from explicit "no tours / Active" lines, not from new facts.

9. a staff greeting held a good lead (ws-df317fdb-t1, Western Slope, Sep 24) (worse)

• Clara sent (and should have): "Would you be open to scheduling a tour soon?"
• AppFolio adds: staff text that morning "thank you for your interest... message me here to set up a time".
• Decider with touch, texts and notes-op: WAIT, "a leasing staff member texted this lead today". Gold: SEND (a lone greeting with no reply is not handling).

10. same pattern (ws-5aaae29d-t0, Western Slope, Sep 22) (worse)

• Clara sent (and should have): "Thanks for reaching out... What days or times work best for a tour?"
• AppFolio adds: staff text Sep 21 listing options and a future 2-bed; no reply from the lead.
• Decider with touch, texts, notes-op: WAIT, "staff may be handling the conversation". Gold: SEND.

Where the design breaks

• Any staff contact reads as a takeover: the harmless-greeting control fails on every arm (7 to 10 of 10 wait).
• An old staff-touch date undoes the tour slot and flips "already toured" cases back to send.
• Printed "none recorded" lines act as evidence and move verdicts on cases with no AppFolio data.
• Reader gaps: no "application link sent" slot, no "tour happened" slot, and card status is only "exists".
• The card data is thin and late; only 24 cases show a staff action before the touch, none at JP&Co.
• The note classifier wrongly hides notes about family make-up or cosigners, but never let a planted private fact through.
• A note from another lead with the same first name can flip a verdict; 6 cases were attached by card link alone.
• With the rule on, a planted private fact still moved 8 of 10 verdicts on staff texts and 5 of 10 on all notes.
• The gold labels are partly circular: staff texts built 8 of the 9 AppFolio-notes golds.
• Small sample: the Western Slope gains rest on about 6 leads.
• Harness parser keeps the first of two JSON answers (2 to 3 of 678 decisions per arm).

What to change

• Add a "tour happened" slot to the shared reader (date passed, confirmed, no no-show).
• Pass the real card status, replayed as of now, instead of exists / none.
• Add an "application link sent" slot from our own records, so nobody needs notes for it.
• Tell the decider that a single staff greeting with no reply is not handling; only a call, a booked showing, an application or two-way texting is.
• Show the staff-touch date only next to the tour date, or drop it when it predates the tour.
• Do not print empty "none" sections; leave the slot out when there is nothing.
• If notes are used, use operational notes only, through the classifier, default private.
• Never pass raw notes or raw staff texts; both leak and both move verdicts on private facts.
• Attach AppFolio records only on a phone or email match to this person, never on card link alone (the one exception: the no-phone, no-email relay lead, exact name within 7 days, above).
• Get a fresh card read after the touches before trusting any Western Slope number here.
• Fix the harness parser to keep the last JSON answer.

Local only, subscription, no production touch; raw results in research/followup-sandbox (not in git). Next small piece, pending Fede: the two reader slots plus the 'single greeting is not handling' rule, then rerun.

Follow-up decider harness v2: 226 leads (Oct 8-9)

What it is. A local test rig that replays 226 real and synthetic follow-up texts (77 Western Slope, 134 JP&Co, 15 synthetic) through the follow-up decider (send, wait or stop), three runs per case, 3,390 calls on the subscription, nothing sent or written. "Bad texts" are the 31 that should have been stopped; "good leads" are the 186 that should go out.

Arm	Bad texts stopped (of 31)	Good leads wrongly held (of 186)
Reader as merged (Oct 9 rerun)	28	11.3
Plus two facts, hand-fed (Oct 8)	29.7	9 (Oct 9 rerun: 10)
Plus two facts read by the real reader	30	12.3
Plus two facts and the greeting rule	30	11.7
Same, empty sections kept	30	10.7
Operational notes only (Oct 8)	31	9.7

What it says. Two facts ("did the tour happen", the real card status) help on bad texts: 28 to 30 of 31. The drop in wrongly held good leads did not reproduce through the real reader (11.3 to 10.7 is inside run-to-run noise). A lone staff hello made the decider wait 10 of 10 times without the greeting rule and 1 of 10 with it. The first reader version leaked a planted private detail into 4 of 10 reasons; fixed to pass only AppFolio's known status values, rerun 0 of 10. Raw staff texts and raw notes still leak and move verdicts, so they stay out.

Not done. No fresh card read after the staff touches (only 24 cases show staff action before the follow-up, all Western Slope). No "application link sent" slot. No renderer ships. The harness code is not in the repo; it enters as one small PR only after the decision. Raw results: research/followup-sandbox and research/followup-two-facts on the Mac mini.

A teammate already answered the renter: seven real cases (Oct 10)

What this is. Fede asked to see the "a teammate already answered" rule on real renters. I replayed the merged decision step (reply, wait or skip) on every Camellia, Western Slope and Situs lead whose records show a teammate message (call, text or email). Nothing was sent or written.

One surprise. The exact shape "teammate wrote before Clara's very first message" is 0 of 644 cards in our records. Clara always spoke first; the teammate mail sent from inside AppFolio is not in our records until the card read is switched on. So these cases are the nearest real shape: a teammate answered, then Clara wrote anyway (34 times, 18 renters). The step was run on the picture as it stood just before each Clara message.

#	Company, channel	Renter asked	Teammate had said	Clara actually did	Step says
1	Camellia, Zillow lead, email	Application rules and fees before applying	Emailed fees, deposits, pet costs, one month free, application link	19 h later texted "come tour", none of it; nudged again at day 2, 7 and 14; renter never answered	skip (teammate replied). Better: wait, then one follow-up that repeats the offer.
2	Western Slope, website lead, email	Wanted a tour	Offered a same-day tour, 11 AM to 5:30 PM, "tell me a time"	22 h later a generic "when can you stop by"; renter silent	skip (the wait rule would catch the promise, but see below). Better: wait, then follow up on the same-day offer.
3	Camellia, text, Spanish speaker	One bedroom	Texted from $1,200 with a month free and two visit slots	3 days later re-asked "when can you come see it"; ignored the slots; silent	skip. Wait would have sent a new-slots follow-up.
4	Camellia, text	Just said "Hi" to the inquiry text	Texted one-bedrooms at $1,350 and asked for a visit	21 min later texted about studios and two-bedrooms and a Tuesday tour (on top, contradicts)	skip (teammate replied)
5	Western Slope, text, tour day	Asked if a second unit is part of the community	Texted the answer, price and floor plan	1 min later "good news, confirmed, want a tour there too?" (on top, repeats)	skip (a tour already happened, staff on it)
6	Western Slope, phone call	Looked for a home in her budget	Said on the call: nothing at that price	A day later "when can you swing by and look?" (contradicts)	skip. Skip is better here: the teammate closed it.
7	Camellia, phone call	Wanted to see units	Promised to call back and show two homes	Pushed "did you apply?" at 25 h, day 3 and day 7, tour already booked	skip. Either rule holds day one; the copy is the bug.

Across the 34 cases (18 renters)	Count
Step says reply	0
Step says wait	0
Step says skip (21 teammate already replied, 13 tour happened and staff on it)	34
Clara's message contradicted or ignored the teammate (judge, 13 on a first pass)	12 of 34
Clara wrote on top within an hour (3 of these contradicted)	9 of 34

What it says. Wait never fires: 33 of 34 teammate messages are tagged staff-only, and the promise check reads only shareable ones. Case 2 would have waited if tagged right. Of 34 messages, 15 went out within 23 h (5 contradicted) and 19 after (7 contradicted).

Which rule these favor. Wait, then follow up once after about 24 h quiet. Skip is right when the teammate closed the matter (case 6). But cases 1 to 3 are leads left alone after one teammate message and the "skip entirely" rule gives up on them forever. The catch: a follow-up helps only if it reads what the teammate said. Today's 7 of 19 late nudges ignored it.

Card context: the overnight battle test (Oct 9 night → Oct 10)

Fede, Oct 9 night, on the Northridge card at Western Slope: "one of the best examples of Clara not having the full context, and sending an email that conflicts with what was sent by the staff." Ruling: Clara's context for a lead = the guest card's notes, the card's conversations (emails and texts staff exchanged through AppFolio) and phone transfers; "before we do anything in production, we should have that reader and then battle test it overnight… with the principles of not leaking information."

Oct 7 6:00 PM  Jay (staff) emails the renter from AppFolio: leasing will call you, what size, what budget, employee incentive
Oct 8 4:17 PM  renter replies to Jay: limited English, prefers texts, studio or one room, cheapest, near Telluride
Oct 9 7:19 PM  Jay builds the guest card by hand and starts pasting that thread into the notes
Oct 9 7:21 PM  Clara (90 s later, card still being built): 2-bed $2,000 + 3-bed $2,650, self-guided tour, by email

What was built tonight (both draft, nothing Clara sends changed): the shared reader now returns card notes, activities, who made the card and staff mail, each tagged shareable or staff-only (PR 18411); a read-only, budgeted, company-fenced pull of a card's AppFolio conversation (PR 18417; finding: robot reads were never under the per-account request budget, this one is; AppFolio threads texts by phone across the whole company, so rows from other cards are dropped).

The overnight run (1,686 real cards, every customer plus both test properties, 727 model calls on the subscription, 2 h 54 min, zero sends, zero writes, all 19 planted-defect controls passed):

Check	Today's composer	Same cards, plus a staff-notes block
Private staff text copied into a draft	1 of 58 (two look like false alarms)	2 of 57
Another customer's data in the picture	0 of 1,679	0 of 66
Contradicts what staff already told the renter	36 of 73 (49%)	27 of 57 (47%)
Ignores a constraint the renter stated	100 of 462 (22%)	11 of 57 (19%)
Decision bank (reply / wait / skip, 34 scenarios)	28 pass, 5 miss, 1 judge error

Headline: when staff had already spoken to a renter, today's first message contradicts them about half the time. Northridge is the norm, not an outlier. Typical misses: "hope the tour went well" to someone who never toured; "that unit is no longer available" to a renter the team is moving in; re-asking what the renter already answered.

What it says about the fix: more context in the same composer does not help (47% vs 49%). The composer has no step that decides whether to write before it writes. The prototype decision step (reply / wait / skip from the picture) passed 28 of 34 scenarios on its first run. So the wiring order is: decision step first, then the composer reads the picture, then the follow-up check.

Not done tonight: no AppFolio notes were read; the robot runner token is not configured in the harness environment, so all 491 customer cards ran on our own records only. The true contradiction rate is likely higher. Monday: run the enriched pass inside the AppFolio read window with the runner token. Full numbers and the five worst examples (masked): vision-2026-10/research/card-context/harness/report-all.md on the Mac mini.

Identity and notes, the precise version (Oct 8 evening)

Fede: "we need to go a little more precise and small"; "leaking internal information is the most dangerous part"; "any staff can type anything... it's their private system". Three small pieces, each proven before the next, none built yet.

1. Identity span: a PMS record attaches to a Clara person only by a hard key. This is what the code does for AppFolio today (PMS id, phone or email as claims; same full name at the same home is the one soft rule) and what every next PMS inherits. One narrow exception, Fede's go on Oct 8 at night after a test over 2,993 real cards: a lead that carries no phone and no email at all (a listing site's relay address) attaches on exact full name within 7 days of that person's last lead activity; placeholder names refused, two same-name people means no match. 7 days merged nobody wrongly in that data; 30 days would have merged three strangers.

PMS record ──matches a person only by──▶ PMS id, or phone, or email   (never by name alone)
no match   ──▶ new person marked "PMS-only, unconfirmed"
               the picture says "identity unconfirmed" ──▶ the check answers WAIT
               (no automatic text ever reaches an unconfirmed person)
wrong attach ─▶ needs an unmerge of two people: does not exist today; required before any new PMS feed

2. Notes: a classifier with the strictest default, built from a mined corpus. Not mined yet: 51 Western Slope lead cards from a Sep 19 read, and 5 resident households from today's canary. Step one is a read-only pull of lead-card notes and tour notes at Western Slope and Situs Group into local files (same caps and redaction gate as the resident pull), then a labeled set:

Bucket	Example	Clara may use it
private (default)	screening result, balance, "difficult", anything about a third party	never, not even to decide
operational	no-show, not interested, chose another home, staff already called	to decide stop / wait / send only
warm	has a dog, moving with family in March, wants a ground floor	later, for the writer, through the audience filter

The bar: zero planted private facts pass, measured on every run; proven on held-out notes before one note enters the picture. Replay note from today: the audience tag alone did not stop a leak (10 of 10 with the prompt line removed), so staff-only lines are dropped before the model sees them, never left to the prompt.

3. Yardi for Yale 25 Station, prototype only. No API until the partner program clears, so the MVP reads as a user: a second robot with the same contract as the AppFolio one (one shared token, read-only pages to JSON, local dumps), and the same "visit the inbox, pull what is new since the cursor, drop our own echoes" job shape the AppFolio staff-text feed already uses. Reads in scope: inbox messages, leads and lead status, applications, calendar availability. Nothing touches a Clara record until pieces 1 and 2 are proven on the dumps; no writes, no calendar changes, nothing in production. Today the PMS layer knows Yardi as a registry name and a scrubbed Yale rent roll only.

The phone line, same shape

A call that Clara hands to a person is the voice version of a message leaving through the door. Today it runs on three dial paths, about ten hand-written "who do we ring" lookups and eight "did a person pick up" checks (read-only on production, Oct 8, by the phone-routing lane). The design puts it on the same four pieces as text and email.

Piece	Text and email	A call handed to a person
Read first	the shared reader (decision 1)	the same reader, called by the connect step instead of its own caller lookups
Who to reach	the thread's own people	Gera's shared lookup, nearest set level wins; today only the office-hours check uses it
The door	Gera's send gate: consent, module, Supervised, approval, plus the new stop / wait / send question	one connect step on every phone agent, replacing three dial paths; caller ID is a fact set per destination, never inferred; every transfer gets one verdict (person, screening robot, voicemail, no answer) and each destination shows its last results on the settings page. Joanna's phone screened transfers for two weeks while the log said "connected"; the verdict is what makes that visible within a day
After	the message on the thread	one note path from the transcript, one notice to the client's inbox, a nightly check that every call ended with a person or a delivered note
Policy as data	company and property settings	every destination per call type at property, group or company, with a stated answer for "empty"; the settings the customer sees are the settings the engine reads (today the Calls & messages page shows "Talk to a person: Not set" at Camellia while the engine rings Joanna from a row the page does not show); the table lives on the phone page

Owner and proofs: the phone line and hand-off page (routing onto the shared lookup and the screening fix passed their replays on Oct 8; the notes rewrite has not). This page holds the decision only, as 4b above.

Clara as a coworker on the phone: Clara as a coworker on every channel (proposed Oct 9, pending Fede's yes)

Lane 14. Execution rows on the tracker, Area 6. This replaces the Oct 9 morning draft; Fede's direction that afternoon: one core brain that recognizes staff on every channel, the same lookups and actions behind each channel with per-channel overrides, access to the whole company with the caller's role known; for the phone, a new ElevenLabs agent, an architecture diagram, the triage changes, and a prototype today.

What really happened

Jay, Western Slope's admin, Oct 8 at 5:11 PM, 105 seconds. Clara knew his first name from a test call he made as a renter in September, so she never looked further. Redacted excerpt:

0:16 Jay	"I am hoping that you can tell me what's going on with one of our guest cards since I cannot currently log in to our dashboard."
0:24 Clara (front door)	"Let me look into that for you." (hands him to the leasing agent, as a prospect)
0:27 Clara (leasing)	"It sounds like you may be with the property management team rather than calling as a renter. The team is closed right now… I can take a message."
0:44 Jay	"Actually, Clara, I am part of the property management team. It's Jay, the property manager, and I noticed that we have three active guest cards for a lead… Maybe you can tell me."
1:11 Clara (leasing)	"I don't have access to guest card records or your dashboard. I can only help with leasing inquiries from prospective renters."
1:29 Jay	"That was a helpful answer. Not what I was looking for, but a good way of explaining it and redirecting."

No lookup ran, no message was saved, and the call was graded "success, transferred to PM" by the voice vendor. By text, the same question is wired to the guest-card lookup for an admin. The other real staff ask (a Camellia regional manager, Oct 6, "speak to management") hit an empty catch-all and she hung up. Every other staff-looking call in the window was role-play or a test.

By text, the last 60 days (read from the production records Oct 9). Staff wrote Clara 45 times across every customer; two people wrote 42 of them. Of Western Slope's 37 texts, 31 answered something Clara had just asked (how was the tour, which card, the lockbox code); only 6 began with the staff member (book a showing, "has X confirmed?", a tour note). Nobody has yet asked by text the questions Jay asked by phone. Every text got a reply, median 13 s. Of 18 gradable asks, 10 went clean, 4 were fixed by our team by hand (3 to 97 minutes later), 4 were flawed; all four hand-fixed patterns are fixed on main since. Staff who email get no desk at all, and the two JP&Co asks by email (a calendar date, a deposit refund) still have no tool.

The team, Oct 8 evening (chat). Sean: "what if Clara recognized that it's Jay from the property management company from his number… she's like an employee that works for him… he just has a different role." Fede: "what's missing is feature parity between channels for Clara as a coworker… someone like Jay should be able to email, text, call or video Clara and ask any question or take any action… employee recognition should take priority over a test lead." In the meeting: keep the menu for the Western Slope launch, try the open greeting later, Camellia first.

One brain, five doors

The identity rule

Rule. Who the person is and their role in this company is decided once, at the door, from the number or the sign-in, fenced to the line's company. A staff match beats every other record: a prospect card, a test lead, a vendor row. Nothing is looked up mid-call. Recognition is a fix with no switch: it is what text already does, and the phone is simply wrong. Caller ID can be spoofed: the walk already trusts it for managers, so questions by phone add no new exposure beyond staff-only facts flowing to whoever presents the number; actions by phone (phase 2) need a second factor, a call back to the number on file or a spoken code.

Channel	Today	Proposed
Phone	ring step sets one flag, "property manager" (5 manager-type roles, built for the walk); the "who is this" step checks tenant, prospect, vendor, never staff	ring step runs the same company-fenced staff lookup text uses and sets staff_is_staff, staff_first_name, staff_role; the manager flag stays as the walk sub-case; the "who is this" step never runs for staff
Text	sender's number → person → roles, staff first	unchanged; the one lookup both share
Email	staff recognised, desk off (a From line can be forged)	questions on, actions off (decision 3)
Chat	signed-in account	unchanged
Video	signed-in start pins the company; role re-checked each turn	unchanged; the phone copies its fail-closed pin

Checked Oct 9 on the production records: Jay's number sits on three person records (his staff record, a role-less stub from a September call, and a vendor contact at another company); the company-fenced lookup returns his Western Slope admin record. Two Western Slope leasing agents resolve the same way. One Western Slope admin and three other customer staff have no phone on file and would still be strangers (readiness row 38). The unfenced lookup must never be used here: it returns the first company found.

What each role sees and does

Role	Sees	Does by voice, phase 2	Today
Admin / owner	the whole company: every building, every number	everything a desk can do, plus the day's summary	every staff kind gets the same tools; text flattens the tiers to one; accounting was ruled read-only on Sep 13 but the matrix still lets it write; voice applies no role gate at all
Property manager, assistant, regional	their buildings (all, when assigned "all")	desk actions, work orders, the move-out walk (today's only voice path)
Leasing agent, leasing assistant	leads, tours, cards, renewals, listings for their buildings	notes, tours, cards, lockbox codes, guest cards
Maintenance	work orders, vendors, appliances, access notes	open and update a work order, call a vendor back
Accounting	balances, ledgers, reports	nothing; reads only

Open with Gera: his portfolio page says roles route work and do not restrict ordinary in-scope reads and edits; Fede wants access scoped by role on voice. Phase 3 settles it in one role catalogue; phases 0 to 2 only need "staff or not" plus the company and building fence, which both agree on. Also on the roster today: Western Slope's maintenance manager and its virtual assistant are both recorded as leasing agents, so any routing by role would send maintenance to the wrong desk until the roster is corrected (readiness row 38).

Fig. 2. The phone: a new ElevenLabs agent whose brain is ours

Piece	Where it lives	New or reused
Staff lookup at ring time	the personalization webhook, next to today's manager check	reused: the company-fenced staff resolver text uses
Call binding	no table row: the vendor's conversation id and the caller's number ride as request headers on every custom-LLM request (proven on four real bench calls Oct 9), and the ring-time webhook can add company, person and role as the extra body	new wiring only; fail closed like video (no binding, no answer)
The coworker agent	registry, create script, sync on merge, drift test, like the other twelve	new agent; its language model is a custom endpoint
The answer line	the video turn route, with channel "voice"	reused: company snapshot, read-only frame, actor by person, brevity eval
Transfer out to a person	not in the minimum slice (a coworker who wants a human hangs up and dials them)	later: the connect step, same as the front door

Verified Oct 9 in the vendor's API spec and on a live bench agent: the agent's language model is set to custom-llm with a custom_llm block (endpoint URL, model id, an API key stored as a vendor secret, request headers). The reply must be a streamed OpenAI-style completion, which our video route already emits (proven by three simulated calls). System tools (end_call and the like) arrive as function definitions. The extra body on each request is whatever our own ring-time webhook returns as custom_llm_extra_body (switched on per agent), so the binding travels inside the call and needs no table. Request headers set as dynamic variables (the vendor's conversation id, the caller's number, the called number, the call id) arrive on every real call; a text simulation sends none of them, and the double-brace string spelling is sent literally. One hard number: cascade_timeout_seconds defaults to 4 s (range 2 to 15), so the first streamed word must land inside it, which means the answer line speaks a filler that names the thing within a second when a lookup will take longer. The measured request carries messages, model, max_tokens, stream, temperature and the tools; nothing else.

The coworker prompt is the staff hat, spoken

It is not a thirteenth specialist prompt written from scratch. The engine already composes the staff hat for texts and video: who is asking, their role, the company snapshot, the lookups, the desk rules. Voice adds the spoken overrides video already has (lead with the fact, one number and one date, no lists, count first then offer the list, fillers that name the thing). What the hat must know is the job itself:

What a coworker asks about	Where the answer is
A lead: did they reply, did they tour, what does the card say, what did Clara send	person picture, cards, tours, the thread (reads live on text, chat and video)
Today: who is touring, what is on the calendar, who called, who is waiting on us	tours, calls, open asks; the "matter brief" (who, role, today, open asks, the tours board)
A home: available, price, listed, lockbox, specials, applications pending	units, listings, cards; application status lives in AppFolio (say so)
A resident: lease end, balance, who is behind, what they said last	tenants, leases, balances, delinquency report, the thread
Maintenance: open work orders, a ticket, the vendor, when they are coming	work orders, vendors, appliances, access notes
Renewals and turnovers: who is up, what was sent, the walk	renewals, turnovers; the walk stays its own agent
Actions (phase 2): add a note, book or move a tour, open a work order, text the lead, remember this	the desk handlers, read back first, then the yes

• Rules carried from the text desk's hard week. Kat never hears "I don't have a tool for that." When one reading remains, act; never make staff pick between two cards. Every number comes from a lookup or the snapshot; nothing estimated. Staff-only facts stay with staff. English. Two sentences, then stop.
• Rules from the phone. No narrated reasoning, no "let me check" twice; a filler names the thing ("pulling the Ember Lane card"). A number heard is read back once. A question about a person off the line gets the answer, not a transfer.
• Rules from the Camellia walk. The walk stays scripted and separate; the coworker is conversational. "Got it, one sec" in 35 of 41 walk calls is the sound to avoid.

How long the caller waits

Path	First word after the caller stops	Source
Phone today (vendor model, webhook tools)	1.8 to 2.3 s median; a tool call adds its round trip; the silent transfer 2 s median, 4 s p90	Aug and Sep measurements
Video on Tavus (our engine)	3.3 s first answer, 4.8 s p90; Tavus turn detection and waiting for the full reply cost 1.3 s of it	Oct 5, two calls
This design (our engine behind ElevenLabs)	about 1.9 s when the answer is in the snapshot (turn 0.3, hop 0.1, first words 1.2, voice 0.3); a live lookup adds 0.3 to 2 s	estimate; the bench prototype measures it

Phases and the minimum slice

Phase	What staff get	Minimum slice	Full	Switch	Proof before it counts
0 · Recognise	greeted by name, never treated as a renter; the walk unchanged	the fenced staff lookup at ring, three variables, the greeting; one PR, about 200 lines	same	none: a fix	planted-defect unit test, Jay's call replayed, a bench call, Willows
1 · Answer questions	ask anything about the company by phone	the coworker agent with our answer line as its brain, read-only, the snapshot and the 23 lookups, no transfer out	plus the per-call brain swap on the front door (no transfer seam) and the connect step to a person	Fede's call: none (precedent: the same reads on staff text, no switch) or a company setting	bench and Willows calls measured; the other-company fence test; the brevity eval on channel "voice"
2 · Act	notes, tours, lockbox codes, cards, work orders, "text the lead", "remember this"	notes and tours with a spoken read-back and a yes	the whole desk, built once for text, video and voice	company setting, default off; Fede turns it on	Willows, then a supervised week at one customer; a second factor for the caller before any write
3 · Roles	each role sees and does its own job, on every channel	admin, manager, leasing, maintenance, accounting as one catalogue feeding the capability gate	building-scoped staff, a person at two companies, the email desk for questions	none: correctness	two-companies-one-asks probe on every channel

Execution starts the weekend of Oct 11 on Fede's yes (no PR before the decision). Phase 0 and the Phase 1 agent are two to three PRs under 300 lines each; the binding row and the voice channel in the answer line are two more. Nothing turns on at a customer without his word.

The prototype, Oct 9

A throwaway voice agent on our bench line (named with the fastlane prefix, so the usual guards treat it as a bench clone; the isolation gate refuses any production agent or customer number), its language model pointed at a tunnel to this Mac, where the real video turn route runs against the Fairhaven test company with Fede on file as a leasing agent ("Fred"). The engine is untouched; the server reads the production table and may write only the call's own conversation rows (every other write is refused and logged). Deleted after, bench line restored. No customer line, no PR, no CI.

Results (Oct 9, by 11:45 AM). Live on the bench line since 11:12. Three simulated calls by the vendor's simulator, then four real phone calls placed by our robot caller into the bench line, two questions each. Every answer came from the Fairhaven data; the conversation id and the caller's number arrived as headers on every real call, so the answer line keyed each call's thread by the vendor's own id. Identity was pinned for the prototype: every caller is greeted as Fred and given his leasing-agent hat (the robot calls came from a renter test line and still got staff answers), so this proves the phase 1 answer path, not phase 0 recognition; the caller's number now arrives on every request, which makes phase 0 the next wire. Agent deleted and bench line restored after each try.

Real call	Agent settings	Wait for the first word, question 1 / question 2	What happened
1	vendor defaults (eager turn-taking)	5.2 s / 2.2 s	the vendor sent question 1 twice (an interim transcript, then the final one); both ran in full on our side, one after the other, and the filler "Right, I see…" played at 4 s
2	speculative turns off	5.7 s / 2.4 s	same double send; the engine's second run waited on the first
3	same, abandon logging on	about 5 s / 2.2 s	the vendor never closes the first request, so the server must cancel it itself
4	patient turn-taking	4.0 s / 2.6 s	question 1 sent once; no filler; a mid-sentence pause ("Got it. Thanks.") still costs an empty engine run
5, Fede	patient turn-taking, 109 s, seven questions	4.0 s / 2.2 s; later answers 1.9 to 2.2 s, two slow ones at 4.2 and 4.5 s	vacancies (28, then the corrected 14 when asked to check), who is touring (none, three cancelled), the newest prospect (name, source, home, stage), weekend tours (none), maintenance headcount (nothing on file at the test company). The vendor filler ("Noted…", "I understand…") played before each answer slower than 4 s; the first answer was wrong (28) until pushed, which is the count-drift defect below. His first attempt at 3:02 PM reached another session's robot-test agent that had taken the bench line four minutes earlier; the line was rebound by hand.

Where question 1's 4 s goes (call 4)
Engine to first words (our side)	3.1 s on the first question of a call, 1.8 s on the second: the first turn pays the thread and prompt set-up
Tunnel, vendor, voice	about 0.9 s
Vendor-side first token in simulations	1.6 to 2.6 s warm, 3.5 s cold

What this settles for the build: turn-taking on the coworker agent is "patient"; the answer line cancels an in-flight run when the same call sends a newer request, and never persists an interim turn; the first question of a call needs the thread and the staff hat prepared at ring time (the personalization webhook already runs then), which takes the first turn down toward the second-turn 1.8 s; the 4 s cascade timeout stays above every measured first token except a cold cache, so the answer line speaks a short filler by 1 s when a lookup is slow. The vendor's own filler phrasing ("Right, I see…", "I hear you…") is replaced by Clara's. One defect found: the same engine, same data and same question gave 28 vacant homes on three calls and 14 on one. The read-only count says 14 is right: the test company stores the same 14 homes under two properties, and three of four calls counted the records, not the homes. Counts must not drift between calls: counts and lists come from a deterministic lookup that dedupes by address, the snapshot is context only. The read-only count against the tables is in the hidden section below.

Decisions

Question	Options
1. The phone design?	(a) A new coworker agent reached by transfer, whose brain is our answer line (recommended; it is the video work reused, and the one-brain rule kept). (b) The agent carries its own webhook tools over the same handlers (how every specialist works; a second prompt family). (c) Only the recognition fix for now.
2. Questions by phone need a switch?	(a) No switch: read-only answers to verified staff, like the same reads on staff text (recommended). (b) A company setting, default off, proven at Willows first.
3. Staff by email?	(a) Stays off. (b) On for questions, actions off (recommended). (c) Same as text.

Decided already, by Fede's words on Oct 9: a coworker is looked at first on every channel; no big refactor; the walk stays. Actions by voice are a new capability and ship behind a company setting, default off, in phase 2.

Two hard rules (Fede, Oct 9: "the most important thing in this design")

Rule	How it is enforced	Proof (planted defect turns the test red)
Nobody who is not staff can reach the coworker agent, and nobody can talk their way in	The decision comes from the caller's phone number matched against staff records; nothing the caller says plays any part. Two independent checks: the leasing agent gets the handoff instruction only when our call-start answer says staff, and the coworker brain re-checks the caller number on every request. A non-staff caller hears "this line is for staff" and the call ends; no company data is loaded before the check passes. Caller-ID spoofing is the residual risk, so V1 is read-only and any action needs a second factor.	a prospect who says "I'm the property manager" is refused; a caller with no staff match is refused; remove the per-request check and the tests go red
Never across customers: each customer gets only its own context, and no trick or accident leaks another customer's data	The company comes from the number that was called, never from the caller. The caller must be staff at that exact company; staff at two companies get only the called company's context. Every lookup runs scoped to that company id, as the video coworker already does: one company, read-only.	staff of company B calling company A's line is refused; swap the fence to the caller's company and the test goes red; a coworker row in the isolation gauntlet fails if an answer carries another company's data

Rollout, decided Oct 9 (Fede: "go ahead and build it… test it in production first… just one switch that we can retire later")

The new piece lives beside the existing lines. The only change to an existing line is one handoff rule that stays dormant unless the company's switch is on. The switch is a plain company record set by script, off everywhere, no page, no UI (Fede: "I don't need to show anything on the company page"); it is deleted at step 4.

Step	What ships	Customer lines touched	Proof
1	The coworker agent, standalone: a new ElevenLabs agent whose brain is the answer line, in production, bound to our bench number. Callers are matched by phone to the test company's staff; anyone else hears that the line is for staff.	none; no existing agent changes	unit tests with a planted defect; real calls from our own numbers; robot callers as prospect, tenant, unknown get the staff-only answer
2	The switch and the handoff: company setting "staff by phone", default off. The existing leasing agents get one transfer rule: recognised staff at a company with the switch on go to the coworker agent.	none while off	replay of every customer's recent real call-start payloads, byte-identical where the switch is off; robot callers on the test line unchanged; a robot staff call transfers
3	On at one sandbox company in production (centralised-leasing shape, staff numbers are ours). A supervised week.	the sandbox company only	every call reviewed; count defect fixed and shown; first-word timings per call
4	Retire: recognition is the only code path, the setting row is deleted.	all, on Fede's go	dark-features register closes the row

One shared leasing agent serves every customer (Fede, Oct 9: "one agent for everyone"), so the handoff is not configured per company. The flag is read once, by our app at call start; the handoff instruction is sent in the call-start answer only when the flag is on, and the shared prompt never carries it. For every company with the flag off the call-start answer is byte-identical to today, and that is what the replay proves.

Why a sandbox company and not Willows: Willows sits inside JP&Co and staff belong to the company, so a switch there would also recognise JP&Co staff on the Camellia line. Turning on at the sandbox company, and later at any customer, is Fede's call.

Deep inspection of the original turnover work (Oct 9, read-only map of the code at commit 4392d05)

The finding in one line. "Who is this staff person?" is answered in five separate places, each with its own rules, and the turnover walk is its own phone agent with its own prompt rules, variables and sync, bolted onto the shared leasing agents. Clara as a coworker on the phone replaces the bolt-on; the five loops become one.

Place that recognises staff today	Who it counts as staff	Company fence	After the cleanup
Voice, at ring time and again at tool time (the "PM call context")	five manager-type roles only; org admins, maintenance and leasing agents are not staff	yes, the dialled company and building	one staff lookup, the one text already uses, with the called company as a required fence; voice, video, the turnover binding and the tool guard all call it. Staff = any active staff role at that company. What they may do comes from the role catalogue (phase 3), not from which loop found them.
Text and email (the staff lookup)	all eight staff tiers	optional
Text turnover binding	manager-type roles, its own copy of the loop	none
Turnover tool guard (falls back to the text lookup even on voice)	manager-type roles	none
Video Clara (its own copy)	active staff role	one company

Turnover-specific thing on the shared phone path	Where	Verdict
The Turnover Intake voice agent, reached only by a transfer from the leasing agent, with its own sync workflow outside the fleet sync	the eight-agent fleet; a Willows clone	retire once the coworker agent does the walk at the sandbox company (step 3); the walk becomes one capability of the coworker core, as it already is on text
Rules 1.7 and 5b in the leasing agent prompt (manager precedence, turnover and walk routing, "a purchase order" as a bare intent word) and the five pm_* / turnover_* variables sent on every call	the shared leasing (triage) prompt and the call-start webhook	replaced by the one handoff rule of step 2: a recognised staff caller goes to the coworker agent first; the leasing agent carries no staff material
Voice tool route still has handler cases for six turnover tools removed from voice in June; the text tool schema still lists a dropped tool	the voice tools route, the text turnover tool schema	delete now; dead code
The voice staff gate only ever protects turnover tools (the "staff infra equals turnover" coupling)	the role matrix predicate	goes away with the one lookup; coworker reads on voice are gated by role, not by tool family
Four turnover switches: a property flag, a two-factor sending arm, a workflow env flag unset in production, a cohort-walker env flag	property record, arm state, env	to the switch audit (Area 0, wave 2); the autonomous-sending arm is a real new-capability switch and stays until that decision; the env flags look fix-shaped
Vendor and purchase-order material (outbound vendor calling, handyman line, vendor callback recognition)	vendor-facing agents	leave; a different audience (vendors), not staff

Cleanup chain, in order. C1, a fix, no switch: one staff lookup with a required company fence, called from voice, video, the turnover binding and the tool guard; the existing fence tests and the harness isolation row stay green, the "manager-tier literal" drift test is updated to the new rule. C2, cleanup: the dead voice tool cases and the dropped schema entry. C1 and C2 can start now. C3 waits for step 3 of the rollout: retire the Turnover Intake agent, its sync workflow, the two prompt rules and the five variables, in that order, each a small PR. C4 is the switch audit entry. About 70 turnover unit tests, the fence tests and five fleet drift tests are the red surface; each PR names which it touches.

Full map with file and line for every item: research folder vision-2026-10/research/turnover-inspection/map.md on this Mac (also linked in the hidden agents section). Not verified live: ElevenLabs bindings and arm states were read from code and config, not from the vendor or the table.

What the past attempts teach

• Keep. The text-side staff lookup and its "staff first" rule; the four hand-fixed text failures of the last two weeks (which card, book it, back-to-back showing, lockbox then unit) stay fixed on the phone only because it runs the same handlers; the matter brief on every staff turn; the 23 reads with a per-call role check; the ring-time hook as the model for a staff flag; video's fail-closed company pin; one named person, their own work, real tools, a short text (the tour check-in text was answered 11 of 12 times, median 3 minutes).
• Do not repeat. Recognition bolted onto one workflow (the Camellia walk saw only property managers, only for the walk); word-list intent sorting (failed twice on the text desk); a wrapped dashboard persona; switches on fixes; tests with single-role fake actors; a shared inbox as the door (0 of 24 missed-call emails answered); building before the map.

For agents: paths and sources (hidden)

• Voice identity today: src/app/api/voice/personalization/route.ts (manager check ~:2142, dynamic vars ~:5027 with pm_is_pm ~:5504, config override ~:5002); src/lib/domain/turnover/pm-call-context.ts:126; src/lib/tools/handlers/handle-identify-caller.ts (no staff step). Text identity: src/lib/domain/staff/inbound-resolution.ts:261 (company-fenced), src/lib/domain/identity/resolve-actor.ts:244 (staff ≻ vendor ≻ tenant ≻ prospect).
• Front door prompt: agents/clara/lib/voice-agents/triage.ts (identity block ~:274, rule 1.7 :351, rule 5b :388, rule 6 :397), transfers in triage.config.json. Registry: agents/clara/lib/agent/specialists/registry.ts:78; create scripts scripts/create-*-voice-agent.ts; roster drift agents/clara/lib/agent/specialists/roster-reconcile.ts.
• The answer line: src/app/api/video-turn/chat/completions/handler.ts (fast route) and src/app/api/video-clara/llm/chat/completions/handler.ts (runVideoClaraTurn, deps at :151); actor src/lib/domain/video-clara/call-actor.ts:148; binding call-binding.ts:81; read-only gate agents/clara/lib/agent/capabilities/video-read-only-gate.ts:61; the local seam scripts/eval-video-brevity-subscription.ts:140-260. Capabilities: agents/clara/lib/agent/capabilities/index.ts (:341 metrics, :359 portfolio, :371 desk), staff-portfolio.ts (the 23 names).
• Builder notes from the prototype: the leasing-prompt fallback guard (#15322) is scoped to channel video and must cover voice; the answer line must abort an in-flight engine run when a newer request for the same conversation id arrives (the vendor keeps the old request open) and must not persist interim turns; coworker agent turn settings: turn_eagerness: patient, speculative_turn: false, soft-timeout filler text ours; custom-LLM request_headers use { variable_name: "system__conversation_id" } (the {{…}} string form is sent literally); set platform_settings.overrides.custom_llm_extra_body: true when the webhook returns a binding. Data check of the two vacancy answers (read-only count, Oct 9 11:35 AM): 28 vacant unit records out of 89 across 11 properties, but the same 14 homes are stored twice (under the bench company line property and under fairhaven-homes), so 14 distinct vacant homes is the true answer and 28 was double counting; three tours dated today, all cancelled. Bench data hygiene: the duplicate property copy should go.
• Bench: line +17208071724 (Fairhaven Residential (TEST), org_53047a06-2c49-4231-92c2-6f2a7009149a, table propflow-prod); fastlane scripts/voice-fastlane/run.ts (:292 clone, :386 bind, :408 restore, :428 delete). Vendor docs: custom LLM and overrides pages on elevenlabs.io/docs (fetched Oct 9).
• Evidence: 841 of 842 inbound calls Sep 8 to Oct 9 read through the voice vendor's API (Jay's call conv_4701m4ewjgx1e6qaa5rych8b4tdd); team chat and meeting in #transcripts, thread 1791438554.256149 (chat) and 1791503556.027459 (meeting); the Oct 7 voice note 1791378613.845939. Past attempts: coworker by text, staff loop v2, video Clara, role-by-channel audit.

Rule. Every failure lands in exactly one of six places, and the fix is made there: a policy row was missing or wrong; the situation lacked a slot; a tool was missing or wrong; the model's judgment was wrong; the egress let something through; the model or effort was wrong for the job. Evals are invariants over the whole real corpus (nothing twice, no staff-only fact outside, no message while a human holds the thread, no deadline in any ask) plus consistency: the same case run several times must come out the same, which is τ-bench's pass^k and the number that separates a demo from a product. Every new capability runs Supervised on real traffic before Live. Prototypes and harnesses run locally on the subscription and ship their result as a page; they enter the repo only after the decision, as one small PR. The harness is written from the production distribution of intents, never from the diff.

Why this ends break-fix. Break-fix is what happens when each failure becomes a new code path. With six places to land and invariants that run over everything, a failure becomes a row, a slot, a tool, a case or a gate, and the same failure cannot come back silently. Hamel Husain's evals essay makes the same case: the product is the eval loop; the model is a component.

The models we run (inventory, Oct 8). Eighteen production call sites, six model ids, all set as code literals with two env overrides, none a customer setting (which is right).

Job	Model and effort today	Harness exists
core reply loop (voice, text, every channel but email and SMS drafting)	Sonnet 4.6, effort low, adaptive thinking; about 25 call sites inherit it	no end-to-end eval of the loop itself
voice agents, all eight (ElevenLabs)	Sonnet 4.6, set in the ElevenLabs config	listen-tests only
email and SMS drafting (reason first)	Sonnet 5, effort high, thinking on	yes (outreach, knowledge, fair housing, muted threads)
video Clara	Sonnet 5.5, thinking off	no
Ask Clara chat	Sonnet 5, effort low	benchmark gate, overridden
extraction (conditions, onboarding transcripts, access notes)	Sonnet 5 and 5.5; access notes on Sonnet 4.6	partly
judges (policy gate, conversation quality, work-order access, attribution, eval judge)	Haiku 4.5 and Sonnet 4.6	yes for the eval judge
fast paths (summaries, FAQ ask, quote parsing)	Haiku 4.5	no
maintenance manuals	a local Mistral, falling back to Haiku	no
declared, unused	Fable 5 as the "smart" tier	n/a

The finding. The loop we think of as "Sonnet 5.5 with medium or high thinking" is not what runs: email and text drafting run Sonnet 5 at high effort; voice and every other channel run Sonnet 4.6 at low effort, and all eight voice agents run the same Sonnet 4.6 (the effort is set in the loop, not in the voice config); the fast jobs run Haiku 4.5. The history explains it: the Jul 27 flip to Opus 5 was rolled back, the A/B that blamed the model was refuted as a configuration bug (parity at 20 of 21 once fixed), and the default never moved again. The lineup as of Oct 8: Sonnet 5.5 (default effort high, $2 and $10 per million tokens), Opus 5.5 (default medium, always thinks, $4 and $20), Haiku 5.5 (released Oct 7, $0.10 and $0.50), which Anthropic describes as built for "quick and repetitive workloads (like summaries, compactions, database queries, and classification requests)" and "speed-sensitive tasks like live customer support". Effort replaces token budgets: thinking is required at xhigh and max, can be turned off at high or below, and manual thinking budgets are not supported. Our loop already uses effort, so a swap is a model id and an effort value, proven on the job's harness.

Decision 9, the recommendation. One registry in code maps each job to a model and an effort, with its harness named beside it. Sonnet 5.5 at high effort is the loop default for drafting and decisions; it is enough, and Opus 5.5 at medium is tried only where consistency on judgment-heavy asks (typing an ask, resolving a policy conflict) measures better on pass^k. Haiku 5.5 is the candidate for summaries, extraction and categories, where the benchmark puts it at the noise floor; not for urgency or send/skip decisions, where it fell behind; for the voice turn only if a listen-test wins, since with thinking on it was slower than Sonnet 5.5 at low effort here and with thinking off it failed the control. Each swap is proven on the job's harness with the model held constant and the code fixed first, the lesson of the Opus 5 A/B; a swap ships live with no switch. The first live job to run is reason-first drafting, the one live Sonnet job with a harness. The jobs with no harness (the core loop, video, the fast paths) get one before they move.

The benchmark (Oct 8, local, subscription, read-only; two classification jobs, not the loop). Two local jobs with gold labels, each with a planted-violation control a model must pass before its score counts. The decider is the follow-up check from the follow-ups work, "is there anything that says do not send this follow-up?", on 226 gold-labeled Western Slope, JP&Co and synthetic leads with the step-1 inputs (the lead's Clara threads, tour rows, card status). The asks are the 205 real asks Clara sent to staff, typed by urgency and category; there is no human-labeled set yet, so the score is agreement with the Sonnet 5.5 default run, and the 46 Haiku-vs-Sonnet disagreements were read by this session, not a person. Not run: the core loop, email and text drafting, voice, video, the fast paths.

Model and setting	Decider: bad follow-ups caught (of 40)	Decider: good leads wrongly held (of 186)	Asks: urgency / category agreement with the Sonnet 5.5 default run	Decider seconds per call; list cost per ask
Sonnet 4.6, no thinking (today's loop model), 3 runs	30 to 31	18	not run	baseline
Sonnet 5.5, adaptive thinking, effort low, 3 runs	30 to 31	13 to 14	85% / 98%, Sonnet 5.5 against itself: about 15% of urgency labels move between settings, the noise floor of the four-label rules	2.2 s; about $0.005
Sonnet 5.5, no thinking, 1 run	28	11	82% / 96%	2.1 s
Haiku 5.5, adaptive thinking, effort low, 3 runs	26 to 27	11 to 14	78% / 95%: categories at the noise floor; on urgency it pages more (120 urgent vs 102) and invented two emergencies	3.9 s; about $0.0004
Haiku 5.5, no thinking	fails the clean-lead control on this decider (void)		70% / 94%	0.8 s
Live drafting evals: Sonnet 5.5 vs today's Sonnet 5, both effort high	leasing drafts 27 vs 28 of 31 pass; renewals 19 of 19 both		not run	3.8 s vs 4.5 s per draft
Haiku 4.5, no thinking (today's fast model)	fails the same control on this decider (void)		67% / 95%	1.4 s; about $0.002

• Sonnet 5.5 clears Sonnet 4.6 at matched low effort on a decision job. Same catches, far fewer good leads wrongly held (13 to 14 vs 18), fewer tricky leads held (9 to 10 vs 13), and steadier: 2 of 226 decisions flip across three runs, against 5 for Sonnet 4.6. It stops holding quiet leads 4.6 held after an unanswered application link or tour offer; its one loss shape is a toured lead "thinking it over". The loop question is the model, not the effort: low already clears 4.6, and the loop keeps medium or high.
• Haiku 5.5 is not a drop-in for decisions. With thinking it catches four fewer bad follow-ups than Sonnet 5.5, flips 10 of 226 decisions across three runs, and its misses cluster on the Western Slope toured-lead shape (toured, then "come see it"), the case this check exists for. Without thinking it cannot say "send" on a clean lead; neither can Haiku 4.5.
• Haiku 5.5 earns its place on categories, extraction and summaries. Categories agree 95 to 98% on every model. On urgency it is no less accurate than Sonnet 5.5 across the 46 labels they disagree on (13 to 12, with 21 the rules cannot settle), but it leans to paging. At list price it is 12x cheaper than Sonnet 5.5 and 5x cheaper than Haiku 4.5.
• Voice latency is not a free win. With thinking on, Haiku 5.5 at low effort was slower than Sonnet 5.5 at low effort here, because it thinks about three times the tokens; with thinking off it fails the control. The listen-test decides, not this table.
• Two findings are about our rules, not the models. The labeler was given notices as well as asks: tour heads-up texts to the host made 21 of the 46 disagreements, and a notice is never an ask (Fede, Oct 8: a tour confirmation is a notification; the level is for messages left on the line and the like; one general framework, leasing first). So the first rule is scope: only a real ask gets a level. The second: a prospect writing again on a thread the team holds is urgent on every model that got it right.
• Nothing live changes yet. No live job we would swap has been run. The one live Sonnet job with a harness is reason-first drafting (Sonnet 5 at high); its Sonnet 5.5 run came back level: 27 vs 28 of 31 leasing drafts pass the judge, 19 of 19 renewals pass on both, and 5.5 is about 15% faster. Its one real miss named a unit number the prospect had not asked for. Parity on 31 cases is not a swap decision; the full 120-row suite and the fair-housing and muted-thread suites run before drafting moves.

Sized Oct 8, zero new requests. The September Western Slope pull, redacted on the Mac with a leak check that passed (a planted name, phone and email made it abort, as it should), covers 85 households: a typical one already holds about 60 texts, emails and notes (14 texts from the resident, 23 from staff, 19 emails, 1 note) plus 23 change-history entries; 93% have some history and 69% texted in the last 90 days. That is the picture Clara joins today without it. The live one-building read (Pomona Park, 37 households) needs one small read-only robot route first; it is row 18 on the tracker.

Resident-history pull: production run numbers (Oct 8)

Two small read-only canary runs on Western Slope's AppFolio, same afternoon. Neither stop rule fired, and nothing was written back. This is a canary, not the full building pull.

Measure	Result
Account-wide inbox read (3:35 PM Mountain)	1 call, 40 conversations, 20 requests of the 320 hard stop
Household read (3:03 PM Mountain)	5 households, 36 requests, about 7 each against a budget of about 8
Replay set built from both	117 conversations, 6,177 messages: 3,807 texts, 2,197 emails, 173 notes; 85 households plus 32 inbox-only
Leak check	GREEN, and every planted leak made it go red

Rule. Clara is never first. Before she sends a word, the customer's PMS and mailbox already hold years of the relationship: notes, staff texts and calls, showings, applications, work orders, payments, notices, and for residents the whole tenancy. That history is part of the situation from day one. PMS-side conversations are channels: Clara reads them and, under the same egress, can answer in them. The anonymized history becomes the permanent replay corpus, so evals are built on real traffic from the start instead of waiting for Clara's own volume to grow. A platform that assumes every relationship starts at its first message is a chatbot bolted onto a system of record; this one is meant to run the system of work on top of it.

What we hold today (inventory, Oct 8, read-only).

Source	Held in Clara	Not pulled
guest cards	mirrored every 15 minutes: Western Slope 1,085, JP&Co 73, Situs 1,135; status, source, assigned user, inquiries; Situs stale since Sep 29	the actions log: staff texts and calls, notes, showings scheduled and occurred, status changes; read by the robot for one check, persisted nowhere
rental applications	mirrored: status, group id, source	the person link (null on every row)
work orders	schema and an enrichment job; zero runs in the last 24 hours; a manual sync button	the resident's messages on the work order
resident messages in the PMS	nothing	everything: maintenance, payments, notices, questions, for every resident at both centralized customers
tours and showings	Clara's tours; her bookings written to AppFolio	staff-run showings; AppFolio's own "showing occurred"
the mailbox	replies on threads Clara already has	the mailbox's history with a person before Clara; staff mail to a lead with no Clara thread

How much this matters: on a snapshot of 51 Western Slope cards, staff had sent 278 texts (256 by a person), received 192, logged 19 calls and written 86 notes on 41 cards; 43 of 51 cards had staff-initiated contact. A follow-up decided without that history is blind to most of what the customer did, which is the exact shape of the Oct 6 bad text. Clara follows up today without the full context, and this is the measurement of it.

How the history gets in. AppFolio's partner API (Stack, read-only) covers properties, units, tenants, work orders, vendors, bills, charges and attachments at about 120 requests a minute per key; communications, activity notes and guest cards are not in it, so they come by budgeted robot reads or exports, under the rate limits Situs already tripped. Yardi and Entrata are the same pattern with different doors; the history slot in the situation is the same. The mailbox side is a per-person backfill from the connected mailbox, the slot the Graph sync already writes to for replies. Nothing here needs a new login flow or a new switch; the feed and the importer exist and are off.

Two uses of the corpus, two rules. Anonymized replays and evals follow the existing redaction pattern (the identity map stays local, the corpus goes to the training bucket) and need no permission we do not have. Training or fine-tuning a model on customer conversations is a different line: the customer contract and AppFolio's partner data terms, which are not published, get checked first. That is a Fede and legal question, in one sentence, not an engineering slice. Evals do not wait on it.

Resident services (decision 8). The module exists for balances, payments, maintenance intake and basic information, built first for Camellia, and is partly off. State per customer, from the switch audit (values from the Sep 30 and Oct 5 audits, not re-read; "unknown" where no audit had a value):

Resident-facing switch	JP&Co / Camellia	Western Slope	Situs
module modes (gatekeeper)	all seven on	leasing on; renewals, maintenance, collections off	all off
collections and lease billing	collections default on	off	off
rent-roll data (fix-shaped, bucket C)	on at 1 of 2 homes	off	off
payments	no switch of its own anywhere; answered by the loop wherever the module is on
voice callback (bucket A) / fair-housing voice alert (bucket B)	on / off	on / off	on / off
resident call routing v2, human handoff by text	off	off	off
maintenance updates by email, vendor job reference (added in Oct)	unknown	unknown	unknown
hidden handoff mode	per customer unknown; platform-wide 7 properties autonomous, 3 coworker, 224 unset (unset means autonomous)

Why it "sometimes hits", our reading of the audit (the audit reports the states, not the cause): there is no single resident-services switch. Whoever reaches a live line gets the one reply loop, and at JP&Co every module is on, so a resident question is answered there and not at the two centralized customers. Recommendation: Off everywhere except the emergency path, which always goes out, until the resident's PMS history is in the situation; then Supervised at one building as matter types on the one loop (Pillar 6), not as a separate phone agent. The information it is good at (a balance, a due date, office hours, how to submit a request) is exactly what the PMS record and the policy rows answer without judgment, so it is the first resident matter to prove.

Proof. Done: the inventory above. Next, local: re-decide the 16 bad follow-up texts with the card history in the picture (expected: the 17 "should send" cases with prior staff activity come out STOP or WAIT); one budgeted robot pull of one building's resident message history, redacted, to size the resident corpus and the emergency level that leasing traffic cannot prove.

Anonymized history: the permanent replay corpus (Oct 9)

What it is. A standing set of 117 real Western Slope resident conversations, 6,177 messages (3,807 texts, 2,197 emails, 173 staff notes), for replaying how Clara would handle a resident message. It merges the 85 households from the Sep 7 dump with the 40 conversations from the Oct 8 inbox pull (32 stand alone; 7 merged into a household).

How it was anonymized. Names, phones, emails, addresses, units and property names are replaced; dates are shifted by whole weeks (1,582 days). Wording stays real. A leak check runs on the final file (GREEN), and a planted-leak control turned it red for each mapped name, phone and email. Known gap: an unmapped invented name stays invisible to a map-based check.

What Clara should do (40 labeled conversations)	Count
Escalate to staff	19
Acknowledge and log	8
No reply needed	6
Check the account, then reply	3
Answer from knowledge	2
Schedule a visit or tour	1
Send a form or link	1

Topics: leasing 14, move-in/out 8, lease 7, other 5, maintenance 3, parking/pets/rules 2, payment 1. Labels are one model's opinion (Sonnet 5.5), a seed and not ground truth.

Where it lives. Only on the Mac mini, in research/history-replay-set, folder mode 0700. It is not in any repo, bucket or Slack, because it derives from customer data. What it is for: replay and evals only. Not for training, sharing or real-person outreach until the AppFolio partner-terms check is done. Thin spots: only 10 of the 40 inbox threads are complete, and most inbox conversations are leasing, not residents.

The PMS robot core layer: what is shared, what every vendor still rewrites (Oct 8)

Fede's rule: no PMS reinvents login, how to pull, how often, or the safety caps. Gera split the robot on Oct 6 (six PRs, issue 469 in the robot repo): a vendor-driver interface, a registry, and AppFolio as the only driver so far. Where that leaves each concern:

Concern	Today
Login and MFA	AppFolio code; only the code parser sits behind the driver
Session jar and 2-minute keepalive	Shared code, keyed appfolio: in storage; the heartbeat imports AppFolio directly
Request pacing (2 in flight, 250 ms apart, 30 s cool-down after three 429s) and login budget	Shared code, AppFolio-keyed
Per-account request budget	Does not exist
Sign-in redirect detection	Generic, patterns come from the driver
The 503 "no session" guard	Only on the resident-history route
Service token and account-scoped routes	Generic
How often to pull	Not in the robot at all; the app's sync Lambda owns cadence (1 min, 5 min, 1 hour classes)

To finish the layer (small, mechanical, not tonight):

• Vendor-neutral storage keys.
• Heartbeat goes through the driver.
• The 503 guard and a per-account budget move into the shared client.
• A pull-cadence contract per vendor, owned by the Lambda.
• A conformance test every new driver must pass.

Nothing here builds until the context MVP has its number.

The vision is for the whole industry, so the jobs are checked against what public surveys and law say about an ordinary week, not against one customer. Numbers below are as published; the source is named on each.

What the data says	Source	What it means for Clara
Colorado law: answer a habitability notice within 24 h; start repairs within 24 h when life, health or safety is at stake, within 96 h otherwise	Colorado warranty of habitability, 2024 summary (Snell & Wilmer)	"emergency" is a legal category with a clock, not a judgment call; the customer's own list (habitability, property damage) plus the caller's claim decides it
Hot water and heat: 24 to 72 h in most states; Texas "reasonable time", Florida 7 days by statute	Steadily, 2024 state survey	the emergency list is per state and per customer; it is a setting Clara reads, never a rule in code
Tax-credit (LIHTC) housing: 97% occupied, 16.9% of properties on a watch list, nearly a quarter not breaking even	CohnReznick 2024 via Propmodo	in affordable housing the work is retention, recertification and arrears, not lead response; leasing is the smallest job
At some affordable communities English is not the first language for over half of residents	Multi-Housing News, 2024	every channel in the resident's language, team-facing text in English (ruling of Sep 3), and voice carries the same rule
Three or more software logins a day for 60% of managers	NAA + AppFolio benchmark, 2024	Clara works inside the PMS the team already has; a new screen is a cost, not a feature
After hours: 43% of real maintenance emergencies and 28% of requests arrive outside business hours; 23% of calls go unanswered in hours	AgentZap blog, 2025 (vendor figures, primary survey not found)	the loop runs the same at 2 AM; the only thing that changes after hours is which door the urgent item takes

What this changes in the page. The routine three quarters of communication is Clara's job in every team shape. Turnover of a third to a half a year means knowledge cannot live in a person's head or inbox; it lives with Clara and survives the person. In affordable and class C housing the daily work is arrears, recertification, inspections and language, so "leasing first" is our sequencing, not the industry's. Gap: no credible first-person day-in-the-life accounts for class C operators were found in public sources; the closest evidence we hold is our own corpus of 1,353 conversations at three customers, and nothing on this page should be read as more than that until a fourth and fifth customer of a different shape are live.

Attempt	What it fixed	What it did not
Email every ask to the inbox	nothing lost in code	nobody answers a shared inbox: 0 of 24 missed-call emails
One note per person per day	repeats	the ask still went by email; no deadline, no second person
Text the host after a tour	Clara learns within minutes	status texts with no question got 2 of 10 replies
One engine with a 6 PM roll-up	silent stalls, double sends	urgency; a timer nobody reads; keyword topics split one ask in two

Fede's question: we over-escalate, but the customer did engage. What is the balance? The Opus review classified all 88 staff-facing items one by one.

Of 79 readable items	Count	Answered	Should become
NOW: someone waiting, safety, same-day access	4	1	an urgent item: top of the inbox plus a text to the named role
ASK: a real decision that can wait hours	11	4	a normal item with its category, matched person and transcript
CHECK-IN: Clara asks the host for tour notes	12	11	keep
FYI, ticket, repeat, thank-you	52	2	a record on the card, shown in the inbox as "record", never a ping

Two thirds should never interrupt anyone. The four that mattered most were the ones lost: three of four NOW items went unanswered, all by email (a police call, a move-in-day key, a tour-day "please greet them").

One worked example of a day of asks, before and after, sits on the data appendix. The aggregate above is the evidence; the example only illustrates it.