Knowing when not to answer

Clara answers every message she receives — including "thank you", goodbyes and thumbs-ups — and sometimes repeats what she just said. This page explains why, how often it happens in production, and asks you to pick a fix.

2026-08-28, revised 2026-08-29 · Status: Proposed — pending review · Evidence: full production sweep (read-only), code trace of the incident thread, and a live reproduction during the investigation

Goal

The bar we should hold her to is the one a good leasing agent holds: when someone says "thank you" and everything is handled, a person puts the phone down. They do not send "you're welcome — anything else?" That reply costs nothing to send and quite a lot to receive; it is what made the prospect in this week's incident write "you will always sound like a bot."

Strategy

Three commitments, in order. They matter more than the individual fixes, because they decide which of the options below actually fit together.

1. Give her the ability before you tune the judgment. Every prompt we write telling Clara "don't reply to a closer" is currently unenforceable for a prospect: there is no action she can take that means "send nothing." Ability first; taste second.
2. Put the last word in one place that every message passes through. Today a message can leave the building through at least three different doors, and the checks on each door are different. A necessity decision that lives in only one of them will be right most of the time and quietly wrong on the rest.
3. Nothing on a timer sends blind. Decided by Fede, 2026-08-28. Every automated follow-up must check what is happening in the conversation at the moment it sends — not just the database fields it was built to read. This one is settled; only how to build it is open (number 3 below).
4. Prove it in the lab before a real person sees it, and prove the failure first. The risk of a silence rule is not that it is annoying — it is that Clara goes quiet on someone who asked a real question. So the rule ships behind a test that first reproduces the bad behavior on the real incident thread, then shows it fixed, and it ships on texting only until that test has run for a while.

What is actually going wrong

She cannot be silent — for prospects, literally

Every incoming message wakes Clara up and makes her write something. We did build her a way to end a conversation on purpose, and we wrote good instructions telling her when to use it. But that ability is only handed to people we have already matched to a lease. Someone shopping for an apartment — exactly who was in this week's incident — never gets it (capabilities/index.ts:167-168, verified). For that group, silence is not a hard choice, it is not a choice at all.

And if she somehow wrote nothing, the system does not stay quiet: it fills the gap with a canned apology — "I'm sorry, I wasn't able to generate a response…" — and sends that instead (conversation-manager.ts:8886-8892, verified). Producing nothing is treated as a malfunction, never as an answer.

The one brake we built cannot reach the pedal

There is a circuit-breaker meant to stop an endless goodbye loop. It only trips when Clara's own last two messages were pure pleasantries with nothing in them. Her house style is to always tack a next step onto a sign-off — "talk to you tomorrow", "see you Friday at 11:45" — and the breaker counts a weekday, a time, or the word "tomorrow" as content (guards/farewell-loop.ts:82, verified). So her goodbyes never qualify as empty, the counter never reaches two, and the brake never fires. It is also only wired to incoming messages; none of the automated follow-up sequences ever consults it.

Nothing tells her not to repeat herself on text

The rule "never repeat yourself" exists — in the phone-call instructions only (clara-delivery.ts:252, verified). Texting and email have no equivalent. A separate rule pushes the other way, telling her never to claim she already answered something. And nothing anywhere compares a message she is about to send against one she just sent: there is no such check on the texting path at all.

Her own automated follow-up texts are deliberately hidden from her (context-message-filter.ts:53-58, verified) — a fix for an older bug that has created its mirror image. A reminder goes out making a promise, and on her next turn she cannot see that it was sent, so she makes the same promise again.

How widespread it is

We read every real text and email conversation in production — 174 of them after excluding test properties and voice-only records, essentially all at one property, 7,619 messages. Read-only; nothing was written.

The damage concentrates. It is not a light drizzle across every thread — one conversation, the Section 8 prospect at Camellia (conv a05c3c99…), holds 7 of the 16 pointless replies on its own. That is the shape of the problem: mostly invisible, then catastrophic in the one thread where somebody is already unhappy.

Is this new? No — with one exception

The obvious suspicion was that we broke something recently: we moved Clara's texting and email drafting onto a newer, reason-first model on 21 August, and raised how hard it thinks on 28 August, about seven hours before the incident. We tested that directly against the corpus, bucketing every message by its own timestamp.

August looks worse only because of concentration: 7 of its 10 pointless replies are the one incident thread. Remove that thread and August is 89% — in line with June and July.

