Who Clara's messages come from: the sender audit

The rule

"It should be from Clara at Propflow for internal team notifications. And it should be leasing outside to prospects, not internally." · "Seems like we have too many places that decide what email to send it from."

Fede, 2026-11-03

• Customer's own team (org admin, PM, leasing agent, maintenance, ring list, tour host, escalation owner): from clara@propflowai.co.
• Outside people (prospects, applicants, renters, vendors): from the customer's connected mailbox, so the thread lives in their shared inbox.
• Who someone is comes from their roles at the company, looked up by the sender seam itself. Never a per-call flag, never "same email domain as the mailbox".

The two cases

What production did, last 14 days

Every email to a customer-domain address (Western Slope, Situs Group, Camellia / JP&Co), with the sender inferred from the message id each door stores. Calendar invites are not in this log.

The Miriam send happened after the window closed and is counted under the cases above. Checked separately: the Situs mailbox's Sent folder holds exactly one email to Miriam since Nov 2, the hand-run one; Clara's own automatic reply to her at 22:22Z did not go from that mailbox. Per-row evidence is in the appendix.

Every place that picks a sender

Email, in plain words

• Notices (call summaries, tour alerts, lead notices, digests, approvals, emergencies): one sender with Clara at Propflow as the default. Every staff notice is right today. (79 staff send sites in all; the 5 wrong ones are the reply paths below.)
• Replies through the property router: building mailbox, else company mailbox, else SendGrid. Every input is about mailboxes. Five reply paths put staff through it: the shared-inbox reply, the clara@-lane fallback, an approved held reply, the held reply's draft row, and the shared reply router behind them (the root).
• "Role known, then ignored": the shared-inbox reply looks the reader up as staff, uses the answer only to pick a plainer template, and still sends from leasing@. It also counts "same domain as the mailbox" as staff, which is a stand-in, not a role.
• The one right path: a staff member writing to clara@ gets a reply hard-wired to Clara at Propflow. It sits outside the router.
• Second copies of the mailbox rule: lead follow-ups and turnover vendor emails each carry their own. Turnover vendor mail at Western Slope and Situs goes out from Clara at Propflow today, the reverse mistake.

The full per-point table (file and line, inputs, role awareness, verdict), the texts, voice and calendar tables, and every search pattern used are in the appendix.

The fix: one seam

• Becomes pass-through: the three staff flags (internalRecipient, audience, recipient.isStaff) stop deciding anything about the sender.
• Covered with no change of their own: approved held replies, the clara@-lane fallback, and every hand-run script that uses the router.
• The shared-inbox Lambda keeps its own wire for threading; it drops the domain shortcut and branches on the same lookup, sending staff the way the staff turn already does. One decision function, two callers, until the Lambda moves onto the router.
• Ships as a behavior fix to live Clara: no switch. Proof: replay of the Miriam thread and the five reply paths, then a real staff email at Willows, then the Kat case re-run.

Before → after

Follow-ups

