Step 5 of the F8 workstream. In the design doc this is docs/design/f8-vendor-conversation-routing.md §4.3 "Phase 3: route signature events to the counterparty"; its verification list (§6.4) is exactly the eval below.

The problem, and the mechanism

domain-identification.ts told the agent that every automated notification goes to the sender's vendor bucket , "do NOT open a deal, even if the body names a company." That rule is correct for a meeting recap (Cedar already has the meeting from calendar sync, so the company in the subject adds nothing) and wrong for a signature/transaction event, which reports a contract state change Cedar cannot learn from calendar, email or CRM sync.

What made it fail is the tool's argument order, not the agent's judgment. lookupCompanyFuzzyTool resolves domain first and returns on a hit (lookupCompanyFuzzyTool.ts:357-408), so passing the vendor's domain hands back the vendor's own bucket before the counterparty name is ever tried.

• Baseline passes { domain: 'pandadoc.net', companyName: null } → the PandaDoc bucket.
• Candidate passes { companyName: '<counterparty>', domain: null } → the counterparty's deal.

In a real production trace the agent called the tool with companyName: null on an email about a specific customer's order form and returned the PandaDoc bucket. 38 select-primary-company calls resolved that way.

What changed

apps/server/src/mastra/skills/crm/domain-identification.ts, instructions only:

1. Classify before routing. An automated message is sorted by what it reports , a meeting artifact (recap, transcript, shared recording, agenda digest) or a contract-document state change , with the vendor's identity explicitly not deciding it, and recap as the default when it isn't unambiguously a document.
2. Transaction path: read the counterparty out of the document title, pass it as companyName with domain: null.
3. Fallback is mechanical, not composed. On a miss the agent calls the tool a second time with the sender's root domain and returns what comes back, instead of writing a domain from memory. This is what fixed the fallback case.
4. Two general prohibitions, strengthened in place rather than duplicated: a company name is not evidence of a domain, and the user's own domain is only ever valid for a genuinely internal thread.

No code paths changed. pnpm --filter @zero/server run types clean, pnpm deps:check clean (1751 modules, no violations).

Results

playbook-instruction-eval, model gpt-4o (the real workload model). Baseline is this file as it stands on origin/staging , verified byte-identical to the frozen fixture, so the A/B isolates only this diff. Counts are aggregated over repeat 8-trial runs on identical fixtures.

Tuned set , visible while the instructions were being edited:

Held out , written from production before any iteration, scored afterwards, two signature vendors this change was never tuned against:

The unit of analysis is the case, not the trial. Trials within a case are repeats of one prompt, so they are not independent; there is no pooled N here and no p-value on n