• Answering goodbyes is original design, not a regression. The first case in the data is 22 June 2026, three weeks into the earliest real texting traffic. Every month with any goodbye traffic shows it. In the whole corpus she correctly ignored a closer only 4 times, spread evenly across all three months.
• The model change is ruled out at the boundary. Reply-to-goodbye was 83% before the 21 August model switch and 83% after it. Nine of the earlier pointless replies predate that model entirely, four of them from June. A behavior present in June cannot have been introduced in August. The 28 August effort increase has only six hours and forty minutes and one conversation behind it, so it is honestly untestable here — not exonerated, just unmeasurable. Practical consequence: routing cheap turns to a cheaper setting is a cost-and-speed lever, not a fix for this.
• One shape genuinely is new: the repeated status line. Telling the same person more than once that she has checked with the team and will follow up tomorrow appears exactly once in the entire corpus — 28 August, the incident thread — and it started 55 seconds after an escalation record was opened on that conversation. Every earlier "I'll check with the team" message in the data was said once and never repeated. That machinery only began writing records on 14 August. This is a strong lead on a single case (n=1), not a proven rule.

The yellow dot — the straight answer

On the two dotted messages in the incident thread (4:34 PM and 4:43 PM Mountain), it was the promise-backing check: Clara drafted a version of "I've checked with the team, I'll get back to you", the check found nothing tracking behind that promise on that turn, and it swapped the clause for "I don't have that answer on file right now." Both delivered messages carry that substitute sentence word for word. So: the check caught something, a message did go out, but what went out was the rewrite.

Two things are genuinely wrong here, though, and they are not what the dot suggests. First, the dot is the same colour whether a message was withheld or merely rewritten — the underlying field is called "blocked" in both cases, which is why the app reads as more alarming than the event was. Second, and worse: the rewrite made the message sound like a robot. "I don't have that answer on file right now" is a phrase no person would say, and it is a fair candidate for the line that triggered the "you sound like a bot" reaction. Our safety checks are allowed to change what Clara says; they should not be allowed to make her sound like a form letter. That is Decision 6.

It happened again while we were investigating it

The sequence, all from production, the night of 28–29 August (times in UTC; local was late evening in Denver):

• 02:26 — the correct voucher answer finally reached him, sent with a person's approval, and the open question was closed.
• 02:27:14 — he replied "Thank you so much". That message is a contentless closing by the production guard's own definition — the brake we built for exactly this case looked at it and had nothing to act on, because the brake needs Clara's previous two messages to have been empty pleasantries too.
• The live loop answered him: "You're very welcome, [name]! Good luck with your application — reach out anytime if you need anything else." Nothing new in it — one more pointless reply in a thread that already held seven of them.
• He sent a smiley. Clara sent a smiley back. The same emoji-mirroring exchange that, on our own internal number, ran to 2,767 messages (Appendix C).
• 02:31 — "I need humans to come back".

And then the one lane that does have a working state check did its job. Clara escalated the thread to a person herself, the conversation went human-owned, and when he followed up — "Is your team comprised of humans or ai?" — the system correctly sent nothing and left it for a human. That is silence, chosen and held, on the only path where the machinery is actually wired to conversation state.

Which is the argument of this whole document, demonstrated twice in five minutes: where a check reads what is happening in the conversation, Clara behaves like a colleague. Where no such check exists, she cannot stop talking.

What the rest of the industry does

Before proposing anything, we checked how mature conversational products and the research literature handle "should I answer this at all". Four things came back consistently.

Closing a conversation is a recognised, labelled speech act — not a vibe. Deciding what job an utterance is doing (a question, a statement, an acknowledgment, a goodbye) is a standard, decades-old classification task with public benchmarks; conversational-recommender work routinely uses an explicit "goodbye" class alongside greeting and follow-up. The classic conversation-analysis result behind it is that people do not just stop talking — they run a short, recognisable closing ritual, and a "terminal exchange" ("bye" / "bye") is its final move. In other words: "thank you" then "you're welcome" then silence is the correct human script, and Clara is inserting an extra turn after the script has ended.

Commercial support tools treat "no follow-up" as a first-class setting. Intercom's Fin lets you choose, explicitly, what happens after it answers — check in again, offer a human, or send no follow-up at all — and it can close a conversation on a positive closer like "that helped, thanks" rather than replying to it. Bot-building platforms document "respond only to valuable messages", where greetings and acknowledgments such as "thanks" or "okay" are classified as low-priority and skipped by design. Nobody mature ships an always-reply loop.