• Fix in flight, PR #25042: one role lookup at the top of the router; replay of 196 delivered emails (Nov 2 to 4) moves only Kat's Zoom link and the Miriam thread to Clara at Propflow, every outside send unchanged; Willows live run done (staff email from clara@propflowai.co, prospect email from the Willows leasing mailbox).
• Ruled by Fede (Nov 3 night, "Clara at Propflow. Propflow."): shared-inbox replies to a teammate also come from Clara at Propflow. PR #25061 removes the Aug 9 restriction and branches that reply step on the same role lookup; armed for the merge queue. Replay of 123 shared-inbox sends over 14 days found none to a staff role (staff mail into that inbox has been skipped as coworker mail since Aug 20), so this is the guardrail. First production proof: a sender_door_chosen line in that step's log after deploy. Fede: staff don't write there; if they do, an earlier send from leasing@ was wrong.
• Sender display name: other staff emails still show "Clara", not "Clara at Propflow". Same-domain-counts-as-staff shortcuts remain in two escalation and team-notify files; both are on the staff-reply refactor design's deletion list (clara-coworker-loop-v3-2026-10).
• Superseded: the shared-inbox reply step (the Lambda) is NOT in the PR. A permanent test from Aug 9 forbids any send from Clara at Propflow in that file, which clashes with the Nov 3 rule. Until he rules, a staff member who writes to the customer's shared inbox still gets Clara's reply from that inbox.
• Trace Kat's Zoom link (Western Slope, Nov 3 16:06Z): which path wrote it, since no code on main writes that subject.
• Issue #25035: Clara's staff replies should name the company's Clara line (Miriam's "is there an app" question).
• Takeover skill: the email recipe must route staff readers through the staff door; one-off scripts under scripts/_*.ts are gitignored and never meet CI.
• Turnover vendor emails go out from Clara at Propflow today, the opposite mistake (vendors are outside people). Own fix, with the lead follow-up bypass, both onto the router.
• The delivery log does not store the sender address. Add it, so the next audit reads it instead of inferring from message-id shapes.
• Two canary scripts can send from a real customer mailbox with no test-property check.
• Texts: the AppFolio text door trusts a caller flag the same way; if texts ever follow the rule, same lookup. Open for Fede only if it matters: do staff texts need a separate line, or is the shared Clara line fine?
• Owner reports (2 sites): are owners "internal"? Unclear until Fede says.

Where Clara decides who a message comes FROM (decision-point audit, 2026-11-03)

Read-only. Repo ~/.claude/propflowai at e1d7fe14 (origin/main a23571aa differs only in CI-cost and fallback-call files, none on a sender path). Nothing edited. Companion to notification-inventory.md (the 109 send sites, ids W1-W6 / U1-U7 used below).

Rule checked: the customer's own staff hear from clara@propflowai.co (SendGrid). The customer's mailbox is for outside people only.

The answer in brief

• Email has 24 places that touch the from-identity. Nothing inside the property router reads the recipient's role. The one path that picks clara@ because the recipient is staff (the staff email turn, E16 → E17) sits outside the router.
• Three "this is staff" signals exist (internalRecipient, audience: 'staff', recipient.isStaff). None reaches the rule that picks the mailbox. They steer the template, the contact limit and the not-live hold.
• Two places do a real role lookup (the shared-inbox Lambda, the staff email turn). Only the staff email turn acts on it for the sender. The Lambda looks it up and then sends from leasing@ anyway.
• A likely source of today's Situs email: a one-off script dated today (X1) that emails a Situs PM through the router from the Situs mailbox, following the clara-takeover email recipe. Whether it was run with --send is not verified. The other candidates are W2/W3 from the inventory.
• Staff only get clara@ today because staff *notices* use a different function (sendEmail) that defaults to clara@. Any staff mail that enters the property router instead comes out from the customer mailbox.

Email decision points

"Role?" = does this point know whether the recipient is the customer's staff. "Staff on customer identity?" = can a staff recipient come out of it sent as the customer (leasing@, camelliaapts@, or a building's own SendGrid identity).

