Messy input is on us
The operating principle for how Clara turns whatever a property hands us — rambling policies, typos, tribal knowledge — into short, right-sized answers on every channel. Set by Fede, 2026-08-28.
2026-08-28 night · Principle ADOPTED · nine approaches measured · LIVE-CALL ROUND COMPLETE — winner below, awaiting Fede’s pick
TL;DR — revised after Fede's namespacing challenge (Aug 28, late night)
- What the live round proved: on a dedicated, single-property agent, auto-cleaned facts in the platform's knowledge slot (all loaded up front) were the fastest to first word of six setups — 1.47s typical, 1.84s worst-case, no added latency — with a fully automated cleaning step and an 11k-character (16.7%) lighter prompt. Mid-call retrieval is rejected: one real call stalled 12 seconds.
- What it did NOT prove — and why adoption is now gated: the knowledge slot attaches to an agent, statically. Today Camellia and Yale answer on the SAME agent — property identity arrives per call from our webhook. A static per-agent doc cannot tell those callers apart; the round never tested multi-property. Also: average words/reply stayed flat across all six setups (the rambling cure is a separate behavior fix), and the sample was 3 calls per setup.
- Revised recommendation: (B) architecture yes, ship gated. Adopt the slot+distiller design only where an agent serves ONE property (Willows-style dedicated fleets); shared agents keep today's per-call injection until the namespacing decision is made (dedicate an agent per property, or keep injection there permanently). Gates before any live change: multi-property leakage test on the harness, a bigger call sample, and the rambling dial iteration.
- Your pick below: A adopt now (no longer recommended as-is) · B gated adoption (recommended) · C bigger sample first.
The 10,000-foot view
Messy property notesPropFlow DB · per property
↓
Auto-cleanerAI rewrite · no fact ever dropped
↓
One clean copy per propertystored in our DB
↓
Voice · dedicated agentknowledge slot, loaded up front✓ tested live — fastest
Voice · shared agentkeeps per-call injection⚠ namespacing unsolved
SMS · Email · Telegramclean copy injected per message✓ same mechanism as today
Live data — today’s availability, tour slots, the caller’s own context — is always injected fresh, never stored in a document. Mid-call lookup is rejected: one real call stalled 12 seconds before speaking.
"We should be able to survive in the real world with messy policies, typos, long explanations — and have a way to cut the noise — not rely on clients having perfect policies to fit different channels like voice and text." — Fede. The burden of messy reality is PropFlow's, never the client's. Corollary, also his: tune how the agent behaves; don't over-engineer; don't guess — check how the industry solves this.
Live-call round result (Aug 28 night) — the winner, and your call
The recommendation, one line: put each property’s facts in the phone platform’s own knowledge slot, all loaded up front (no mid-call lookup), auto-rewritten answer-first by the distiller — it was the fastest setup to the first spoken word on real calls, including worst-case, and it’s the scalable one.
Six setups, three real phone calls each on the test line, multi-turn with real tool use (booking a tour, checking availability). Speed = time until Clara’s first sentence starts, from the platform’s own turn metrics. Today’s production setup pastes all facts into the instructions; “knowledge slot” moves them into the platform’s dedicated store.
| Setup | Typical start of speech | Worst case (p90) | Avg words/reply |
| WINNER — auto-cleaned facts in the knowledge slot, all loaded up front | 1.47s — fastest | 1.84s — fastest | 34.6 |
| Test copy of today’s production setup | 1.56s | 1.86s | 33.2 |
| Raw messy facts in the knowledge slot, loaded up front | 1.59s | 2.00s | 31.9 |
| Raw messy facts, looked up mid-call | 1.64s | 2.04s | 35.5 |
| Auto-cleaned facts, looked up mid-call | 2.58s | 12.1s — disqualifying stall | 35.3 |
| Live production line (reference) | 1.89s | 2.14s | 36.8 |
- Why the winner wins: it met the hard rule — no added pause before Clara speaks (if anything slightly faster; differences under ~0.1s are noise at 3 calls per setup) — while carrying the two structural gains: the instructions shrink by ~11,000 characters, and the fact-cleaning step is fully automated (an AI pass rewrites messy notes “short answer first, details on request” and hard-fails if any dollar amount, percentage, or time goes missing). No hand editing, ever, for any property.
- Why mid-call lookup is out: one real call stalled 12 seconds before answering — exactly the added-latency class the hard rule forbids. Tails like that are what real callers feel.
- Honest limits: reply lengths were near-tied across all setups on full calls (greeting and booking chatter dominates), and the one known rambling defect — reciting the whole utility-provider list when asked about costs — survived in every setup. The winner is the right architecture; the rambling cure is the next iteration (sharpen the “quick answer” tier of the distiller + the answer-behavior dial), tested on this same harness. Also: three calls per setup is a small sample; and the round caught a real product bug — Clara confirms a tour that never lands in the system (reproduced twice, independent of setup; needs its own fix).
Your call — pick one: (A) Adopt now — no longer recommended as-is: Camellia shares its agent with Yale, and per-property namespacing on shared agents is untested. (B) Gated adoption (RECOMMENDED) — adopt the architecture for dedicated-agent properties only, behind the namespacing decision, a cross-property leakage test, a bigger call sample, and the rambling fix. (C) More evidence first — a bigger call sample before any change. Nothing ships until you answer.
Due diligence — what the round tested, what it did not, and the gates
Two of Fede's questions from reading this page were the right challenges, answered here plainly.
“How does the winner actually work?” When a call starts, the platform pastes the property’s cleaned document into the model’s context — once, up front, nothing fetched mid-call. It is the same shape as today’s injection, but the platform owns it, it lives outside our 67,000-character instructions (the platform’s own guidance: shorter instructions start speech sooner), and on real calls it measured slightly faster to the first word than today’s setup. There is no lookup step to stall — that’s the whole trick, and why the rejected retrieval flavor (which does look things up mid-call) produced the 12-second stall.
“Why did average words per reply stay the same?” Because that average counts every reply in the call — greetings, collecting a name, confirming the tour — and those are near-identical in every setup, drowning the one verbose defect. And in full-context mode the model still sees the details tier of the cleaned doc, so on the utilities-cost question it still recited it. Moving the knowledge changes where facts live and how fast speech starts; it does not by itself change how much of them Clara says. That is the behavior dial — a separate, already-scoped iteration on this same harness.
Nothing has shipped. All 21 round calls ran against throwaway clones on the test line, which is verified restored to its normal routing. The winner is validated as an architecture for the dedicated-agent case only — exactly what option B gates.
What's already known (measured or verified — not opinion)
- Brevity rules alone barely work today: a scoping rule + token cap on the live voice prompt cut spoken length −5% (voice-verbosity report, §8b).
- Reshaping what's presented works: headline-first, details-fenced content cut −19% overall, −39/−49% on the worst lanes, zero dropped facts. Held as a candidate stop-loss, not shipped — hand-shaping content is not the long-term strategy.
- A prompt diet was already done and got eaten: shipped 2026-07-21 (14.1k → 11.4k est tokens); the live prompt has since regrown to ~17k (+49% in five weeks). Accretion, not absence of dieting, is part of the story (verified in git, 2026-08-28).
- Per-question knowledge retrieval was tried before and increased latency (Fede, from prior work). Not a fresh idea; any revisit must beat that latency history on the harness.
Final standings (all nine approaches measured, 2026-08-28 evening)
- Native retrieval, properly indexed — the facts winner: −14% words and the ONLY arm with zero newly-dropped facts; it also FIXED the two questions the live agent fails today and passed the hard move-in-cost question with both dollar amounts intact. Mechanism: retrieval shows the model only the passage that answers the question — the platform natively does what manual restructuring does by hand. (The earlier "retrieval disqualified" verdict was measured against an UNINDEXED document — uploads do not index automatically; the sync must trigger it. Found by the kb-sync POC, verdict corrected same day.)
- Hand-restructured content — the length winner: −19%, zero rambling leakage, one hard-question fact miss (the physical-floor lane).
- Native full-context KB: −14%, clean facts, no retrieval in the loop; cuts the served prompt by ~19k chars (POC-measured −22% of per-call prompt).
- Everything else measured and beaten: colocated rule −11%, exemplars −5.5%, rules −5%, diet −1%, Sonnet-5 arm disqualified (drops money facts).
- Composed candidate: restructured (progressive-disclosure) content LIVING in the native KB — untested as a combo; strongest theoretical profile.
- Latency: retrieval shows ~+10% in simulate (consistent with the documented ~250ms); the binding number for every contender remains time-to-first-word on a REAL call — the robot-call round, awaiting Fede's go, should race all three finalists.
What the industry actually does (researched 2026-08-28, sourced)
- The pattern has a name — "progressive disclosure." EliseAI's own voice docs: "instead of giving long-winded answers to simple questions, VoiceAI shares several key details then offers more information if needed," paired with guidance to keep source knowledge concise. Short answer first, depth on request — at the knowledge layer, not as a brevity rule.
- Nobody trusts messy documents alone. Every credible competitor has a human checkpoint: EliseAI pre-fills a structured table from the property website and human-approves AI-suggested edits; Zuma pulls structured PMS data (built internal cleaning tooling — "the systems… did not have clean data") and gates unstructured docs behind manual upload; AppFolio "retains a staff of operators" re-labeling live AI conversations. The only "upload docs, AI trains itself" pitch (Rently) has no voice product.
- Platform guidance matches our measurement. ElevenLabs documents per-question retrieval at ~250ms/turn added (why the earlier attempt was slower — expected behavior) and recommends full-context injection with well-structured content for KBs our size; prompts over ~2k tokens add latency (ours: ~17k and regrowing). Retell documents headline-first, question-per-heading KB authoring as standard practice. OpenAI + Vapi both document that positive exemplars beat rules for spoken length/style.
- Caller-experience nuance (Funnel's 169-renter blind study): what renters hate is being talked over and "never getting a direct answer" — length is partly a proxy for directness. Turn-taking + answer-the-question-first matter alongside brevity.
- Full sourced reports (per-company findings, platform docs, papers) live in session 004's research transcripts; citations available on request.
Converged recommendation (simple, all testable on the existing harness)
- 1 · Progressive-disclosure knowledge: entries authored headline-first with details fenced; kept in full context (no retrieval, no added latency). The "distiller" is just the ingestion step that produces this shape from messy client input — AI-drafted, human-approved, EliseAI-style. Scales per property automatically.
- 2 · Positive exemplars in the prompt: 2–3 worked examples of the target answer length/shape — the best-documented untested lever, and the likely fix for the −5% rule flop.
- 3 · Prompt diet with a fence: shrink toward the platform's ~2k-token guidance and put prompt size + words-per-turn on the weekly scorecard so accretion (+49% in 5 weeks) can't silently return.
Decision discipline
- Every candidate mechanism must pass the deterministic gate: shorter spoken answer, zero dropped facts, zero clipping — on the L1 simulate harness before any live caller hears it.
- Latency is a HARD constraint, stated by Fede 2026-08-28: "whatever we do (like test sonnet 5 is fine) i just dont want to increase latency." The binding number is time-to-first-word on a REAL call — the simulator does not measure it, so no candidate ships on simulate evidence alone. Prompt slimming is latency-positive per platform docs (prompts >~2k tokens add latency); content restructuring is latency-neutral by construction; any model swap must prove its live first-word delay before shipping; per-question retrieval stays ruled out (+250ms documented).
- Words-per-turn joins the weekly voice scorecard so this class of drift is caught in a week, never re-noticed after six.
- Nothing ships without Fede's explicit go; the −19% restructure stays a held stop-loss option.
Boundary: voice model/effort choices are unchanged by this page (voice stays Sonnet 4.6 / low — latency-bound, and the channel where Sonnet 5 measured worst). Any voice-side guard remains bound by the zero-added-latency rule.
Related: voice-verbosity-report-2026-08-28 · effort-sweep-email-sms-2026-08-27. This page will gain the research findings and the matrix verdict, then the chosen mechanism.