Reaction texts are a known category of noise, and the platforms fixed them by filtering. When an iPhone user taps a thumbs-up on a message to a non-Apple number, it arrives as a separate text reading 👍 to "…". Both Apple (from iOS 16) and Google Messages solved this by recognising the pattern and rendering it as a reaction instead of a message. The industry answer to a tapback is to convert it to metadata — never to reply to it. We reply to 2 out of 2.

Self-repetition is a known failure mode of generated text with known countermeasures. The research literature treats repetition as a degeneration problem and applies explicit blocking of previously-produced phrases, repetition penalties, and training-side fixes; surveys of neural conversation models list self-repetition as one of the standard failures needing a deliberate fix. The recurring warning is that blanket penalties damage text that legitimately repeats (names, addresses, links) — so the useful version compares a new message against her own recent sends, not against everything.

One boundary worth stating: the messaging-compliance world (quiet hours, contact frequency) already gives us ceilings on volume and timing, and we implement them. None of them help here. A reply to "thank you" at 4pm is perfectly legal and perfectly unwanted. Necessity is a separate axis from compliance.

The decisions

Four picks left, each with a recommendation. Six things are already settled — the global silence ability (1), conversation-aware follow-ups (3), the takeover rule (3d, now its own page), what an empty reply means (4), one shared closing behaviour for texting and email (5), and promised deadlines (9, now its own effort) — and one turned out to be plain defect work rather than a choice (2). Take the recommendation on the remaining five and the result is a coherent package; they were chosen to fit together.

Appendix A — where the safety checks reach, and where they do not

There is no single door every message leaves by. There are three, they overlap unevenly, and this table is why a necessity rule has to be placed deliberately rather than wherever is convenient.

Appendix B — the promise check is inconsistent, and it is a punctuation bug

Worth reading even though it is not the over-reply problem, because it is what made the incident thread look arbitrary from the outside.

In the same conversation, the same promise — "I've checked with the team, I'll follow up with you tomorrow" — was rewritten twice and delivered untouched three times. Two separate causes, both verified:

• An em-dash defeats the detector. The check splits a sentence on dashes and semicolons before looking for a promise. With a comma, "I've checked with the team, and I'll follow up tomorrow" is caught. With an em-dash, the sentence is cut into two halves — one has the subject and no promise, the other has the promise and no subject — and neither half matches. We confirmed this by running the real detector against the actual delivered text. Clara writes em-dashes constantly, so this is not a rare edge case. Fixing it is not a one-liner: the split exists to prevent a known class of false alarm.
• "Backed" does not mean what it sounds like. The check never looks at whether a tracked follow-up item actually exists. It passes only if a record-writing tool fired on that same turn, or the thread is flagged as escalated right now. In the incident there was an open item, owned, with a next-day deadline — and the thread had been flipped back to "active" about a minute before the turn ran. So a genuinely-backed promise read as unbacked, and Clara was made to sound less on top of it than she actually was.

Net: the two catches were correct by the rules as written; the three passes are the bug. Both defects deserve their own cards.

Appendix C — flagged bug: Clara has been texting herself since May

There is no customer in it. It matters because it is the same missing rule with nobody on the other end to stop it: two of our own lanes replying to each other, forever, because neither one can decide that a conversation is over. It is also the clearest possible argument for putting the necessity decision at a point that catches machine-to-machine loops, not only human closers.

Sources

Production numbers come from a read-only sweep of the live database on 2026-08-28 (1,619 conversation records enumerated, 7,619 messages read, test properties and voice-only records excluded). Code references were read directly in the repository and are quoted with file and line. Industry references:

• Schegloff & Sacks, "Opening Up Closings" (1973) — the terminal exchange, and why a conversation is closed rather than merely stopped
• NLP-progress: dialogue act classification — labelling an utterance by the job it does (statement, question, acknowledgment, goodbye)
• Personalization and Evaluation of Conversational Information Access — an explicit "goodbye" act alongside greeting and follow-up in a conversational system
• Intercom — deploying the Fin AI agent and auto-closing conversations — "send no follow up" as a supported end-state; closing on a positive closer
• Chatbot Builder — respond only to valuable messages — greetings and acknowledgments classified as low-priority and skipped
• iOS 16 tapback handling and Google Messages reaction conversion — the platform answer to a reaction text is to render it as a reaction, never to reply
• Welleck et al., "Neural Text Degeneration with Unlikelihood Training", "Taming Repetition in Dialogue Generation", and "Neural Conversation Models and How to Rein Them In" — self-repetition as a named failure mode, and the trade-offs of blocking repeated phrases
• TCPA texting rules, 2026 — quiet hours and frequency ceilings; relevant as a boundary, not as a solution to necessity