Not decision points (checked): every tellStaff / sendOrHoldTeamNotice / team-notification / sendRecapEmail caller (all inherit E8's clara@); the 17 other sendPropertyEmail callers (all address outside people and inherit E6); the SES conversational adapter agents/clara/lib/messaging/adapters/ses-email.ts:346 (dormant, U7; no SES send command exists anywhere in src/agents/lambda).

How the email points feed each other

• Notices: caller → tellStaff / sendOrHoldTeamNotice / team engine / sendRecapEmail → E8 → clara@. No choice is made; the default is right.
• Router: caller → E6 → E4 + E5 → E2 → E1 (+ E3 failure rule) → Graph / Gmail (E22) / SendGrid (E7 → E8). Every input is about mailboxes. The recipient's role never enters.
• Replies to people who wrote in: E23 picks the lane.

- Shared inbox → Lambda → E11 → E10 (→ E4) → E12 computes "staff" → E15 → E13 → customer mailbox. Role known, ignored for the sender. - clara@ → E16 → staff turn → E17 → clara@ (correct). Or sesDeliver → E14 → E6 → customer mailbox (role never resolved). - A held reply → E19 → hold row → E18 → E6 → customer mailbox.

• Bypasses that copy E1's rule: E20 (cadence) and E21 (turnover). Neither serves staff today, but each is a second copy of the mailbox rule that a future staff send could inherit.

Text decision points

Clara's Twilio lines are numbers PropFlow owns, one per building or company. Staff texts leave on the same line prospects text, so no staff text comes from a customer mailbox-style identity. The one real customer identity on texts is the company's AppFolio text door (texts sent from the customer's own PMS number). The dispatcher keeps staff off it, but only when the caller *declares* the recipient is staff.

Voice decision points

Calendar decision points

Verified (event-types.ts read directly): no calendar event the app writes has an attendee, so no invite goes from a customer mailbox to anyone. CalendarEventSpec (src/lib/domain/calendar/engine/event-types.ts:75-88) has no attendee field.

Tooling and one-offs that pick a sender

scripts/_*.ts is gitignored (.gitignore:370), so one-offs never meet CI or the send-door registries.

Slack and other staff channels: Slack posts use PropFlow's own bot identities. None of them poses as the customer. Not enumerated.

Count

Completeness check

Grep patterns used (ripgrep -M 300; skipping tests, dist, maps, node_modules, json, md; --no-ignore for gitignored scripts):

• Email: fromEmail\s*:|fromName\s*:, fromAddress\s*[:=], ['"\]From: , CLARA_EMAIL, sendGridSenderIdentity, selectSendMailbox, chooseMailbox, resolveCompanyMailboxToken, resolveReplyMailbox, resolveSiblingRootMailbox, getValidEmailToken\(, createInboxClient\(|new MicrosoftInboxClient\(|new GmailInboxClient\(, \.sendReply\(|\.sendNewMessage\(|\.sendMail\(, /sendMail|/reply|/replyAll|/createReply|messages/send|gmail\.users\.messages\.send, sendFromGmailCompanyInbox\(, sendPropertyEmail\(|sendPropertyReplyEmail\(, sendClaraProspectEmail(ViaAdapter)?\(, SendRawEmailCommand|SendEmailCommand|client-ses, @sendgrid/mail|sgMail|api\.sendgrid\.com/v3/mail, isStaff|internalRecipient|audience`.
• Text and voice: messagingServiceSid, messages\.create, calls\.create, agent_phone_number_id|agentPhoneNumberId, callerId(E164)?, outbound[-_]call, resolveOutboundAddress, claraNumberForProperty, PROPERTY_TO_PHONE_MAP, TWILIO_PHONE_NUMBER, smsFrom, fromNumber, claraLineForBuilding, resolveStaffLineAndThread, resolveManualSendFromNumber, handoffShows, process\.env\.[A-Z_]*(FROM|_LINE|SENDER).
• Calendar: /me/events|/calendar/events|calendar/v3|events\.insert|sendUpdates|attendee|METHOD:REQUEST|text/calendar|BEGIN:VCALENDAR.

Findings from the checks:

• SendGrid has exactly one wire: client.ts:390. The only exception is X4.
• No SES send exists.
• Only one production line overrides the From address: property-graph-sender.ts:1109.

Sends that skip the known doors:

• Email: the Lambda's own Graph/Gmail wire (E13), the cadence follow-ups (E20), turnover vendor emails (E21), X4, X5.
• Text and voice: T2, V7.
• PROPERTY_TO_PHONE_MAP is gone from the code. claraNumberForProperty (phone-lookup.ts:656) has no production callers left.

Recommendation

Decide the email sender in one function owned by the router, send-mailbox-selector.ts. Call it once at the top of sendPropertyEmail, before E4. It looks up the recipient itself from the to address and the organization: resolveInboundStaffMembershipByEmail(to, organizationId), or holdsActiveStaffRoleInOrg when a personId is in hand. That is roles at the company, never the building, and never the email-domain shortcut E12 uses. Any active staff role turns chooseMailbox into "SendGrid from clara@", ignoring the building's sendGridSenderIdentity.

The shared-inbox Lambda keeps its own wire for threading and its send lock. So sendClaraProspectEmailViaAdapter should ask the same function and, for staff, deliver the way the staff email turn already does (E17). The Lambda already runs this lookup at :978. The change there is to drop the domain arm and branch the wire on the result, not to add a new lookup. That is one decision function with two callers, until the Lambda moves onto the router.

What goes away or becomes pass-through:

• Stop deciding anything about the sender: internalRecipient, audience and recipient.isStaff. The staff fact on E3, E14 and E19 would come from the lookup instead.
• Gone: the "role known, ignored" gap in E12/E15. E17's hard-wired clara@ becomes the default.
• Need no change: the hold-kind split at E18, sesDeliver (E16), E7's staff case, and every X1-style script.
• Separate follow-ups: move E20 and E21 onto the router, and update the clara-takeover email recipe.
• Texts: T7 is the same pattern with a caller flag. If texts ever follow the rule, it should do the same lookup instead of trusting recipientType.

Who Clara emails, and which address it comes from (inventory, 2026-11-03)

Read-only inspection of origin/main @ f59cf9885a (Nov 4 00:33 UTC). Nothing edited. Rule checked: staff of the customer hear from clara@propflowai.co; the customer's connected mailbox (leasing@…, camelliaapts@…) is only for outside people (prospects, applicants, renters, vendors).

Counts

Headline: every *notice* Clara writes to staff (call summaries, tour alerts, lead notices, digests, approvals, staff asks, emergency alerts, renewals, move-outs, vendor outcomes) already goes from clara@ through SendGrid. The leak is narrower: when Clara replies to a person who emailed in, the reply goes from the customer mailbox even when that person is staff. Three doors do this: the shared-inbox reply Lambda, the clara@ (SES) reply lane, and the "approve a held reply" release.

Today's Situs email: the code can't say which message it was. Going by the path you named (sendPropertyEmail → selectSendMailbox), it is W2 (a reply on the clara@ lane) or W3 (an approved held reply). W1 (the Lambda) has the same defect but never goes through the selector. Telling W2 from W3 needs the ingestion-log or hold row for that message.

---

How the sender is chosen today

``` sendPropertyEmail(...) <- every "property-voiced" email | +-- selectSendMailbox() send-mailbox-selector.ts | 1. building has its own mailbox -> Graph from that mailbox (Camellia) | (non-Microsoft own mailbox -> SendGrid) | 2. company mailbox connected -> Graph (Microsoft) or Gmail (Google) | (Gmail + attachments -> SendGrid) | 3. nothing connected -> SendGrid | (sibling rung: reply from a sister building's mailbox that holds the thread) | +-- SendGrid leg: from = property.sendGridSenderIdentity.email, else clara@propflowai.co

sendEmail(...) (client.ts) <- every staff notice from = opts.fromEmail || CLARA_EMAIL ('clara@propflowai.co') Only the SendGrid leg of sendPropertyEmail ever sets fromEmail. Wrappers that all land here: tellStaff, sendOrHoldTeamNotice, sendgridTeamSender (team-notification engine), sendRecapEmail, bake-gate releases of held notices. ```

• resolveCompanyMailboxToken (company-mailbox.ts) returns the company's Graph/Gmail token only when the building has no mailbox of its own. It never looks at who the recipient is.
• What internalRecipient changes today: in the selector, only the failure rule. A staff send whose mailbox attempt throws falls back to SendGrid instead of being held. It never changes which door is tried first. In sendPropertyEmail it also skips the per-person contact ceiling. audience: 'staff' only affects the company-live hold. Neither flag picks clara@.
• And no caller of sendPropertyEmail passes either flag today (checked all 16 direct callers plus wrappers). sendClaraProspectEmail takes recipient.isStaff, but uses it only to pick the plain coworker template. It never passes it to the router.

Where one fix belongs

1. chooseMailbox in send-mailbox-selector.ts: add a first rule, "recipient is staff (internalRecipient or audience: 'staff') → { door: 'sendgrid', why: 'staff_recipient' }", ahead of the building-mailbox rule. Also force SendGrid's fromEmail to clara@ for that reason, not the building's sendGridSenderIdentity. This is pure code with one existing test file, so the rule lives in one place. 2. Thread the flag in: sendClaraProspectEmail passes internalRecipient: recipient.isStaff (and audience: 'staff') to sendPropertyEmail. The SES lane (process-inbound-email.ts sesDeliver) and the held-reply release (bake-gate.ts:1575) need the staff fact too. The SES lane never resolves it today. The hold row would need to store it, e.g. on hold.resume, or the release can read hold.replyModule === 'team.notices' / a staff lookup. 3. Second door the selector never sees: lambda/inbound-processor/handler.ts sends Clara's shared-inbox replies straight through client.sendReply/sendNewMessage on the connected mailbox token. It already computes isInternalRecipient. Its deliver needs a staff branch that calls sendEmail from clara@, the way staff-email-turn.ts already does.

Why the current design used the customer mailbox (for Fede to weigh)

• Threading in the shared inbox. A Graph reply only threads from the mailbox that holds the parent message. A clara@ reply to a staff member's email in leasing@ will not appear in leasing@'s Sent Items or in that Outlook conversation. The staff member's own mail client still threads it (In-Reply-To/References headers ride on SendGrid; staff-email-turn.ts already does this).
• Gera's rule (gmail-company-sender.ts header): the company mailbox is "where Clara reads and writes from". The 2026-09-15 "reply-only" ruling has Clara read only replies on threads she started in that mailbox. If staff reply to a clara@ email, the reply lands at clara@ (the SES lane → staff turn), not in the shared inbox. That is already how every staff notice works today.
• "Never as generic Clara" (#11694): the selector refuses to *re-send* a possibly-delivered prospect email from clara@. It already exempts staff recipients, so the design already accepts staff mail coming from clara@.
• Building voice: the router exists so prospect mail looks like it comes from the property (Camellia, 2026-07-18). None of that applies to staff.

---

Inventory, WRONG first

Door legend: CustMbx = customer mailbox (building Graph mailbox, else company Graph/Gmail mailbox); clara@ = SendGrid from clara@propflowai.co.

WRONG: staff recipient, sent from the customer mailbox (5)

WRONG: outside person, sent from clara@ (1)

UNCLEAR (7)

OK: outside person, sent from the customer mailbox (19)

All go through sendPropertyEmail → CustMbx (SendGrid only as fallback).

(The last three go through sendClaraProspectEmail (W5). They are correct only because the recipient is an outside person.)

OK: staff/internal, sent from clara@ (74)

Direct SendGrid sends (26), all internalRecipient: true, from clara@:

tellStaff → SendGrid (14). Door: clara@. Verdict: OK. All files are under src/lib/.

sendOrHoldTeamNotice → SendGrid (29). Door: clara@. Verdict: OK. The door hard-sets internalRecipient: true and goes through sendEmail. A held one is released by bake-gate.ts:1063, also clara@. All files are under src/lib/.

Sign-in and invites via sendRecapEmail (5). Door: clara@. Verdict: OK. The recipient is the person signing in.

OK: PropFlow's own outside contacts, from clara@ (3)

public/demo-request/route.ts:235 (thanks to a PropFlow demo lead); marketing/subscribe-thanks.ts:47 (newsletter thanks); canary/suppression-probe/route.ts:216 (never delivered). The customer has no mailbox in these flows, so the rule doesn't apply.

---

Texts to staff (for later)

Every staff text leaves on Clara's Twilio line for that building, else the company's line. That is the same number prospects and renters text. It is resolved by resolveStaffLineAndThread → resolveOutboundAddress (src/lib/domain/escalation/staff-line-thread.ts). There is no separate PropFlow staff number.

If texts follow the email rule later, the single place to change is resolveStaffLineAndThread, which every staff text already goes through.

Clara emails to customer staff, last 14 days (2026-10-20 to 2026-11-03 UTC)

Read-only pull, 2026-11-03. Source: the email delivery log in production (one row per send, every door: SendGrid, Microsoft Graph, Gmail), 15 daily partitions, 1,399 rows, queried by key in about 9 seconds. No scans, no writes.

Answer

• 152 emails reached customer staff in 14 days (delivered only; blocked/held sends not counted).
• 151 came from clara@propflowai.co (SendGrid).
• 1 came from a customer mailbox: Western Slope's leasing@westernslopepm.com, to Kat Barker (leasing agent), 2026-11-03 16:06 UTC, "Bre Martin's virtual tour today at 4:30 PM is on Zoom". WRONG.
• Kinds that went to staff from a customer mailbox: virtual-tour Zoom link to the tour host (1 email). Nothing else.

How the sender was decided

The delivery log has no from-address field, so the sender comes from the provider message id each send path stores:

• SendGrid rows carry a 22-character id (e.g. KGG1Kv5cTyKmHi_aNOtdPQ). SendGrid sends from clara@propflowai.co. None of the 145 Situs, Western Slope or JP&Co properties has its own SendGrid sender address that would override that.
• Gmail mailbox rows carry a 16-hex id. None of them went to staff.
• Microsoft Graph mailbox rows carry no id at all. All four Graph send paths in the code write the row that way.
• The WRONG row has a second confirmation. Western Slope's list of "threads Clara started from the company mailbox" gained an entry 6 ms after the send (16:06:55.934 UTC), carrying an Outlook message id. Only the company-mailbox send path writes that list.

Staff means any address at @westernslopepm.com, @thesitusgroup.com or @jp-co.com, in To or CC. I also checked all 54 outside addresses that got mail from a customer mailbox for a staff role. Only Kat has one. The rest are prospects or our own test aliases.

About the WRONG email

• It was logged as transactional, marked not an internal recipient (internalRecipient: false), and filed on Kat's staff text thread (c9f809af-2a67-47dc-8731-55dac75ee51a). That mislabel is the likely reason it went out of the mailbox instead of clara@. The thread has no email message for it, only Clara's texts to Kat about the same tour.
• No code template on main (commit b74879d48e) produces this subject. The code's own "your tour is now a video call" notice to the host goes from Clara by design (src/lib/domain/leasing/tour/tour-room-made-notices.ts). So this email came from some other route: model-written, sent by hand, or code that has changed since. I didn't trace it further.
• The same kind of email to Situs tour hosts went out correctly from clara@propflowai.co: Patricia R.'s tour briefing to Deiby, and Adia R.'s to Miriam.

Limits

• Calendar invites the mailbox sends when a tour lands on the property calendar don't go through this log, so they aren't counted.
• Emails *to* a customer's shared mailbox (e.g. leasing@westernslopepm.com) count as staff emails. All of them came from clara@propflowai.co.
• If a staff member got email at a personal Gmail, it could be missing from the OK totals. It could not be a missed WRONG: every customer-mailbox recipient was role-checked.

Western Slope: by kind

Situs Group: by kind

Camellia / JP&Co: by kind

Appendix: every staff email

Western Slope (70)

Situs Group (50)

Camellia / JP&Co (32)