Voice agent architecture — how Clara's phone answering should be shaped

P1 — One shared set of agents; every client difference is data sent at ring time what we run today

What it is. The ~11 agents we have now, serving every client. Each call is personalized in the split second the phone rings: which building, its hours, its policies, who is calling.

Strongest case. It is not a design, it is a description — Camellia and Yale run it. Zero migration. Zero new maintenance. Every voice vendor's own documentation recommends exactly this and warns against copying agents per customer. It is also the only option that leans on no unbuilt platform work.

The killer objection. VERIFIED It cannot serve a centralized client at all — not slowly, at all. Point the shared line at one nominal building and every resident of the other buildings is silently treated as a stranger, because our code drops a caller's tenant record when it disagrees with the building the number maps to. Leave the number unmapped instead and the call adopts the caller's building — which is a leak we already have filed and are trying to close.

Scores — scale 2 · maintenance burden 5 · isolation 3 · time to first centralized client 1 · migrating Camellia/Yale 5 · reliance on unbuilt work 5 · vendor lock-in 4

P2 — Same agents, plus one new state: "I don't know which building yet" recommended target

What it is. P1 with one addition. A number can point at a company. When it does, the front-door agent holds an unresolved building, asks which one, and stamps the answer onto the call. Every specialist and every tool afterwards reads that stamp.

Strongest case. VERIFIED The stamping machinery already exists and already runs — a call that does not yet know its building gets one filled in mid-call, and then it is locked and cannot be moved. The safest class of our tools already re-reads it fresh on every single tool call. Gera specified the same design independently from the data side, months before this review. And it turns a filed leak into a designed branch.

The killer objection. VERIFIED It must deliberately re-open the exact gate that a real incident closed nine days ago. On 2026-08-26 a Yale caller was answered as somebody else, because a person who rents at both Camellia and Yale was matched to whichever tenancy came back first. The fix was to lock identity to one building. P2 widens that lock from "one building" to "the buildings in this company" — the precise inverse — and the nearest surviving guard only compares the person, so it cannot tell the two leases apart. ARGUED Also unproven: whether the facts we hand the agent at ring time survive a hand-off to a specialist. Our own design note admits it inferred this rather than testing it, in a document that already contains one wrong assumption of the same kind.

Scores — scale 4 · maintenance burden 4 · isolation 2 · time to first centralized client 2 · migrating Camellia/Yale 5 · reliance on unbuilt work 1 · vendor lock-in 2

P3 — Two families of agents: one for staffed single buildings, one for centralized operators

What it is. Fork the agents in two. On-site clients get one family; centralized clients get another, with its own greeting, its own turn-taking, its own tool set.

Strongest case. The two really do have different jobs. A company greeting with a routing question is a different speech act from a building greeting. A front door that must hold "not known yet" across turns and one that knows at ring are genuinely different shapes, with different speed budgets. And tonight's Western Slope prototype is already, accidentally, family number two.

The killer objection. VERIFIED Situs is in both families on day one — one central maintenance line, ~30 buildings that each need their own leasing identity. The split is not a property of the client; it is a property of each phone number, which is a three-valued field, not a code fork. And the cost lands on the one thing already failing: on 2026-09-03 five of our seven live prompts were running thousands of characters behind the code, with every test green. P3 doubles that surface. VERIFIED The promise that a shared core would be rendered into both families is already false — the prototype shares one of five common blocks and about 1–2% of its text.

Scores — scale 2 · maintenance burden 1 · isolation 2 · time to first centralized client 3 · migrating Camellia/Yale 4 · reliance on unbuilt work 1 · vendor lock-in 2

P4 — A private copy of the whole agent set for each client company

What it is. What we do for the Willows test property, done for every customer: their own copies of the eight or eleven agents.

Strongest case. Blast radius, and it is real. A bad prompt on a shared set is a thirty-client incident; on a private copy it is one client's problem. Per-client voice, language mix and rollback become plain configuration. And it costs nothing extra at ElevenLabs — their pricing has no per-agent line, so 240 agents cost what one costs. If a large manager ever contractually demands isolation, this is the answer that sounds true.

The killer objection. VERIFIED The isolation is cosmetic where it matters: all 240 copies call the same server code with the same scoping, so a data leak leaks identically. It reverses a written standing rule, it needs cloning tooling that does not exist (our one existing copy cannot even be rebuilt from the repo), and the copy multiplier lands on 45–85 prompt changes a month. And it does not answer Western Slope's phone: a copied agent still resolves a number to exactly one building.

Scores — scale 2 · maintenance burden 1 · isolation 3 · time to first centralized client 1 · migrating Camellia/Yale 2 · reliance on unbuilt work 1 · vendor lock-in 2

P5 — One agent per number whose internal flowchart branches by client and call type

What it is. ElevenLabs "Workflows": instead of separate agents handing off to each other, one agent contains a graph of nodes, and the call walks the graph. Branches can be decided by data rather than by the model's judgment.

Strongest case. Two genuine upgrades. Routing stops being a judgment call — today the front door decides where to send a caller by reading English instructions, and a graph edge can decide it deterministically. And a node carries its own knowledge and tools as fixed configuration, which sidesteps a real platform limit: personalization can only be applied when a call starts, never when it is handed off mid-call.

The killer objection. ARGUED, well-grounded That headline advantage solves a problem we do not have — we never put per-building data in ElevenLabs' knowledge base; it lives in our server and our tools, which re-read it on every call. Meanwhile we have never used Workflows once: the flag for it is off in all 18 places it appears across our config. Adopting it means rewriting every drift check, every sync lane and every frozen snapshot — the exact machinery that is currently the only thing standing between us and prompts silently going stale. It does not move the first centralized client one day closer.

Scores — scale 4 · maintenance burden 2 · isolation 3 · time to first centralized client 2 (≈4 for the narrow "front door only, keep the 11 agents" version) · migrating Camellia/Yale 1 · reliance on unbuilt work 2 · vendor lock-in 1

• A phone number has to be able to point at a company or a group, not only a building. This is Gera's ChannelBinding design: an incoming address resolves to a scope. A scope wider than one building yields an unresolved building — which is a normal state, not an error.
• The building is discovered in conversation, then stamped and locked. The agent is allowed not to know and to ask. The server is never allowed not to check.
• The caller-identity gate has to widen from "one building" to "the buildings in this company" — safely. This is the Yale incident in reverse, and it is the single riskiest line of the whole program.
• Facts we currently compute at ring time have to become things Clara looks up mid-call. Available units, tour slots, pricing, office hours, announcements and after-hours status are all computed for one building before the caller has said a word. On a shared line they are wrong or empty. This is the largest single change in the program.
• ElevenLabs' ceiling is simultaneous calls, not agents. Their top self-serve plan handles 40 calls at once ($990/month, 12,375 included minutes, $0.08/minute over; bursts up to 3× at double rate). There are no sub-accounts — every client shares one pool. Dozens of clients and thousands of units will hit this before anything else, under every pattern. An enterprise conversation is a scaling prerequisite, not an optimization.
• One number can only ever be answered by one agent. All per-client and per-building routing must be resolved by our server when the phone rings, or by the conversation itself.

Option A — P2 as the target, sequenced behind the server program recommended

• Build first: the number→scope row; a tool that accepts a caller-named building and stamps it; widen the identity gate from one building to the company, with a test that proves the Yale case stays fixed; the two defects in section 5; then convert the ring-time facts to live look-ups.
• Western Slope: live in week 1–2 on the prototype line, which needs none of this. Onto the shared fleet when the program lands.
• Situs: maintenance line rehearsed on their test property in week 2–3; first real building only after the identity widening and the two defects ship, and only with Fede's separate go.
• Estimated cost: 4–7 weeks of server work, most of it the ring-time-to-live-lookup conversion. Agent work: roughly one prompt branch.
• Forecloses: nothing structural. It keeps one agent set, so per-client copies and a second family both stay available later. It does commit us to "a number identifies a company".

Option B — Stay on P1; give centralized clients one number per building

• Build first: almost nothing. Fill in the number→building field that is already built and unused, buy numbers, and ask Western Slope and Situs whether a number per property is acceptable to them.
• Western Slope / Situs: both could go live within the existing model, as fast as numbers can be provisioned and warmed.
• Estimated cost: under a week of engineering, plus recurring number cost and a real operational risk the survey flags: forwarded and tracking numbers accumulate "spam likely" carrier flags and need warming.
• Forecloses: nothing permanently, but it removes the forcing function. The whole server program then arrives in front of the first client who refuses per-building numbers, not behind them. Ask the customers before choosing this.

Option C — Try P5 as a front-door experiment, Western Slope only, dark

