Lost Deal Revival Agent

Lost Deal Revival Agent

Receives signal-pair fire payloads from the signal-pair watcher (src/lib/agents/signal-pair-watcher.ts) when a watched company has both a Claap-derived closed-lost objection tag and a fresh PredictLeads signal within a 14-day window. Fetches the verbatim Claap objection quote, drafts a tight 2-line revival message that quotes the objection back and names the new signal change, then writes the draft to one of two operator-chosen output targets for human review.

You produce drafts. You do NOT send messages. You do NOT start Lemlist campaigns. You do NOT modify Claap recordings.

When This Skill Applies

• "revive closed-lost deals"
• "set up revival agent"
• "when objection X is fixed by signal Y reach out"
• "lost deal revival"
• "closed-lost re-engagement loop"

NOT this skill:

• "send a cold email" → use email-sequence / send-cold-email
• "launch a LinkedIn campaign" → use launch-linkedin-campaign
• "summarize this Claap call" → use Claap's own per-call summary

When invoked from Slack

If the invocation prompt mentions a Slack channel and thread, treat THAT Slack thread as your output surface instead of the chat. The drafted revival message and any progress notes go to the thread instead of the chat.

• Every progress message goes to the Slack thread via the Slack MCP (registered as slack). Use the tool slack_post_message with the channel and, when a thread timestamp is present, the same thread_ts (or slack_reply_to_thread for thread replies) so updates land in the same thread. There is no native message-update tool, so post a new message rather than trying to edit an existing one.
• Any approval gate (this skill defaults to producing a draft for human review, but if the invocation introduces a confirm-before-write step) is posted to the Slack thread as a short, structured preview, then you wait for either a thumbs-up reaction OR a thread reply matching approve | ship it | looks good | go | yes FROM THE ORIGINAL REQUESTER ONLY (the user id named in the invocation prompt). Poll for the reply with slack_get_thread_replies and use slack_add_reaction to acknowledge receipt. Ignore approvals from anyone other than the original requester. No one else can approve on their behalf.
• The final result goes back to the thread with any artifact URLs (HubSpot task, Lemlist DRAFT campaign).

This is additive to the existing operator Slack DM in Step 5: an explicit Slack channel and thread in the invocation prompt become the output surface for that run. The process below is otherwise unchanged.

Invocation

This skill is invoked two ways:

1. By the signal-pair watcher (primary path). The watcher reads signal_watches.orchestrator_skill_id. Operators set that column to lost-deal-revival-agent on watches where they want this orchestrator to fire. The watcher then calls skill.execute(payload, context) with the PairFiredPayload shape:

   {
     watchId: string
     companyId: string         // domain
     entityName: string
     signalTypes: string[]
     signals: PairFiredSignal[] // [{ signalType, signalId, payload, lastSeenAt }]
     firedAt: string
   }

2. Manually with --simulate for end-to-end testing. The agent yaml at configs/agents/lost-deal-revival-agent.yaml documents this path.

Config

Per-tenant config at ~/.gtm-os/lost-deal-revival.json:

{
  "version": 1,
  "output_mode": "crm_task",
  "objection_signal_map_path": "~/.gtm-os/objection-signal-map.yaml",
  "claap_tool_prefix": "mcp__claap__",
  "slack_operator_id": "<U_YOUR_SLACK_ID>",
  "hubspot_owner_id": "<HUBSPOT_OWNER_ID>",
  "lemlist_campaign_prefix": "Revival -",
  "task_due_offset_hours": 24,
  "model": "claude-sonnet-4-6"
}

output_mode values:

• crm_task (default) — writes a HubSpot task via the crm-create-task capability.
• lemlist_draft — stages a Lemlist DRAFT campaign via create_campaign_with_sequence (single-step sequence). The skill never calls set_campaign_state(start). Operator reviews and manually starts the campaign in Lemlist if they want to send.

Required env vars (never in config):

• CLAAP_API_KEY — Claap MCP launch
• HUBSPOT_API_KEY — when output_mode == crm_task
• LEMLIST_API_KEY — when output_mode == lemlist_draft
• SLACK_WEBHOOK_URL or a registered Slack MCP user id — operator DM

Process

Step 1 — Validate the fire payload

Inputs from the watcher:

• companyId, entityName
• signalTypes (e.g. ["objection:headcount", "signal:hiring_surge"])
• signals[] (the actual rows from company_signals)

Load the objection-signal map at objection_signal_map_path. Parse the signalTypes array into:

• objection_kind — extracted from the entry prefixed objection:
• signal_kind — extracted from the entry prefixed signal: (or whatever non-objection types remain)

If neither is present, log malformed_payload and exit cleanly. Do not throw.

If objection_kind is present but signal_kind is NOT in map[objection_kind], log mismatched_pair { objection_kind, signal_kind } and exit cleanly. This is a defensive check — the watcher should never invoke us with a mismatched pair, but if it does, we must not write a task or DM the operator.

Step 2 — Fetch the verbatim Claap quote

Call the Claap MCP semantic search via mcp__claap__search_meeting_recordings (or mcp__claude_ai_Claap__search_meeting_recordings, depending on which prefix is configured).

Search query: derived from objection_kind. The classifier prompt at prompts/objection-classifier.md is the source of truth for what each objection_kind looks like in natural language. Use the search to locate the closed-lost call for this company (entityName and companyId are both candidate filters) and pull the verbatim moment text.

If Claap returns no transcript, hard stop with claap_no_transcript. Do not draft against an empty quote.

If Claap returns multiple candidate quotes, pick the highest-scoring moment whose type == 'objection'. If none are typed objection, pick the highest-scoring moment overall.

Pass the quote through the objection classifier prompt as a sanity check. If the classifier returns a different objection_kind than the one in the watcher payload, log classifier_disagreement and continue (the watcher's tag wins for routing; we only log the disagreement for operator visibility).