fix: connector-delivery reconciler overwrites real responses from agents using non-connector tools

[siglimumuni]

Summary

`reconcileConnectorDeliveryText` is meant to catch agents that hallucinate "I sent your message" without actually invoking the connector tool. As written, it overwrites the agent's response with a canned false-negative whenever:

1. The response language matches its positive-delivery regex (sent / delivered / scheduled + recipient / message id / connector context), AND
2. No `connector_message_tool` event was recorded for the turn — regardless of whether other tool events happened.

Effect: any agent that sends through a non-connector path — `execute` running `nodemailer` against an SMTP server, `curl` against a webhook endpoint, `gh issue create` for GitHub triage, future connectors that don't route through `connector_message_tool` — loses its real response, replaced with "I couldn't confirm that the configured connector actually sent anything." The agent did the work; the user sees a lie in the other direction.

Concrete repro

In our deployment we wired a customer-service agent to send outbound email via Proton Bridge using `nodemailer` from her shell (credentials injected as `PROTON_SMTP_JSON` env). The agent writes a draft, runs nodemailer from `execute`, gets a real `messageId` back, posts a confirmation thread reply: "✓ Reply sent to gmail.com, messageId: <id>". Reconciler sees `sent` + `recipient`-adjacent context, no `connector_message_tool` event, overwrites the entire response with the canned false-negative. The email arrived. The user sees the canned line and resends, producing duplicates.

Fix

When no `connector_message_tool` event was recorded for the turn, only emit the false-negative when no tool events ran at all. Any tool event present is evidence the agent did real work; the reconciler shouldn't blindly overwrite. The connector-failure branch (connector events present but none succeeded) is unchanged — that path has genuine evidence to surface.

This narrows the reconciler's scope to its actual purpose: catch agents that hallucinate sends without invoking any tool. Agents that use non-connector tools to deliver are no longer collateral damage.

```diff
if (connectorEvents.length === 0) {

• // No connector_message_tool event was recorded for this turn, but the
• // agent may have legitimately delivered the message through another tool
• // — typically execute running nodemailer / smtp / curl, or a future
• // connector that doesn't route through connector_message_tool. If any
• // tool ran this turn, the agent did real work; trust them rather than
• // overwriting with a false-negative. Only reconcile when there is
• // genuine evidence of hallucination (no tools called at all).
• if (dedupedEvents.length > 0) return text
  return `I couldn't confirm that the configured connector actually sent anything. No connector delivery tool call was recorded for this response.`
  }
  ```

Workaround we shipped meanwhile

Updated the agent's system prompt to use language that doesn't trip the regex (`Reply queued via Proton bridge` instead of `Reply sent to `). Works as a prompt-discipline tax but the reconciler shouldn't be forcing it on every agent that uses an alternate send path.

Test plan

• Reviewed by inspection.
• Applied locally; agent's nodemailer-based send no longer gets its confirmation overwritten.
• Once merged: revert the prompt workaround on our customer-service agent and confirm reconciler stays quiet.

Files

• `src/lib/server/chat-execution/chat-execution-connector-delivery.ts` (12 lines, one branch added)

🤖 Generated with Claude Code

[waydelyle]

Cherry-picked and shipped in v1.9.33 with connector sanitization coverage and non-connector delivery preservation. Thanks for the fix.