• Build first: the number→scope work anyway (Option A's first item), then one shallow flowchart agent on the Western Slope number that resolves the building and hands off to the existing specialists. The 11 agents are untouched.
• What it proves: whether ring-time facts survive into a node and across a hand-off; whether node settings quietly override our per-call personalization; real per-node speed; whether the graph is reviewable in a pull request; whether per-node scoring exists.
• Estimated cost: 1–2 weeks on top of Option A, and it moves the first centralized client zero days closer.
• Forecloses: nothing, if it stays one number and stays dark. It becomes dangerous the moment anyone treats it as a replacement topology — that version rewrites every drift check we own and converts our most portable asset into an ElevenLabs-only artifact.

Option D — Shared by default; a private agent copy only for a client who contractually demands isolation

• Build first: per-client provisioning tooling and one parameterized sync lane — neither exists — plus a check that every agent actually got copied.
• Western Slope / Situs: unchanged. Copies do not answer their question; a copied agent still resolves a number to one building.
• Estimated cost: 3–5 focused weeks for the tooling (the reviewer's own estimate), and then a recurring cost: every prompt change fans out across a 30-wide test matrix, 45–85 times a month.
• Forecloses: the compounding promise. Copies drift; a fix stops reaching every client automatically. Worth holding as a named exception for a paid isolation term, with an expiry review — never as the default.

1. Compute one new fact at ring time: does this line mean one property or many homes? Call it the intake mode. Camellia's line computes "single" and its call is byte-identical to today.
2. Move the prototype's qualify-first script into the shared leasing prompt as a block that only renders when the mode is "portfolio". Everything else in the prototype is either already shared code, or a duplicate that gets deleted.
3. Turn every Western Slope constant into data on their property record (office hours with the lunch gap, maintenance intake numbers, desk number). The prototype tree, its deploy lane and its 943-line provisioning script are deleted.
4. Prove it on a bench line, not the client's line: the portfolio harness number we bought on Sep 7 rings the Willows test fleet against a bench property that carries the same 16 homes. The 970 line stays on the prototype agent while we do this.
5. Cut over by repointing the 970 number from the prototype agent to the shared front-door agent, one config row, on merge, with Fede's go. Rollback is the same row put back. The prototype agent stays parked for a week as the rollback target, then is deleted.
6. A line that means several property records is phase two, on Gera's address-to-scope design: Western Slope on its 14 real records, and Situs from day one. Phase one leaves the seam for it and does not build it; the qualify-first script is the same in both phases, so phase two is a resolver and webhook change, not a prompt change.

Fits Gera's phases:

• Phase 0 (now). Placeholder building stands in for the org; its type field is the fork's only input.
• Phase 3. The address head lands; the fork's input swaps to the number's own row (org + scope) — no change to the fork logic, the scripts, or anything ElevenLabs is told.
• Phase 6. The re-key runs once, the placeholder is archived, and the fail-open (an unmapped number adopting a default) is deleted — an unknown number is refused rather than adopted.

Detail: night/findings.md (F1–F50), night/overnight-report-LONG.md, night/sentry-sweep.md. Adversarially claim-checked before delivery (night/report-verification.md); its corrections are applied. Where a number could not be traced to an artifact, it says so. ~1,120 words against a 700 target, deliberately. The overage is the corrections the claim-check produced plus the closing rule; cutting to length means dropping the parts that were hardest to establish. The five-line verdict at the top is the 700-word version.

The 970 line, in five lines

1. PROVEN, single-property only: the tour lifecycle ran end to end on a real Outlook calendar — book (call 3, driver PASS), reschedule (call 4, PASS), cancel (call 5, goal pass / vibe fail: transfer_to_agent fired before cancelling) — each read back via Graph, including the 404 showing the slot was released. 6 live calls. Deviation Fede should know: the read-back used the property's own stored delegated token, NOT the propflow/m365-sandbox app credential he specified — that credential cannot reach this line's consumer-Outlook calendar.
2. PROVEN in code, no call needed: three blockers portfolio mode hits (below).
3. NOT PROVEN — nothing behavioural in portfolio mode. Zero bench calls: no tour, no email, no calendar event, no tool firing; all 9 robot-call scenarios UNRUN. Also unproven anywhere: the whole email leg (the Willows suppresses pre-SendGrid by design; the escalation email is unprovable on any test property by design), the attendee on any booked tour (attendees: []), the bench calendar leg, and the leasing desk in replay.
4. BLOCKED on Fede. #7492 merged 03:46:26Z; its --apply is refused by the prod-property guard, which requires the release phrase from Fede's own environment — no session may set it for itself, and no worker reported doing so. Once he runs it, the binding branch still has to be pushed, merged on green and read back from ElevenLabs (9-step checklist) before the first call — call it tens of minutes, not minutes.
5. The 970 line was never dialled by this lane, by hard limit — all the above is inference from two benches.

THE HEADLINE — the finding that matters most, above the blockers

At least nine times tonight an instrument reported something other than what it claimed — ten counting the adversarial checker of this report, which flagged a correct scenario count as invented by conflating two harness tiers. Four read exactly like a product finding: a driver that failed every tour and accused Clara of confirming a booking she had actually made (false #3207 — that file sat on a typecheck quarantine, so a missing required argument never compiled); a green test grading a founder's personal cell under a comment claiming it graded the portfolio line; a grader marking Clara's verbatim standing instruction as a forbidden promise; a ban firing on street addresses, 3 of 4 firings false. Also: a data-store read returning 0 conversations while reporting the dynamodb backend (2473 via db); getConversationMeta returning messages: [] for a call with 18; a cleanup script printing tour-scan properties: appfolio-45 then deleting outside it. Separately a ban fix auto-merged at its first commit, holes live 22m47s — sequencing, not an instrument. Had the bench opened at midnight, 27 portfolio calls would have run through that apparatus and produced a confident, wrong readiness picture.

The rule underneath all of it, worth keeping past tonight: an ambiguous symptom is not evidence until something distinguishes its two causes. A consent screen looks identical whether the grant is absent or our connect path is broken; a tour check returned "missing" for a tour that existed; get-item printed nothing for an absent row; a Sentry endpoint ignored its window; a toggle printed RESTORED before checking; a monitor rendered "could not check" as "changed"; and a deviation was inferred from an order not visible in one agent's view. Each was an ambiguous symptom read as whichever cause was easier to reach for, and the easy reading was usually wrong. It is far easier to see in an instrument than in a person — the conductor made this error three times, once about a colleague — which is the argument for writing it down. It is also why every instrument here was proved in BOTH directions before its output was believed: a reader that has only ever printed "none" cannot tell you which "none" it means.

Blockers (in code, standing regardless of the bench)

1. reschedule_tour/cancel_tour declare a property but never expose one on the voice schema.
2. Open-hours person-ask dead-ends at {{pm_phone_number}}; the bench has no desk phone. #7498 held for Fede.
3. resolveVoiceConversationId's phone fallback has no property scope — watched bind a Willows call to a western-slope-proto conversation at 02:47Z; the 03:02Z control returned its own. Sibling fail-open at personalization/route.ts:580 adopts the caller's property — one config line from writing our bench run into another lane. Most serious product finding of the night; not fixed (hot path, daylight work).

Replay (detail: night/replay/PROGRESS.md)

Simulate replays, not live calls. camellia run 1 (corpus pulled 02:47:07Z): 87 replayed / 56 passed, baseline. western-slope-proto (pulled 02:47:34Z, run 02:57:44Z): 51 / 47, baseline. camellia run 2, same corpus: 87 / 57, 10 tool-sequence changes, 1 flip, 0 broken. 225 replays. No 429 appeared in any log — but the mandated 429-log.txt was never created, so that is an absence of observation, not an instrumented zero. Bar not met: 10 of 87 — but those 10 occurred with the change set held empty: same code, agent, corpus, all transfers. It would have false-alarmed on the first fix landed tonight; Fede rules on any replacement (noise floor persisted, #7520). 64.4% is not a health number: a Triage-only replay cannot reproduce post-transfer tools, and Camellia's transfer destinations differ from the Willows'. Triage-only — it does not cover the leasing desk.

Merged / held

Merged: #7505, #7506, #7513, #7520. Held for daylight, labelled, auto-merge off: #7502 (standing CHANGES_REQUESTED 03:33:54Z, never lifted) and #7509 (CHANGES_REQUESTED 03:33:08Z → APPROVED 03:43:52Z` — so its hold is now a choice, not a blocked review; it is mergeable in daylight). We dismissed no review: that reviewer was right repeatedly tonight and we were wrong.

Sentry (02:35–03:55Z, prod)

14 issues / 75 events: NEW-BUG 2, KNOWN 7, NOISE 0, LOCAL-DEV 5 — read proven by controls first (the project endpoint silently ignores the window; the org endpoint was used). Touching us: 2 issues / 5 events, both known since 2026-08-17, both a mail gate firing after a successful tour. No tour-handler errors, Graph failures or throttling. The 03:44:41Z AADSTS65004: User declined to consent is reported closed by the Onboarding lane — their own deliberate cancel against a throwaway property id, not the bench connect (never attempted). We did not verify that independently; our own sweep artifact still reads "unresolved". Sandbox tenant grant timeline (Onboarding lane): granted 03:49Z → scope-stripped ~04:31Z → deleted ~05:40Z → restored 06:00Z; current state read back good. Exposure for this lane: none, and stated rather than left to be worked out. The single-mode calendar proof ran 03:02–03:08Z on the Willows, against a consumer Outlook calendar via that property's own stored delegated token — not the sandbox tenant — and the bench connect was never attempted. No result in this report ran under the stripped or deleted grant. Reading rule for whoever connects next: a connect that prompts for approval means the grant is missing, not that our side is broken.

2026-09-10. Reference: Camellia today. Bench line +17208071724 → portfolio-bench, sandbox Triage (binding read back from ElevenLabs 15:59:20Z).

1. The single-property line is unchanged

Willows control, conv_1901m26268gffdva945ck0b1dg7p, 8 turns:

Clara: "Hi, it's Clara at The Willows — para español, diga 'español' — what can I help you with?" Caller: "Hi, I'm interested in a two-bedroom." Clara: "We don't have any two-bedrooms available right now, but I'd love to keep you in mind when one opens up. What's your name…?"

Single-property ordering — straight to the unit question, no town or area qualifying — is proven. The which-unit half was not exercisable: the scenario injects two-bedrooms at $1,800–$1,950; the live Willows has none, so Clara had no unit to offer and moved to a waitlist capture. Not counted as a pass on something that never came up.

Byte-identical evidence: PR #7494 (merged, green) — a route-level golden test of the 66-key personalization variable map for an apartment property, against fixtures from origin/main's own route.

2. Many-homes basics

Qualify to one home, cold caller — call one, conv_6801m260rrgxfkt8fqt4ce4w19mm:

"…several three-bedroom homes available right now, from about nineteen-fifty to twenty-seven seventy-five a month, spread across Grand Junction and Ridgway." …"There are two on Ember Lane in Grand Junction — 367 and 372."

Towns named unprompted; two homes on one street distinguished by number. Every address matched a listings snapshot taken minutes earlier; none invented.

Narrowing to one town — conv_5101m261z01bfznsvram7p8sdyn6. Stays inside Grand Junction throughout; names no home from outside it:

Caller: "Is there anything else available in that same area?" Clara: "Yes! Also in Grand Junction, there's a four-bedroom on Emerald Circle at two thousand three hundred fifty a month… available now and pets are welcome."

Caveat: a returning caller — same number, same person by design — so she had prior context and short-circuited the qualifying. The cold qualify is call one, and the both-towns line above is call one's, not this call's.

Book / reschedule / cancel: tour 825c5084 booked 16:01Z on 367 Ember Lane — the home the caller chose — moved 2026-09-10T17:00Z → 2026-09-11T17:00Z on the same event id, cancelled 16:17:46Z. Calendar event confirmed gone by fetching its id through Graph (ErrorItemNotFound), not inferred from an empty list. Tour d514b75f (2841 Morningside Court) confirmed and untouched throughout.

Leasing notifications: four emails to clara@ — 16:04:08Z confirmed, 16:10:09Z rescheduled, 16:14:18Z confirmed, 16:17:58Z cancelled. Matches Camellia's leasing side.

3. Prospect SMS

Shadow mode on, no message row, log line not obtained.

4. Open

The conversation cross-bind (a tool call binding to another property's conversation) stays open; carded.

How it came to be. On Aug 23 a severe tour-reschedule bug had to be tested on a phone line without reaching Camellia. ElevenLabs has no staging: every call rings production and a merge is the deploy. So an eight-agent copy of the shared fleet was created for the Willows test property, with its own agent ids and its own tool records, and the Willows number was pointed at it (#6184). Fede's ruling at the time: "Camellia frozen until he tests." For two weeks only the copy received merges.

What that cost. The freeze opened a gap between the repo and the live line: prompt fixes merged, reached the Willows, and did not reach Camellia, including a dead-air fix stranded three days (#7212 records it). Drift checks were pointed at hand-kept baselines so the gap read green, and one Willows sub-agent silently missed every prompt change since it was built (#7195). On Sep 7 the owner ruling reversed it: every fleet deploys on every merge; per-property difference comes from data, not from withholding deploys. A build test now fails if any writer skips a fleet.

So today: production and the test copy are the same instructions by construction. What differs is agent ids, tool ids, and which number rings which. Camellia is protected by the new behaviour being off for her record and by a test that fails on any byte moved in her call setup.

Alternatives considered (§11.3): ElevenLabs agent branches cannot be reached through the front-door hand-off or the simulator, so they cannot test the path a real caller takes; a separately edited duplicate is how 15 duplicate tools were minted on Jul 19 and live agents rebound onto them; per-call whole-prompt overrides share one webhook URL for all agents, so a mistake reaches both lines at once.

Options. (A) Keep the mirror, recommended for this go-live: what is tested is what production runs; no swap step to get wrong; Camellia's safety is a test, not a promise. (B) Isolated clone from a branch: matches the intuitive "clone, edit, test, promote" model, but it is the Aug 24 – Sep 7 setup that produced the stranded fixes and faked-green drift checks; promotion becomes a big-bang instruction swap; about a day to build a branch deploy path. (C) Do nothing now, revisit after Western Slope is live.

Clean-up worth doing regardless (small, session work): (1) the renewal-voice prompt sync is still shared-fleet-only, so the Willows renewal copy drifts; give it the same per-fleet second run. (2) After the 970 cutover, delete the prototype agent after its seven-day park. (3) Name the fleets by role in the config and ElevenLabs ("Production" / "Sandbox (Willows)") so nobody has to know an agent id to read the setup.

Merged: step 6 (#7608): the shared leasing prompt's intake directive now renders the qualify-first rules for portfolio-mode calls and stays empty for single mode; Camellia's variable map byte-identical (golden test green). Also merged earlier: bench binding #7595, harness verifier fix #7502, after-hours person-ask test #7509.

Closed without merging, on Fede's direction, branches kept: #7504 Research Caller agent (vendor-research tangent); #7613 renewal prompt sync per fleet (clean-up, not go-live); #7498 never-transfer-to-a-blank-number (a bench-only case: the test company has no desk phone, every real line has a destination).

Step 6 verification, 19:00–19:40Z: two robot calls on the bench line FAILED the qualify-first order (Clara named a home before asking area). Call one: the per-property injection cache (up to 26 hours old) predated the merge, so the rules never reached her; cache refreshed. Call two: the rules reached her verbatim inside the home-list data block and she did not follow them. The prototype obeyed the same rules because they sat in its own instructions via a declared slot; the shared prompt never declared that slot, and ElevenLabs drops undeclared variables silently. Finishing step 6 the right way now: the shared leasing instructions declare the slot (empty for single-building calls, so Camellia's rendered instructions are unchanged), rules live in exactly one place, one more call to verify. Follow-up finding: a deploy should invalidate that injection cache.

Open PRs in this lane: none. Fleet setup question (§11.11): default is option A, keep the mirror, unless Fede picks otherwise.

Next, in order: Fede calls the two test numbers (+1 844-285-3526 single building, +1 720-807-1724 many homes) and tries to break Clara; fixes and re-tests as needed; Western Slope's real facts on its record; then, on Fede's go only, the 970 line moves to the shared Clara.

Once the ladder is done, a call rings in and the resolver reads the number's address head — which org, which scope: company-wide or one building; an unknown number is refused, not adopted by a default. Everything downstream reads inside that org's wall; attachments (phone line, leasing mailbox, a calendar, a PMS login, office hours) resolve by nearest hook, the org's own where the building has none; the fact sheet is built for that scope; one shared agent and tool set handles every customer, forking only on which leasing script to speak from; our server books the tour on the resolved calendar (the building's own, else the company's) and notifications follow the inbound channel; conversation and prospect rows are keyed under the org. Western Slope's 970 line ends up exactly where Camellia, Yale, Willows and the bench already are — a number on the shared agent, differing only in scope. Full diagram and the retirement list by phase: §0.2 of the picture page.

Fede's words: "the architecture is decided... build it in a way that doesn't affect the Camellia production agent yet... a full copy that's safe that we can test thoroughly for both... one production agent and one staging."

The five-PR chain:

1. Fleet-aware render: production text byte-identical and pinned.
2. Resolver seam resolveLineScope: which org, company-wide or one building — today from the placeholder/registry, later from Gera's address head.
3. Many-homes leasing script file, unwired.
4. Front door on the staging agent only, picks the untouched Camellia script or the many-homes script by scope.
5. Live proof on the Willows (single-building) and the bench number (many-homes).

Promotion = production flips to the front door (a no-op for single-building customers) and the 970 line moves to the production agent — both Fede-only.

Note: the READ-FIRST carve-out PR #7641 is superseded and will be closed. The Willows stays the single-building test number on staging.

The five-PR chain (§11.13) is on main: #7678, #7679, #7680, #7691 all merged; #7691's merge commit is 351ceb02ed. The specialist sync ran for it (GitHub Actions run 34546671325, push to main, success) and a direct read-back from ElevenLabs confirms the split: the STAGING Leasing agent (agent_5901m0r9azzdetn8b1w2zyjy3v44, "Clara — Leasing [WILLOWS]") carries the literal {{many_homes_front_door_directive}} token in its prompt; the PRODUCTION Leasing agent (agent_8601krxqwzd2fhyrpqcfm71ndzh3) does not. Nothing here touched Camellia's or Yale's text, and neither was dialled.

Willows (+18442853526), single-building: a real robot call at 2026-09-10 22:03 MDT (after Willows' office hours) asked to tour a one-bedroom. Property and intake-mode resolution both verified correctly (stamped appfolio-45 / single), and the call correctly transferred Triage → the Willows' own STAGING Leasing agent — proof the staging front door is live on this line. Because the call landed after hours, Clara's after-hours message-desk logic took over (took a callback message instead of booking a tour) — expected system behavior colliding with test timing, not a defect in the front door. No tour was booked on this call; a clean single-building pass needs a re-run during Denver daytime business hours.

Bench (+17208071724), many-homes: a real robot call at 2026-09-10 22:06 MDT asked for a three-bedroom home. Clara asked area first (caller was flexible), then move-in timing, then the caller volunteered a budget UNPROMPTED — Clara never asked for one. She named two specific homes with prices by the fifth turn (Krista Street $1,950 and Ember Lane $2,750 in Grand Junction), described them only as "a couple of options" (no home count stated), and booked an in-person tour on Krista Street for Fri 9/11 9:30am. DynamoDB shows TOUR#3d2d3fc7-f644-4b7f-958e-f542c7fec6d2 under portfolio-bench, confirmed, with a populated Outlook/Graph event id — a real write to the clara@ sandbox calendar, not just a spoken confirmation. PASS against every bar in §11.13's live-proof step.

Also found, not fixed here (proof-only scope): (1) the harness's l4-e2e-postcall.ts driver has a stale module-load-ordering bug — src/lib/data/dynamo-client.ts's module-level TABLE_NAME constant gets frozen to .env.local's propflow-dev before the driver's own table override runs, so a bench provisioned only in propflow-prod (like portfolio-bench) falsely reads as "not found" unless the shell exports DYNAMODB_TABLE_NAME=propflow-prod itself; worked around for this run, worth a small harness fix. (2) the same driver's hand-off assertion hardcodes the shared/production Leasing agent id, so it now reports a false FAILED on the Willows call even though the call correctly reached the Willows' own dedicated staging Leasing agent — the assertion needs to accept a property's dedicated-fleet agent id, not only the shared registry id. (3) the "Clara behavior evals (promptfoo domain sweep, ci mode)" check that showed red on #7691 was a pre-existing, time-clustered flake — the same check failed at the same ~20-minute window (2026-09-11 00:08–00:28 UTC) on two unrelated branches, including one touching only unit-vacancy-sync.ts, then went green again for 15 consecutive runs afterward; not caused by #7691's changes.

Final results. The overnight test round is complete. This replaces the interim publish that went out mid-round with PARTIAL/PENDING rows — every row below is a settled result from real phone calls and real database/calendar/mailbox checks, not a prediction.

What was proven without placing a single phone call

Before dialing anything, the two lines' underlying setup was compared directly. This is the strongest evidence in tonight's round because it comes straight from the records that decide what Clara says, not from a conversation that could go any number of ways.

Conclusion: the fork works — it correctly tells the two lines apart — and the single-building line receives nothing new at all. It is not "the new material but turned off"; it is genuinely empty for that line.

Camellia's safety, proven two independent ways. (i) The leasing script Camellia's real callers actually hear right now was compared, word for word, against the copy sitting in the code repository — a difference check came back completely empty, meaning they are identical. Then the new many-homes marker text was searched for in both: it appears once in the staging (test) copy and zero times in Camellia's live copy, which proves the check is actually capable of telling the two apart rather than trivially matching everything. (ii) Separately, by how the system is built: the new qualifying script only ever switches on for a property recorded as "scattered-site" (homes spread across different addresses), and both Camellia's building and Yale 25 Station are recorded as ordinary apartment buildings — so structurally, it cannot switch on for either of them, no matter what a caller says. One note: Camellia's live script still carries an empty placeholder slot left over from earlier work, but it is gated off and empty. Both of these checks were done by reading the property records directly in the database, not by placing a real call to the live phone system serving a real customer.

Camellia's regression test: one test file run, 5 tests passed, 336 skipped, 0 failed.

Every call, tagged and checked. Each real call leaves a stamp on its own conversation record saying which script it got. Across every real call checked this way — three on the Willows and seven on the bench (six from tonight's round plus one carried forward from the preceding proof run) — the stamp was present on every single record, the Willows calls were tagged the single-building type every time, and the bench calls were tagged the many-homes type every time. No call ever got the wrong one, and there were no mixed or missing values anywhere in the set.

The replay harness floor

Two identical runs were made over the same stored history of 95 real Camellia conversations, replaying each one through the current system to see if it reaches the same conclusions. Both runs came back 44 passed, 51 failed, with all 95 conversations accounted for in both. Between the two runs, the sequence of actions Clara's replayed self took differed on 5 of the 95 conversations, and the final pass/fail verdict changed on 0 of the 95.

This is a measurement of the test tool's own noise, not a health score for Clara. Running the identical input twice and getting a different action sequence 5 times out of 95 means the tool itself isn't perfectly repeatable — so a raw pass rate out of this lane should never be read as "how good is Clara." Most of the 51 failures are concentrated in actions that are only supposed to happen after a call has been handed off to a live specialist — a step this replay lane cannot reproduce by its nature, since there is no real specialist on the other end during a replay.

Side note on the source data: the conversation history was pulled as 99 conversations recovered out of 100 attempted. The one that didn't come through was not lost — it was correctly refused by the privacy-scrubbing step, because two names had survived the scrub and it declined to write a record that still contained them.

Per-call results

Fourteen calls in total: twelve dialled tonight, plus two carried forward from the preceding live-proof round (marked below), since they land on the same two lines and the same questions.

What the failures have in common

Not one of tonight's failures was in the plumbing. Every real call picked the correct script for its line, read real homes at real prices straight from live data, and every booking, every move, and every cancellation landed correctly in the database and on the real calendar, with a real notification email going out where one was expected. What actually broke is the script Clara is following, not the system underneath it: the order she is supposed to ask questions in gets skipped, the rule capping her to two homes per answer gets broken, counts of homes leak out in wording that's supposed to be banned, the video-walkthrough option never gets offered, and on one call she never asked the caller's name at all. Those are wording problems, not wiring problems — a much better failure to have than the reverse. In line with the brief for tonight, the prompt text itself was deliberately not touched; these become follow-up cards and a ruling for Fede, not overnight edits.

Defects found

Nine defects came out of tonight's round. Six of the nine are faults in the test harness itself, not in the product — and four of those six fail in the direction that looks like success, meaning a clean-looking check could be silently wrong. The real headline of this run is less "how did Clara do" and more: the instruments used to check Clara's work were not themselves fully trustworthy, and that had to be discovered and corrected before its results could be trusted.

Corrections to the brief this run was given

• The brief asked for this write-up to be published as §11.15, describing §11.14 as not existing yet. §11.14 already exists on this page ("Staging front door live proof, 2026-09-11") — so this section is published as §11.15, the actual next free number, not §11.14.
• The brief said the personal runbook contains the test-call harness commands. It does not — they were located in the code repository instead.
• The brief said the harness's known noise floor is documented as "10 of 87." Section 11.8 does not support that figure — it instead warns that a percentage out of this lane is not a health number at all. Tonight's actually-measured noise floor, 5 of 95, is reported above in its place.

How the instruments were proven

Before trusting the calendar read-back used to confirm bookings, it was demonstrated reporting all three of its possible states correctly: a real event it found, an empty window correctly reported as genuinely empty, and a deliberately broken login correctly reported as "could not check" rather than "nothing there." That distinction matters — a tool that can't tell "I don't know" from "there's nothing" would make every negative result untrustworthy. Separately: calendar events showing up with no attendees listed is expected and correct, not a bug.

The mailbox read-back used to confirm notification emails was proven the same way before it was trusted: it correctly found a real email in a wide search window, correctly reported "nothing here" for an impossible subject line in a window that searched successfully, and correctly reported "could not check" rather than "nothing there" when pointed at a deliberately broken login.

Cleanup

The bench line's test tours are not covered by any automatic cleanup, so clearing them was done by hand, through the same booking system a real caller uses to cancel — never by editing the database directly. Cleanup is now complete: every tour record the round touched is cancelled, and — the stronger proof — a direct read of the bench calendar for Sep 10–12 came back with zero events in that window, so the calendar side is confirmed empty, not just inferred from the tour records saying "cancelled." The Willows calendar has no matching events either.

• 3d2d3fc7 — cancelled before the round started, at 05:17:59Z. Left alone it would have corrupted the reschedule and cancel tests, since it sat on the very phone line those tests were about to dial from.
• d514b75f — also cancelled before the round started, at 05:18:01Z, for the same reason: a leftover tour on a line the round was about to use.
• 4b7d6ce8 — booked by the round itself (the book-a-tour test), moved (the reschedule test), then cancelled by the round itself (the cancel test) at 06:31:55Z, as intended.
• 52cc13d1 — booked by the last call of the round, then cancelled during cleanup at 06:58:13Z.
• 825c5084 — already cancelled before tonight's round; left untouched.

Open question for Fede

Clara is not supposed to state a count of homes — "we have three two-bedrooms" is banned wording, and tonight's calls mostly respected that rule for homes (one slip, worded as "a couple of three-bedrooms," was still caught and counted as a violation, so the rule already reaches beyond bare numbers into vague wording too). But she freely states counts of appointment time slots on both lines — "there are eleven more later that day" on the single-building line, "9:30, 10:00, 10:30, and more later" on the bench line. One ruling would settle both lines at once: should the never-state-a-count rule also cover time slots, or is that fine as-is?

Fede asked for one comprehensive test harness for the shared phone agent — real tests, evals, multi-turn conversations, the tool calls verified end to end, across both of the agent's scripts: the single-building script the Willows test line runs, and the many-homes script the bench line runs. We already had most of the pieces. What follows is an honest map of what each piece proved, the three holes that map exposed, and two design questions that are Fede's to answer.

The short version. Six separate layers of testing already point at this agent, and between them they cover the single-building script well. The many-homes script is proven for booking a tour and for the way Clara qualifies a caller, and almost nothing else. Three holes matter more than the empty cells: the live layer can prove that something happened but not that something correctly did not happen; neither script has a local multi-turn conversation test, so every rule about the ORDER Clara asks things in is enforced only by the prompt itself; and on the many-homes line, booking a tour is proven while rescheduling and cancelling have no test at any layer.

Two things the map found that read as product findings, not gaps. First, one of our own many-homes tests grades Clara for asking the caller's budget — and asking for a budget is explicitly banned in the shipped rules, and the live bench call was recorded as a pass precisely because she never asked. That test is marked "expected to fail for now", which means the day Clara regressed into asking, our harness would announce it as a fix confirmed. A test that passes under the bug certifies the bug. Second, the check that verifies a call reached the right specialist looks the agent up in the shared production list, so a call on the staging line reads as a failure even when it behaved perfectly. Both are being corrected.

The map

Rows are behaviours; columns are the six layers that can test them. Full = a named test asserts it. Part = something adjacent is asserted, or it was observed once live without a standing test. None = nothing covers it.

A note on reading this table, carried forward from §11.8: "absent" and "could not read" are different answers, and a checker that has only ever printed one of them cannot tell you which it means. Every new check described below is proved in both directions — shown failing as well as passing — before its output is believed.

What is being built

One command runs the whole map for both numbers and writes a single report — every behaviour marked passed, failed or known-open, with the list of tools each call fired and whether each one's real-world effect was found. Alongside it: the missing "did this correctly NOT happen" half of the side-effect checks; multi-turn conversation tests for both scripts, advisory at first; the empty cells filled one layer at a time; and the two broken instruments above repaired. Each ships as its own small change, dark, nothing turned on at a customer.

Two design questions — one already answered, one still open

1. Whose calendar does a scattered-homes tour go on? — ASKED AND ANSWERED; this is no longer a question for Fede. An earlier version of this section had this pending Fede's decision. That was stale by the time it was written, and the correction matters more than the original point. Fede ruled on 2026-09-10: one shared leasing calendar per company, not one per leasing person — so the multi-person question that was holding it never needed answering. The read path is already built and merged: one chokepoint, getCalendarToken, tries the building's own calendar first and the company's calendar attachment second, and every caller that matters goes through it — checking availability, booking, moving and releasing a tour. The change that proposed a per-officer calendar was closed in favour of it. So the proposal as originally framed is void, and the harness case changes shape: it should assert through that one chokepoint, and it should cover both rungs, because the bench still has a calendar of its own and therefore never reaches the second one. A case that only ever exercises rung one cannot tell you the company rung works. What is genuinely left is not a decision but a data change — taking the calendar off the bench's placeholder building so the company attachment is what answers, which is also what makes the shared-mailbox collision below stop being possible. That is our work, on a test property, not a call for Fede.

The measured cost of leaving a calendar on a placeholder building still stands and is the reason to finish this: the placeholder behind the Western Slope line shares one sandbox mailbox with the Willows stress tests, so on 2026-09-09 a 9:00 slot offered to a caller came back as a conflict and the blocking event was a synthetic Willows move-in. A real caller can be told a time was just taken by traffic from a different property.

2. "Can I see the two homes next to each other?" Right now the tour tool takes one home, so two homes means calling it twice — and we have a real call where that failed in the worst way: the second booking was refused as a time conflict because the first booking's own calendar event was in the way, and Clara read one success plus one refusal as two confirmations and told the caller both were booked. The proposal is that one visit is one calendar event at one time, and the tour tool's home input accepts a list of up to three homes; a single building always passes exactly one, so nothing about Camellia changes. The harness case asserts the many-homes script offers a combined visit only when the caller actually asks to see two homes — offering it unprompted is a failure — and that exactly one confirmation and one calendar event result. It is marked known-open, so it reports red and does not block anything until the product change lands. Pending Fede: whether to make that change.

Both cases are written and will run; neither waits on the decision to be useful, and neither product change has been made.

A correction to an earlier claim on this page

This page has said, since the overnight report, that rescheduling and cancelling a tour are blocked in code because those two tools "declare a property id in their inputs but do not expose it on the voice schema, so on a call the property is never passed". The first half is an accurate reading of the schema. The conclusion does not follow, and it is wrong. The handler takes its selector from whichever field arrives — the phone tool's field is honoured by the same resolver as the documented one — and the property is filled in on the server from the conversation the call belongs to, so it never needed to come from the caller. One of the two tools does in fact carry a property field on its voice schema as well.

Worth saying how this was caught, because the mechanism matters more than the fact. The wrong conclusion was carried forward into the new harness as a pre-marked known-open gap — which would have suppressed a red for a defect that does not exist, the mirror image of the budget scenario that rewarded a banned question. A code reviewer refused the characterisation and cited the three places that refute it. A claim repeated from a prior report is not evidence; it had been true-sounding for a day and a half without anyone reading the handler. Rescheduling and cancelling on a many-homes line remain untested, which is the honest status — not blocked.

The rule was being broken inside our own instrument

The check that asks "did the team actually get a message about this call?" could be asked in two directions: prove one arrived, or prove none did. In the second direction it had a hole. It reads three places a message could have landed; if two came back empty and the third could not be read at all, it reported "confirmed: nothing was sent" — an absence certified off an incomplete look. It had been doing that since the check was written, and it would have gone on reporting clean negatives forever, because a negative that is wrong looks exactly like a negative that is right. The guard is now unconditional: if a lane could not be read, the answer is "could not check", in both directions. That is the same rule §11.8 was written about, found this time in our own apparatus rather than in a symptom.

One honest limit on all of the above. The ability to catch a write that happened when no tool asked for it is proven against fixtures, not yet against a real call — the live driver does not yet hand the checker the list of tools the call actually fired, so today that check produces no row rather than a false pass. It is one function call away and named as a follow-up. Until it lands, "we can catch a phantom write" is true of the checker and not yet true of a live call, and the report should not be read as though it were.

One root cause showed up four times in one night

Four separate pieces of harness work each needed to know what the many-homes bench property is, and because there was no single place that said so, all four authors typed it out by hand — and three of the four got the same field wrong in the same direction. The field is the one that decides whether Clara promises to text you about your visit. The real bench property has texting in shadow mode, which makes the shipped code say "nothing is sent for a visit here"; the hand-typed copies said the opposite, so the tests asserted a confirmation text and two reminders that the property provably never sends. In one of them the check could not even notice, because the expected value and the actual value were both built from the same hand-typed copy — a guard comparing a thing to itself.

One refinement, or the rule above gets over-applied. "Read the real thing" raises the question of which real thing, and the answer is not the same for every fact. The script that sets a test property up is the truth about what it was built with — its type, its shadow-mode switches. It is not the truth about what has been connected to it since. The bench's setup script records no calendar at all; the live row has one, attached out of band after the script last ran. So a fixture assembled purely from the setup script would have been wrong in the opposite direction — confidently asserting no calendar for a property that has one. The working rule: structural facts come from the thing that creates them, operational facts from the live record, and a test that needs both should say which it is reading and why. The harness case for the calendar now does exactly that — it takes the live connection as the first rung's fact, and builds the second rung from the same real row with the calendar stripped off, because no property in hand exercises that rung yet.

Only one of the four was caught by review. The other three were caught because, once the first was known, everyone went and looked. The fix is not three fixes. There is now one module that reads the real provisioned property, and the harness reads that instead of describing the property again — the same thing the homes list already does, which is why the homes were never wrong. The general rule, worth more than the incident: a test fixture that re-describes production is a second source of truth, and it will drift toward whatever the author assumed. Read the real thing, or assert nothing about it.

Bench testing with Fede 2026-09-11 settled four rules for how the staging and demo environments work, and named four more decisions still open for his call.

1. Production behaviour on staging lines. Fede: "I need to be testing what production would be like, not experimental features." Both the Willows and bench phone lines render production-grade behaviour (real prompts, live tools, no test gates affecting their paths). Dark features that are behind isTest conditions move to yale-sandbox only, never to a staging number that fields production calls.

2. The Willows is a demo, not a test dump. Fede: "It's a production-grade demo environment for customers." The property uses demo-grade data (fictional companies and personas, no real financial numbers), confirmations are on (residents and staff see real email and text activity), and no robot calls by default — the single-building voice line's outbound caller (the one that dials residents) moves to yale-sandbox, leaving the Willows voice line for customer-facing tours only.

3. Bench property configuration mirrors Camellia. The portfolio-bench property is now seeded to match Camellia's live settings: SMS shadow mode off (confirmations ship), tour confirmation texts on, office hours set, and nine knowledge-base fields left empty to match Camellia's state. The property's display name is changed from the literal "portfolio-bench" to a fictional company name.

4. Four decisions still open. (a) Cut the "is the date firm" clause from the booking script? (b) Drop or shorten the open-needs question — option A drops it, option B shortens it? (c) Should time-slot counts be in scope for the rules that guard what Clara states? (d) Pending: the past-weekday rule above (§ this page).

The independent inspection said two checks had never been run once, and told us to run them and publish the numbers as one table before any more changes to the phone script. This is that table, plus every other check that now has a real number against it. From here on, a change to the script is measured against these numbers — not against a fresh opinion.

What is new here. The full phone-agent test suite had never been read against these lines. The written conversation eval had never been executed at all — its first run is below. The prototype-versus-staging comparison had never existed. All three now have numbers. Two of them are uncomfortable, and they are printed as they came out.

Known differences on the stand-in lines, and why each one is there

1. Where the list of available homes comes from. Both stand-in lines read availability from the rent roll; production reads it from the vacancy list in the property system. Kept on purpose: pointing the Willows back at the production source left the line with zero homes to offer, which is the defect that ruined Thursday morning. The difference is recorded rather than hidden, because it means what a caller is offered can differ for a reason that has nothing to do with the agent.

2. The gate audit's 28 differing switches are not 28 differences a caller could hear. Of the 28, nineteen are the .isTest safety fences — email sinks, overnight sweeps, write guards — that exist precisely so a test property cannot send real mail or write real records. A caller never hears those. The checklist currently counts them as failures anyway, because it has no way to tell a safety fence from a behaviour change; splitting the row into "a caller could hear this" and "safety only" is the follow-up, and until it lands this row will stay red for the wrong reason. The one differing switch that genuinely sits on the path a caller hears is src/lib/integrations/voice/bench-codes-rule.ts:43, which adds a block of text to the prompt — but only when the caller's own number is one of ours, so a customer calling the same line gets nothing.

3. The tester's number is still known to the system. It was cleared earlier in the day; by the time the checklist ran at 18:16Z it resolved as a known prospect again, carried by three person records. The cause on record is the property-system sync re-creating it from a Test Property 45 record that carries Fede's email address. Until that is fixed, a call from that number is never a cold call — it is greeted with history — so the "one daytime call from a number with no stored identity" row cannot honestly be claimed. Fix carded for tomorrow.

4. The prototype comparison measures the script as it stood before the cut. It ran at 16:34Z today; the unapproved qualifying order was deleted an hour later. Its four differing rows describe that older script. The re-run after the cut will produce different rows, and those replace these.

The rule this baseline sets. A change to the phone script merges only against these numbers — the prototype comparison and both clone checklists are re-run after each one, and their new output replaces the rows above. No "ready", and no script-order change, without that re-run attached.

This is the go/no-go page the independent inspection asked for: seven rows per phone line, pass or fail on each, the proof-call transcripts attached in full, and every known difference written down with the reason it is there. Everything below was measured this evening against one build of the product — 71b3e92d93 — and every number points at the file it came from.

What is red or pending, exactly

Also pending, and not blocking on their own: text-message registration for the bench number +17208071724 (Fede's call, below); and PR #7853 and anything after it, which landed after this measurement and are therefore pending on this page.

The seven rows — The Willows line (appfolio-45, standing in for Camellia)

Run 2026-09-11 21:02:46–21:02:48Z against product code 71b3e92d9327dfecf1bd1536b5cc234da85f5630, reading the production table. Full output: final/willows-2026-09-11T21-02-39Z.md.

The seven rows — the many-homes bench line (portfolio-bench)

Run 2026-09-11 21:02:54–21:02:57Z, same build, same table. Full output: final/bench-2026-09-11T21-02-39Z.md.

What is actually holding row 5's identity check red

We assumed this was the property-system sync re-creating Fede's number from a Test Property 45 record that carries his email. On this run it is not. The three person records carrying the tester's number were last touched on 2026-09-06, none of them carries an email at all, and the record the system actually resolves to is a Western Slope prototype prospect created 2026-09-06 (3b88ef6c-…, property western-slope-proto). So the sync fix that is in progress tonight will not clear this row on its own — the check is being re-scoped to the line's own company instead. Source: final/row5-identity-claim-note.md, re-read independently at 21:05:09–21:05:20Z.

This did not weaken the proof calls. Both were placed from robot number +17205942061, which has no stored identity, and both conversations confirm it: the returning-caller context blocks rendered empty and the line had no tour on file for the caller. The red row is about Fede's own cell phone, which is the number the checklist is written to test with.

The row-6 grading — The Willows, turn by turn against a real Camellia call

Reference: conv_1201m1ykdwj8ejms7ks9e3pt5v1w, a real Camellia production call, Mon 2026-09-07 12:52 PM MT. Both transcripts are attached in full below.

The row-6 grading — the many-homes bench, turn by turn against the same Camellia call

Four of the automated grader's complaints about this call were checked one by one. Three are the grader quoting rules that were deleted from the script this afternoon and no longer exist anywhere — one question per turn, offering both tour formats, naming a team member in the confirmation. The fourth splits: "a couple of options" is the phrasing the script itself prescribes, but "a couple of two-bedrooms around sixteen hundred" is a real violation — counting what matches in one area and one bedroom size is counting the portfolio, which the live instructions ban outright, and it was also factually wrong.

Did it sound right? The audio check

The recordings were pulled and re-transcribed independently, because the failure we were hunting for — an English sentence delivered in a Spanish-accented voice — does not show up in a written transcript.

Stated honestly: the transcriber identifies the language spoken, not the accent — an English sentence read with a Spanish accent would still come back as English. The accent evidence is the voice-id lookup and the single-voice fact, not the transcription. The two together are what make this a pass. Separately, and not on this call: a different Willows conversation at 04:03Z the same day did open with the Spanish clause, which the ruling says should never render on this line. Our proof call was clean; that one is a separate lead.

Both transcripts, in full

[0s]   CLARA (Triage)
       Hi, it's Clara at The Willows — what can I help you with?

[5s]   CALLER
       Hi. What do your one bedrooms start at right now?

[10s]  CLARA (Triage)
       Let me check pricing and availability for you.

[11s]  CLARA (Triage) — (no speech, tool turn)
       TOOL transfer_to_agent → {"agent_number": 0}

[11s]  CLARA — (no speech, tool result)
       RESULT transfer_to_agent → transfer_to_agent_success, status success,
         from_agent agent_4701m0r9axyef53ry3bdtjkndcdp,
         to_agent agent_5901m0r9azzdetn8b1w2zyjy3v44,
         condition "Caller's intent matches leasing scope (see prompt-side routing rules)."

[13s]  CLARA (Leasing)
       The one-bedrooms start at fifteen-fifty a month, and we've got several available right now.
       We're also running one month free on 12-month leases — you'd pay for the month you move in,
       and the next month is the free one. Want to come take a look?

[32s]  CALLER
       Yes, I'd love to tour tomorrow afternoon. Can you get me in?

[38s]  CLARA (Leasing)
       Tomorrow is Saturday, September 12th — I've got slots at 10:30 AM, 11:00 AM, 11:30 AM,
       and more later that day. What time in the afternoon works best for you?

[54s]  CALLER
       Any afternoon slot works great for me. What do you have afternoon?

[59s]  CLARA (Leasing)
       Let me grab your name first — what should I put on the booking?

[65s]  CALLER
       It's Riley Chen.

[67s]  CLARA (Leasing)
       Let me get that booked for you, Riley!

[69s]  CLARA (Leasing) — (no speech, tool turn)
       TOOL schedule_tour → {"preferred_date": "2026-09-12", "preferred_time": "12:00 PM",
         "prospect_name": "Riley Chen", "desired_bedrooms": 1,
         "system__message_to_speak": "Let me get that set up for you!"}

[73s]  CLARA — (no speech, tool result)
       RESULT schedule_tour → {"success":true,
         "tourId":"2d81c465-b410-4b46-bbff-e8fa028dbeeb","auto_confirmed":true,
         "unit_number":null,"booked_time":"12:00 PM",
         "message":"Tour confirmed for Riley Chen at The Willows on 2026-09-12 at 12:00 PM.
                    It's been added to the calendar.",
         "spoken_confirmation":"Your tour is confirmed for Saturday, September 12 at 12:00 PM.",
         "mismatch":false}

[73s]  CALLER
       Great, thank you.

[76s]  CLARA (Leasing)
       You're all set, Riley — tour confirmed for Saturday, September 12th at noon at The Willows!
       Anything else I can help you with?

[87s]  CALLER
       Quick question: What's the pet policy for a small dog?

[92s]  CLARA (Leasing)
       Up to two pets per unit, no breed or weight restrictions. There's a three-hundred dollar
       one-time pet fee, a three-hundred dollar refundable pet deposit, and thirty-five dollars
       a month in pet rent. Anything else?

[109s] CALLER
       No, that's all. Thanks so much. Clara?

       — caller hung up. No end_call tool. Termination: "Call ended by remote party".

0.  CLARA (Triage)  [t+0s]
    Hi, it's Clara at Mesa County Homes — scattered homes (TEST) — what can I help you with?

1.  CALLER  [t+8s]
    Hi, I'm looking for a place in Fruita. What do you have available there?

2.  CLARA (Triage)  [t+13s]
    Let me check pricing and availability for you!

3.  CLARA  [t+14s]  (no speech — tool turn)
    TOOL transfer_to_agent → {"agent_number": 0}
    → transfer_to_agent_success, from agent_4701m0r9axyef53ry3bdtjkndcdp
      to agent_5901m0r9azzdetn8b1w2zyjy3v44

4.  CLARA  [t+14s]  (empty turn — post-tool continuation)

5.  CLARA (Leasing)  [t+17s]
    We don't have anything listed in Fruita right now, but we do have some great options in
    nearby Grand Junction and Clifton. Would you like to hear about those, or are you pretty
    set on Fruita specifically?

6.  CALLER  [t+31s]
    I'm pretty flexible on location, so sure, I'd love to hear what you have.

7.  CLARA (Leasing)  [t+36s]
    We've got a nice mix across Grand Junction and Clifton. In Grand Junction, there are
    three-bedroom homes running from about nineteen-fifty to twenty-seven seventy-five a month,
    and a couple of two-bedrooms around sixteen hundred. In Clifton, there are two-bedrooms
    starting around twelve-fifty a month — and the Krista Street homes in Grand Junction are
    offering four weeks free rent on new twelve-month leases right now.
    What size are you looking for, and when are you hoping to move in?

8.  CALLER  [t+69s]
    Just something quiet. A two-bedroom would be great. And I'm thinking sometime in the next
    couple months. Pretty flexible.

9.  CLARA (Leasing)  [t+77s]
    Great — for two-bedrooms, I've got a couple of options. There's a place on 32 1/8 Road in
    Clifton at twelve-fifty a month — about eight-ninety square feet. And there's another on
    Elm Avenue in Grand Junction at sixteen hundred a month, a bit more compact at around
    six-seventy square feet.
    Want to hear about either of those, or would you like to come take a look?

10. CALLER  [t+103s]
    The Clifton one sounds great. I'd love to see it.

11. CLARA (Leasing)  [t+109s]
    I'd love to get that set up for you! I have Friday, September 11th at four-thirty or five PM,
    or Saturday the 12th starting at eight AM — which of those works for you?
    And what's your name so I can get the tour booked?

12. CALLER  [t+126s]
    Friday the 11th at four-thirty works. And my name is Morgan Ellis.

13. CLARA (Leasing)  [t+133s]
    Let me get that booked for you!

14. CLARA  [t+134s]  (no speech — tool turn)
    TOOL schedule_tour → {"preferred_date":"2026-09-11","preferred_time":"4:30 PM",
      "prospect_name":"Morgan Ellis",
      "unit_number":"486 32 1/8 Road, 4, Clifton, CO 81520","desired_bedrooms":2,
      "notes":"Caller is flexible on move-in, looking within the next couple of months.
               Interested in a quiet two-bedroom.",
      "system__message_to_speak":"Let me get that booked for you!"}
    → {"success":true,"tourId":"403ae24a-1bea-41b9-aae6-f1f5ac1eb913","auto_confirmed":true,
       "unit_number":"486 32 1/8 Road, 4, Clifton, CO 81520","booked_time":"4:30 PM",
       "spoken_confirmation":"Your tour is confirmed for Friday, September 11 at 4:30 PM.",
       "mismatch":false}

15. CLARA  [t+139s]  (empty turn — post-tool continuation)

16. CALLER  [t+143s]
    I'll wait for Clara to finish.
    (audio-only, dropped by the live transcript: the robot begins to wrap up and is cut off —
     "Perfect. Thank you so much for taking the time to—")

17. CLARA (Leasing)  [t+146s]
    You're all set, Morgan — tour confirmed for today, Friday September 11th at four-thirty PM
    at 486 32 1/8 Road in Clifton. You'll get a confirmation text shortly with the address.
    Anything else I can help you with?

18. CALLER  [t+165s]
    No, that's all. Thanks.

    — caller hung up. No sign-off turn, no end_call tool.

[t+0s]   CLARA    Hi, it's Clara at Camellia Apartments — what can I help you with?

[t+8s]   [CALLER] Schedule a tour.

[t+11s]  CLARA    Let me check pricing and availability for you.

[t+12s]  CLARA    (no speech — tool turn)
                  TOOL transfer_to_agent → {"agent_number":0}

[t+12s]  CLARA    (empty turn — post-tool continuation)

[t+14s]  CLARA    Happy to get that set up! What type of apartment are you looking for —
                  a studio or a one-bedroom? And when are you hoping to move in?

[t+26s]  [CALLER] One bedroom, September 30th.

[t+31s]  CLARA    Great! We have one-bedrooms starting at twelve hundred a month, and there's
                  a move-in special right now — one month free on new 12-month leases.
                  I've got tour times available Tuesday, September 8th or Wednesday,
                  September 9th — do either of those work for you, and what time would you prefer?

[t+53s]  [CALLER] No.

[t+56s]  CLARA    No problem! What day works better for you?

[t+61s]  [CALLER] Thursday, September 10th or Friday, September 11th.

[t+66s]  CLARA    What time works best for you on either of those days?

[t+74s]  [CALLER] Thursday, September 10th at 10:00 a.m. or 12:00 p.m.

[t+83s]  CLARA    And what's your name?

[t+86s]  [CALLER] [CALLER].

[t+92s]  CLARA    Let me get that booked for you!

[t+95s]  CLARA    (no speech — tool turn)
                  TOOL schedule_tour → {"preferred_date":"2026-09-10","preferred_time":"10:00 AM",
                    "prospect_name":"[CALLER]","desired_bedrooms":1,
                    "desired_move_in":"2026-09-30",
                    "system__message_to_speak":"Let me get that booked for you!"}

[t+100s] CLARA    (empty turn — post-tool continuation)

[t+105s] CLARA    You're all set, [CALLER] — tour confirmed for Thursday, September 10th at ten
                  in the morning at Camellia Apartments! Anything else I can help you with?

[t+118s] [CALLER] No.

[t+121s] CLARA    Great — have a wonderful day, [CALLER]!

[t+122s] CLARA    (no speech — tool turn)
                  TOOL end_call → {"reason":"[CALLER] confirmed no further questions after tour
                    was booked.","system__message_to_speak":"Great — have a wonderful day, [CALLER]!"}

[t+124s] CLARA    (empty turn — post-tool continuation)

What else the two bookings produced, checked one by one

The text-message question, now answered

The Willows sent a booking text. Would Camellia? Yes — this is a match, not a difference. A confirmed booking bypasses the "tour request texting" opt-in entirely, so that setting is irrelevant here. Reading both property records strongly-consistent: neither carries any text-message setting of any kind, and neither company has any company-level defaults to inherit from — those records do not exist. Camellia reaches the identical code with identical answers at every gate, and its prospect would get the same message with Camellia's name and address filled in. This corrects the earlier handoff note that said Camellia does not text.

What the same investigation did turn up is a real bug, and it is in the open findings below: the booking text left through Twilio even though the Willows is configured to send through AppFolio. The cause is in the source, not the configuration — the tour text senders never tell the message dispatcher which property the message belongs to, so the dispatcher has nothing to look the door up with and falls back to the direct one. The same mistake was found and fixed on the reply lane on 2026-09-03; the tour lane was missed.

Cleanup — both proof tours cancelled

Both bookings were cancelled through the app's own cancel endpoint at 21:24:58Z and 21:25:54Z. Both tour records read cancelled on a strongly-consistent re-read, and both calendar entries were verified gone (the calendar returns "not found" for each). The bench's cancellation email was delivered to our sandbox mailbox; the Willows' was suppressed at the sink address as designed. The bench property's display name was also corrected in the data to "Mesa County Homes", through the app's own rename route — one field changed, everything else on the row verified unchanged, and the cancellation email subject already shows the corrected name.

Neither line sent a cancellation text, and the plan expected the bench to. That is logged below as an open question, not a pass.

Known differences — everything the stand-in lines do differently, and why each one is there

The verdict asked for this list with a reason per line. Nine differences, all deliberate, none of them hidden.

Open findings from the proof calls — product bugs, not clone differences

These are things the calls exposed that would be wrong at a real customer too. None of them is a reason the lines are not a faithful copy; all of them are work.

What ran, and on what code

Everything above was measured against one build of the product: 71b3e92d9327dfecf1bd1536b5cc234da85f5630. The changes in it, in the order they landed today: #7801 (re-gating, 16:27Z), #7807 (guard), #7809 (checklist), #7818 (the dead intake block deleted, 17:35Z), #7823 (tool order), #7831, #7834, #7835, #7842 (replay, test fixture, row-4 split, gate rulings), #7844 (push to staging), #7805 (the prototype gate itself), and #7822 (the area question actually reaches a company-wide line, 20:46Z — the head of this build). PR #7853 and anything after it landed after this measurement and are therefore pending on this page. Every tool was faked in the two harness runs: no webhooks fired, nothing was written, and no phone call was placed by either of them. The two proof calls were the only real calls.

What Fede decides

Seven independent passes over Fede's own transcripts — six Claude sessions plus the Western Slope kickoff recording — pulled out every word he actually said about what the company-wide phone line asks a caller, in what order, and how it books a visit. This section is the result: his rulings, dated, verbatim, with the ones he reversed shown as both halves. Nothing here is paraphrased. Where a row records something nobody said, it says so.

1. The rulings, dated

Times are Denver (MT). "Source" names the session transcript, the kickoff recording, or the document that carries the words. Verbatim means verbatim, typos and dictation garbles included; a fix or note from us is in [brackets]. "Relayed" means another Claude session passed his words across — the quote is his, the wrapper is a teammate's.

2. What the customer actually asked for — Jay, Western Slope kickoff, 2026-09-09

Verbatim from the raw per-speaker transcript in #transcripts (thread 1788995366.021449), not from the recap. Speaker label is the recording's: "JasonFish" is Jay.

And Fede, on the same call, on what the whole script is for: "The goal is get a showing with a person, right? Like, don't give objections, just give the information, just, hey, can I book a tour? You know, keep pushing."

3. What the research recommended, with its own confidence and sources

Verbatim from qualifying-research-2.md §(d), the pass Fede accepted with "this seems like a first good pass". Pass 1 is explicitly superseded by pass 2's own words: "Pass 1's 'budget second' is contradicted by all primary evidence."

Its consensus-order source counts, verbatim: "Move-in date — 6 sources"; "Bedrooms / layout — 4"; "Name, then phone — 4 early… 2 sources put it last"; "Specific needs / preferences — 5"; "Pets — 4"; "Lead source — 3… Rubric-only artifact"; "Price / budget — 4, but always LATE, and NAA says quote price only if the caller asks; EliseAI does not require it at all"; "Occupants — 2… Weakest"; "Reason for moving — 3… Rubrics grade it; leasing AI never asks it."

Its central finding, verbatim: "The central conflict: rubrics close for the tour at item 13 of 20 (ACE) and 13 of 15 (EPMS) — after full qualification and amenity-selling. Every verified AI agent inverts this and offers the tour within 2–3 turns on ≤2 qualifiers."

Sources it actually read. Five full call transcripts: EliseAI (a 7-month operator review, 1,600 leases, plus support.meetelise.com docs read through a search index — direct fetch 403s); Thoughtly (live demo call); Excel/Accelerate AI (demo call); a realtor agent's three live calls. Three published mystery-shop rubrics: LeaseHawk/Fenix ACE Agent Performance Survey (20 items / 100 pts), EPMS telephone shop (15 items / 100 pts), NAA NALP "Telephone Presentations". Plus LeaseHawk's conference talk on 150M calls / 100k scored agents, and renter-side accounts (r/Apartmentliving, a Yahoo Finance piece). Absences it proved: AppFolio Lisa (18 support articles read, no question set documented anywhere), Knock, Entrata ELI — nothing found. Struck from the competitive set: Colleen AI is defunct (folded into Entrata); Hyro is a healthcare vendor, not multifamily. Never called: the two public demo lines, EliseAI (888) 315-2945 and LeaseHawk/Fenix 844-389-4060.

4. Fede's process rules — the ten he repeats most

Two more that govern everything above, and are not negotiable: the three-step rollout — "shipping to prod off, testing at willows, and only then turning on to customers is a separate step with my approval only" (2026-08-30 19:39, after missed-call changes reached a live customer) — and the settings freeze, "no dont do seetings yet" (2026-09-09 20:45).

5. The pattern behind every complaint

It is one shape, said in different words for twelve days. Something arrived that he had not asked for and could not see the reason for — "why are you adding stuff we never asked for or thigns production doestn have", "i ddint ask for anyo fthis", "theres a lot of things here i didnt ask for", "this is half baked", "this seems half baked?", "no this is over engineering and not focused on the problem i want solved" — or it arrived at a customer without him — "we cant be making chagnes in production without my approval or testing", "but why did you change production without asking me" — or it was explained in a register he could not read — "plain anglish", "i dnt understand anything", "Can you tell me in plain English?", "what diagrams should i lookat theres a lot" — or it was called finished when it was not — "i also saw no test results, evals, if we regressed", "seeems like we ran no quality ch[e]cks", "why is it idle its not done", "tell it do fully finish dont be lazy" — or it stopped and waited on him for something he had already delegated — "why are you wainting on me", "why jus tdo it", "So now I'm… I don't understand why you're kinda, like, pausing and keep asking for permissions and all this not done stuff. I don't know what… like, what is going on". And when several of those land in one morning, it becomes the sentence that ended 2026-09-11: "Okay. I think we need to pump the brakes here. there's too many issues and confused. Can you just take a step back and figure out why there's so many bugs, and it's so confusing, and it's… like, stuff is off here, on here. It's just a mess. What is going on?" — followed by "because the overnight goal was a production ready clone. Right? And I would just do the final testing. And then I will share with the client. But instead, I'm finding issue after issue after issue."

Provenance. Every quote above is verbatim from one of: the six mined session transcripts (agents/000, agents/002, agents/003-bd, agents/006 ×2, agents/010), the raw per-speaker Western Slope kickoff recording in #transcripts, qualifying-research-2.md, or Fede's own words to the orchestrator on the evening of 2026-09-11. Two rows carry an explicit [INFERENCE] or "no Fede quote exists" label; nothing else on this page is inferred. Recorded so nobody mines them again: three of the seven passes — the two agents/006 transcripts and agents/010 — are grep-verified negative for the qualifying-question set, the question order, "is that date firm", the open-needs question, counts, one-question-per-turn, the tour-booking rules, the Spanish clause and the 970 cutover. In those three files the 970 line, the September 17 date and Kat by name appear only inside cross-session relays, never in a word Fede typed. What they do carry is parity, tours-of-unavailable-units, the per-property-switch ban, and most of the process rules above. The build specification these rulings resolve into is at scratchpad/fede-context/BUILD-SPEC.md in the session that published this section.

Western Slope’s phone number stopped ringing its own private agent today and started ringing the same Clara every other customer gets. The first fifteen live calls said she describes the homes well and cannot book one properly. Sixteen more, after the fixes, say she is ready to dial. Alongside it, a test company of our own now exists, so rehearsals stop happening on a customer’s account.

1. The cutover — the 970 line rings the shared Clara

• The 970 number now reaches the same Clara that answers Camellia and Yale.
• The old private agent stays parked, switched on and unused, as the way back.
• Going back means pointing the number at it again — never undoing the change.
• Merging took seven tries: six build machines died mid-check, not from our code.
• A measured wall — the check needs 8.4 GB, the machine has 7.9 GB. A bigger machine is proposed.

Proves: The cutover ledger, the vendor's read-back of the line, and today's memory measurement.

2. The re-run — ready to dial, with one open item

• Sixteen more live calls. All three blockers from the first run are closed.
• The booked tour names the home — in the record, on the team’s calendar, and in the caller’s text.
• Deposits: six of six published quoted right, five of five unpublished sent to the team. The invented formula is gone.
• The stall before a named home is gone, and both visit formats are offered, on all fourteen.
• One open item: a leasing call still ends without a name, so a booked tour reaches the team as a phone number. A fix is in flight.

Proves: Sixteen placed calls on the live line, each answer read against the home’s own published record; the booking checked on the record, the calendar and the text.

3. The many-homes rules never reached the production agent

• The rules for a many-homes line live in one block handed to Clara each call.
• It arrives through a named slot. Only the rehearsal script had that slot.
• Real calls use the production script, and the vendor silently drops what nothing asks for.
• So on every call the rules were built, sent, and thrown away.
• The caller's name was never asked; a video walkthrough was never offered.

Proves: A read of the live production script, plus a new check that the script declares the slot.

4. A company's homes are the company's own rows, never a building

• Each scattered home is already its own building, and most hold nothing: 55 of 69.
• Asking each building what is available answers “nothing” while the public page lists sixteen houses.
• The page is now read into rows the company holds. No building is written.
• Address matching would not have saved it: eleven of fifteen homes match a building, four match none.
• Those four sit inside a complex under another street number — unanswerable under the old shape.

Proves: The customer's real page parsed by the production parser against their real building rows. Both pieces are dark.

5. Fairhaven Residential — a test company of our own

• Built unattended through the real front door: invite, real email, terms, texted code, buildings imported.
• Its leasing mailbox and calendar hang on the company, not on a building.
• A tour entry landed on that calendar, was read back, and removed.
• Twelve invented homes on a page we host, so no rehearsal reads a customer's page.
• Rehearsals move here; the customer's own account is kept for acceptance only.

Proves: A build report of ids, links and 51 headless screenshots, plus a cold read straight off production.

6. Two writes that need Fede, then the line follows

• One guarded write creates the company's anchor record: no homes, no line, nothing reaching a person.
• Only Fede's own session can release it. The guard is working as designed.
• The second declares where the homes are published. It acts on a company, so the hook refuses.
• His pick: a plain terminal, teach the hook about companies, or both writes in one sitting.
• Once the anchor exists, pointing the 970 line at it is ours to do.

Proves: The dry-run output of both writes, and the safety hook's own refusal message.

7. “No calendar” is not a regression

• Phone bookings have confirmed on the spot, calendar or not, since March.
• Fede wrote that rule himself: the caller is on the phone.
• Text bookings have always waited for a calendar. That split never changed.
• September's change was narrower: it stopped a confirmed tour being quietly un-confirmed afterwards.
• The hole: no calendar and no team address means nobody on the team is told.

Proves: The tour code's commit history read back to March, plus three open defect lists already carrying it.

8. Appendix — every pull request opened 2026-09-12

91 in total: 72 merged, 10 still open, 9 closed without merging. Newest first.

One goal on this line: match the caller to a home we have, and book the tour. Nothing else matters.

• Two callers: one saw a listing, one is exploring. Clara sorts them from what they said — or asks.
• Move-in timing comes first — the client’s own front-running question. It forks the call.
• Urgent hears what is open today. “In a month” hears the coming-soons.
• Then area, then a real conversation: dog, yard, space, who is moving with them.
• Past one home it is Camellia word for word — details, fees, applying, slots, booking.

Proves: The raw per-speaker recordings with the client (Sep 4 and Sep 9), the 2026-09-09 industry research, and Fede’s own words of 2026-09-12. Full reasoning: scratchpad/many-homes-mode/REASONING.md.

Five calls to place on the Western Slope line, in order. Each one shows a different thing Clara now does. Every home, rent, deposit and fee below is live in that account today.

1. The drive-by — he names the house, she books it

• Greeting keeps the leasing / maintenance ask, then she hears the street and repeats it back.
• Home and rent in one breath, two or three highlights, then “anything in particular?”
• Deposit $2,750 and the $32 background check fee come straight off the card.
• Mornings or afternoons, two concrete slots, booked, read back, name taken.

Point at: she never asks what he already answered, and the $32 fee she used to not know is now in her head.

Proves: 367 Ember Lane is live in the account today with that rent, deposit, fee and special.

2. Two weeks, and firm — the area cuts it to two

• Move-in first, and whether it is flexible. Firm forks the whole call.
• Urgent hears only what is open today — nothing she cannot deliver by her date.
• Area asked once, open. “Anywhere” would have been a complete answer.
• Both homes named with their rents in one turn, then the pitch, the fee, the slots.

Point at: two homes and two rents came back in one breath, and the firm date quietly kept the $2,800 house out of the conversation.

Proves: both Clifton homes are open in the account today at those rents and deposits.

3. “Sometime next month” — the coming-soon earns its keep

• “End of October” forks the other way — lead with the coming-soon.
• Name it, offer him its list.
• It cannot be walked yet, so offer its open twin this week.
• Book that visit. Same slot offer, same close.
• Rehearse this one first: the feed carries the pre-leasing card, the block Clara reads does not.

Point at: the caller in no hurry hears a home nobody else can show him, and still lands on the calendar.

Proves: the account holds 15 cards today — 14 open, one pre-leasing (374 Ember Lane), which the block excludes.

4. A dog and a yard — the question that picks the home

• Move-in, then area. Grand Junction leaves a handful, not one.
• Now she gets conversational: pets, yard or garage, space, who is coming.
• “A dog, and he jumps” makes the fenced yard decisive.
• She names the runner-up and why it loses — closest match, said as such.
• No deposit published for Placer, so she says so. No invented number.

Point at: the dog and the fence are asked once, and her added question chose the home.

Proves: Placer’s yard, garage and pet policy are on its live card; its deposit genuinely is not.

5. “What’s around there?” and “can I talk to a person?”

• Named home, so no re-qualifying. Rent, deposit and the $32 fee from the card.
• The neighborhood answer comes from notes stored on the home.
• Asking for a person gets his question written down for the team.
• No transfer, no hold, no promised callback, no team member named.
• She goes back to the tour in the same breath.

Point at: she answers the town like a local, and “let me talk to a human” still ends in a booked tour.

Proves: the Redcliff card carries that rent, deposit and fee; the neighborhood lines come from sampled notes.

6. What you’ll see afterwards

• The text names the home’s address and nobody on the team.
• The email reads in two seconds on a phone: who, when, which home, when they want to move.
• Preferences read as preferences — has a dog · wants a fenced yard · moving end of month.
• Empty fields vanish. No repeated company name, no “from phone”.
• The summary describes this call, not an older thread.

Proves: the text is the shipped template. The email rewrite is in flight, not shipped — open a real one before promising its exact shape on a call.

7. Do not demo yet

• In-person visits are the default. A video walkthrough happens only if the caller asks.
• Promise follow-ups are switched off on purpose, everywhere — they did not work.
• Clara never asks the office mid-call and promises the answer back.
• Adding a second home to a tour is wanted, capped at two when it comes, and not built.

Proves: each is a stated 2026-09-12 ruling or an explicit “we’re not building it now”.

Appendix — the lines, word for word

What the demo-er says, and what Clara should do with it. Homes, rents and fees are today’s live cards.

Proves: every home, rent, deposit, fee, amenity and special above was read from the Western Slope account on 2026-09-12; the flow is Fede’s rulings of the same evening (§11.22); the neighborhood lines come from the sampled notes for that exact address.

Proposed — pending Fede’s review. The page to hand the Western Slope team so they can test the leasing line themselves. Eight short calls, one screen each: what to play, what to say, what you should hear, and what should arrive afterwards. No preparation needed.

Before you start

• Dial +1 970-822-0641 from your own mobile. It answers any time, day or night.
• She asks whether it is leasing, maintenance, or something else. Say leasing.
• The line recognises a phone number. Your first call from a phone is the only “new caller” call that phone gets — so spread the eight calls across the team, one each.
• Play the situation as if it were real. Do not explain that you are testing.
• These are real bookings on real homes. Warn whoever watches the calendar so nobody drives out.

Proves: the number is live and answering today, on the same homes as your public listings.

1. You drove past the sign

• Play: you drove past a sign on a new duplex on Ember Lane and called the number on it.
• Say: “I drove past a new place on Ember Lane with your sign out front — is that one still available?”
• You should hear: the address back, three bed / two bath, $2,750, two or three good things about it, then “anything in particular you’d like to know?”
• Then: ask to see it. Mornings or afternoons, two real times, booked and read back to you.

Tell us if she asks you something you already told her — your timing, your budget, or which area.

Proves: that home, its rent, deposit, fee and opening special are live on your account today.

2. Nothing in mind, moving in two weeks

• Play: you are looking around, have nothing picked, and must be out by month end.
• Say: “I’m just seeing what you have open right now” → “end of the month, and I can’t really move that” → “out toward Clifton if you have anything.”
• You should hear: when you want to move, asked first, and whether that is firm. Then one open area question.
• Then: two Clifton homes with their rents in a single answer — 486 and 460 32 1/8 Road — then a visit booked.

Tell us if she offers a home you could not actually move into by your date.

Proves: a firm date silently keeps the homes you cannot have out of the conversation.

3. Not moving until late October

• Play: you are early. Late October, nothing urgent, you want something new.
• Say: “I’m starting to look — probably end of October” → “Grand Junction, near town ideally.”
• You should hear: the coming-soon home first — 374 Ember Lane, $2,775, pre-leasing — and an offer to put you down for it.
• Then: since it cannot be walked, a visit this week to its open twin at 367 Ember Lane, same floor plan.

Tell us if she only offers what is open today and never mentions what is coming.

Proves: a relaxed date is worth a pre-leasing home, and still ends on the calendar this week.

4. A dog that jumps fences

• Play: a three-bedroom in Grand Junction around $2,000. You have a dog that jumps fences.
• Say: “Three-bedroom in Grand Junction, around two thousand” → “next month, I’m flexible” → “a dog” → “a yard — fenced, he jumps.”
• You should hear: after the area, questions that narrow — pets, yard or garage, how much space, who is coming with you.
• Then: 566 Placer Street named as the best fit and why, the runner-up named and why it loses, and a visit booked.

Tell us if the dog or the fence gets asked about twice, or the questions start to feel like a survey.

Proves: what you volunteer is written down once and used, never handed back as a question.

5. What does it cost me up front

• Play: you are looking at the Ridgway two-bedroom and want to know what it takes to get in.
• Say: “I’m looking at the Ridgway one, the two-bedroom” → “what do I need up front?” → “any other fees?”
• You should hear: $2,300 a month, deposit $2,500, a $32 background check with the application, and what is included.
• Then: ask about a home whose deposit is not on the listing. She should say so and pass it to the team.

Tell us if any number differs from your own listing, or she produces one that is not published anywhere.

Proves: everything printed on the public card is in her head, and everything else is handed over, not invented.

6. “What’s around there?”

• Play: you like a home but do not know the neighborhood at all.
• Say: “Honestly — what’s around there? I don’t know that part of town.”
• You should hear: groceries, the schools by name, the parks and trails, and how far downtown is.
• Then: notice what she will not do — no rating a neighborhood, no telling you where you would fit. That is deliberate.

Tell us if anything she says about the area is out of date, wrong, or not how a local would put it.

Proves: neighborhood answers are written per home in advance, so the call stays fast.

7. “Can I talk to someone?”

• Play: part-way through, you would rather speak to a person about one specific thing.
• Say: “Is there someone I could talk to?” → give your name → “I want to know about the parking in winter.”
• You should hear: your name and your question taken down, and told plainly that it is going to the team.
• Then: she returns to booking the visit. No transfer, no hold, no promise to call you back, no team member named.

Tell us if she puts you on hold, promises someone will ring you, or lets the visit drop.

Proves: the message reaches the team through one inbox, and the call still ends with a booking.

8. The same call, in Spanish

• Play: a Spanish-speaking caller who would rather do the whole thing in Spanish.
• Say: start in English, then say “español” (or “Spanish”) out loud, and carry on in Spanish.
• You should hear: the rest of the call in Spanish — same questions, same homes, same booking, same confirmation.
• Then: on a different call, never say the word. She should stay in English the whole way through.

Tell us if she switches to Spanish when you never asked, or stays in English after you did.

Proves: the language changes on the caller’s word alone, never on a guess.

What should arrive after each call

• Your phone, within a minute: a text confirming the visit, with the home’s own address.
• The team inbox, one email per booking: who, when, which home, when they want to move.
• A line of what the caller actually said — has a dog · wants a fenced yard · moving end of month.
• Fields we do not have are simply missing. No team member’s name appears anywhere.

Tell us if the address or time is wrong, if something arrives twice, or if anything else goes out at all.

Proves: the text is the template in use today; the team email is being rewritten this week, so its exact wording may change.

How to tell us what you saw

• Use one shared note or one email thread for the whole team. Do not save it all up for the end.
• Four things per call: when you called, which phone, what you played, what was wrong or great.
• Quote her when something is off. “She said $2,700” is worth far more than “the rent was wrong”.
• Say what was good too — we need to know what to keep, not only what to fix.
• You do not need to write down the whole call. We read the recording and the full transcript of every one.

Proves: every call is recorded and transcribed on our side, so the time and the phone number are enough to find it.

Not yet — things to skip

• Video walkthrough: she will not offer one. Ask and she notes it. Visiting in person is the default.
• Two homes on one visit: not built yet. Ask for it and she should say it is coming.
• Calendar invites: bookings reach the team by email. Nothing lands on your Outlook calendar until your Microsoft administrator approves the connection.
• Texting the line: replies to the confirmation text do not reach us yet. Call instead.
• Promises to follow up: she never says “I’ll find out and get back to you”. That is switched off deliberately.

Proves: each is a stated decision or a named blocker, not an unknown — the Microsoft approval is the one thing on your side.

Appendix — the lines, word for word

What the tester says, and what should come back. Homes, rents and fees are today’s live listings.

Proves: every home, rent, deposit, fee and special above was read from the Western Slope account on 2026-09-12; the neighbourhood lines come from the notes written for those exact addresses; the flow is the decided one (§11.22).

The Western Slope phone line stopped ringing our stand-in and started ringing Western Slope’s own company record. Fede called it four times that evening and said what was wrong; the night turned each of those into a change, verified the line against the customer’s own record, replayed every earlier test call and scored it, and recorded a demo he can play to the client. What is left is a short list only he can do.

1. The night in one screen

• The line now answers as Western Slope’s own company, off their own listed homes.
• Call one: a fee printed on the listing was not in her head, and the home pitch ran long.
• Call two never connected. Nothing of ours errored.
• Call three: one garbled word read as Spanish and switched the whole call.
• Call four: she took a message instead of answering, spaced two homes two hours apart, and could not say how long a visit takes.

Proves: each call is a recording with a transcript and the records it wrote beside it; the line’s new record was read back from production.

2. What is live on the line now

• Spanish only on the words “hablas español”; a mis-heard word stays in English.
• She sorts the call first, knows every fee the listing prints, pitches in three short sentences, and never offers a video walkthrough.
• A question she cannot answer goes to the visit — never a message, never a transfer.
• No “the team will get back to you”, live since 1:47 in the morning.
• The team’s email follows the call with that call’s own summary — still delivered to our mailbox, not theirs.

Eight more are built, green and landing this morning, one at a time; two more wait until that queue clears. The appendix names them.

Proves: each live line was heard on a call placed to the number after the change reached production. The queue state is 06:00 Mountain, production 7710a274; the tracker rows move as merges land.

3. What was proven, and how

• Three calls on the customer’s own record came back ready: three defects, none blocking.
• Every artefact a call produced was graded, not just the conversation — that is where the earlier misses hid. The bench’s own judged runs now average 8.0 out of ten.
• Sixteen earlier calls, his and the client’s, were placed again and scored twice: 2.8 out of ten before, 4.8 after; the six on this line, 3.8 to 4.8 (§14).
• Fourteen ran before the night’s biggest fix landed, so 4.8 understates the line.
• A recording of a renter calling the real line, at normal speed and at one and a half times — handed over as paths, because our chat robot cannot attach files.

Proves: the judge ran on the subscription, never a metered key. The replays were real calls, the caller cleared between dials and every visit cancelled.

4. What the company line still does not know

• It is not one missing switch. The company has no settings record, its knowledge record holds office hours and nothing else, and how long a visit takes had never reached the words Clara speaks anywhere.
• Eighteen settings, ordered by how much a caller notices: four already right, eleven unset, one a hole in the code, two go-live steps.
• The row-by-row is §13. Fede confirms one row at a time, and each yes becomes one guarded write.
• Row one matters most: fifteen minutes for a visit, the value Camellia has always used.
• Nothing there was written to the real company or to Camellia.

Proves: every value was read live from production, and every “does the phone script read it?” answer comes from tracing the code that builds a call.

5. What waits on Fede

• Say “texts on”, and attach the company’s own mailbox. The team’s email is written today and delivered to us; attaching theirs is the moment it reaches them.
• Approve the settings rows, starting with a fifteen-minute visit. Each yes is one guarded write; nothing is copied in bulk from Camellia.
• Run the seventy-cent command that fills in what is around their fifteen homes — a customer’s rows and real money.
• Two vendor settings: a maps key for real drive times, and inbound texting on the two phone numbers.
• Three calls outside this line: whether the after-hours fix widens to Camellia, which has the same fault; turning renewals off at Western Slope; and a file-upload permission on our chat app, so the demo audio reaches him as audio rather than as file paths.

Proves: each is a write to a customer’s records, a spend, or a third-party setting — the three a session never does on its own.

6. What the night taught us about how we work

• Changes to what Clara says merge one at a time. Two at once rewrite the same file and silently cancel each other.
• Merge state is read from the repository, not the vendor’s interface. Polling burned the shared hourly budget three times and the watchers went blind silently.
• Every pull request carries its plan, its proof and its channel answer, or a check holds it — and only a fresh push makes it re-read.
• A rule that lives only in words is not a rule. One switch forced a feature on at every test property before it read the setting.
• Machines and accounts have ceilings, and we hit both. Report and work around; never retry in a loop.

Proves: each lesson traces to something that broke tonight: a cancelled merge, three exhausted budgets, five pull requests held an hour, a stray text, a machine out of memory.

7. Appendix — every change this night touched

Work on the phone line and the Western Slope company only; the rest of the repository’s night is not listed here. Live is on the main line and serving callers. In the queue is built and green, landing this morning one at a time. Parked is deliberately set down. The queue state is as of 06:00 Mountain on 13 September, with production serving 7710a274; the rows on the Western Slope go-live page move as each one lands. Two more changes are written and held back until the queue clears: the two-home pitch, and routing after-hours callers to leasing before any message is taken, on company-wide lines only.

Proves: every state above was read from the repository’s own history and from each request directly, not from a polling watcher — those had gone blind on their hourly budget three times that day. Everything live shipped switched off or invisible to a real caller; turning any of it on at Western Slope is a separate step and Fede’s call.

• The twenty rules are the ones he dictated on 12 September, already in the bench suite — nothing was re-invented.
• On top of them the judge carries how he actually reacts: what he calls a miss, what he calls a bug, and the fact that “but it’s fine” is approval.
• Each call gets one score out of ten and a two-sentence verdict written the way he would say it.
• Both halves of every comparison run through the same judge, so a change in the number is a change in the line.

Proves: the judge ran on Fable 5.1 on the Claude subscription; no metered key was read. Each verdict carries the line it was read off, and a verdict with no quote is discarded rather than believed.

So 4.8 understates where the line is now. Three more changes Fede asked for were still waiting to merge when the batch finished: asking mornings or afternoons before naming times, taking the name early, and asking when they need to move. Those three are the top three rows of what is still wrong below, which is what you would expect if the measurement is honest.

• Asks mornings or afternoons, then offers a couple of concrete times — still on 9 of 16 calls.
• Asks when they need to move — and how firm that is — before naming any home — still on 8 of 16 calls.
• Never says the team will reach out, or that she will find out and get back to them — still on 6 of 16 calls.

Fede asked for the paperwork to be graded too, not just the conversation. Ten of the sixteen replays booked a visit; eleven wrote a prospect card.

• All 10 booked visits now carry the caller’s name. On his own call last night that was blank.
• None of them reached a calendar — 0 of 10. The company record still has no calendar connected, so a caller is told a time nobody will be at.
• The prospect card is written and it is good: all eleven carry the name, nine carry the bedroom count, and each one summarises its own call.
• The move-in field takes prose where a date belongs — four of the seven that carry one read “pretty flexible”, “next week”, “ASAP”, and one that reads “September 4”, a date already past.
• Every visit was booked as 30 minutes. Camellia uses 15; this company has no length on file, so a default nobody chose is what callers hear.