cocottetech/@platform/codebase/@features/prospecting/docs/warm-intros.brief.md

warm-intros.brief

Subfeature of: prospecting Code-name: warm-intros Specialist: specialist-warm-intro Status: P5+ (gated on copilot adoption density; ships after cross-provider-graph and auto-qualify-draft).

Problem

A cold inbound pitch costs both sides time: the recipient triages, the sender re-pitches. Most never reach a match. Meanwhile, some of those pitches are obviously good fits if a trusted third party could vouch — but no one has the cycles to broker manually.

Solution

Two copilots negotiate an introduction on behalf of their humans. Neither human is interrupted until both copilots agree the intro is worth the interrupt. When they agree, the recipient sees a single warm-intro card with the vouching copilot's reasoning summarised; the sender sees a "your copilot reached out on your behalf" receipt.

A successful flow:

1. Sender's copilot identifies a target Person (via the cross-provider graph or directory).
2. Sender's copilot composes an intro packet: who I represent, what I want, why this match, public reputation evidence.
3. Sender's copilot calls specialist-warm-intro on the recipient's tenant (federated MCP call, recipient-authenticated).
4. Recipient's specialist-warm-intro evaluates against the recipient's stated preferences, calendar pressure, and graph reputation of the sender.
5. If both copilots' confidence × utility crosses the recipient's threshold → the recipient sees a warm-intro card. Otherwise → silent decline (sender's copilot is told "not now", no human is bothered).

States

1. No copilot on the recipient side. Subfeature is a no-op; sender's copilot must fall back to a cold pitch.
2. Recipient copilot present, threshold not met. Silent decline. Sender's copilot is told "not now" with a reason class (out-of-scope, over-capacity, low-reputation) but no human content.
3. Threshold met, awaiting recipient confirm. Card surfaces; recipient one-taps accept / decline / defer.
4. Accepted. Both sides' copilots open a thread on the recipient's primary channel; the warm-intro packet becomes the thread's pinned context.
5. Audit replay. Every negotiation is auditable; both sides can replay why their copilot did or didn't surface a given intro.

Constraints

• Human-on-the-loop, never agent-only commit. Copilots never accept a meeting / booking on the human's behalf; they only decide whether to surface the intro. The accept-tap is always human.
• Symmetric audit. Both sender's and recipient's copilot record the negotiation; either side can replay (per I-audit-trust-replay.brief.md).
• No content leak on silent decline. A declined intro reveals nothing to the sender beyond the reason class — never the recipient's preferences, calendar, or full availability.
• Graph-conditioned. Sender reputation flows from cross-provider-graph; without the graph, warm intros degrade to provider-local trust (effectively cold).
• Rate-limited per sender. Sender-copilots are rate-limited per recipient and per network to prevent agent-amplified spam.

Constraints (privacy + safety)

• Warm-intro packet may quote the sender's own outreach phrasing; never quotes the recipient's prior content.
• Recipient preferences used in evaluation are policy-coded (e.g., "weekends only", "no first-time deposits") and never leaked outside the evaluation.
• Coop safety flags (N-provider-coop) hard-block warm intros — a flagged sender never reaches the recipient's threshold regardless of utility.

Related docs

• prospecting.brief.md, cross-provider-graph.brief.md
• warm-intros.contract.md, warm-intros.screen.md
• @features/ai-copilot/docs/N-provider-coop.brief.md (safety primitives)
• @features/ai-copilot/docs/I-audit-trust-replay.brief.md (symmetric audit)
• @features/ai-copilot/docs/specialist-ai-copilot.contract.md (copilot fleet semantics)