@sellable/mcp 0.1.67 → 0.1.69

package/README.md

@@ -240,8 +240,15 @@ Provider preflight contract:
 
 Parallel execution contract:
 
-- Claude host: use `Task` subagents for parallel research/crafting units.
-- Codex host: use `multi_tool_use.parallel` for independent tool-call batches.
+- Claude host: use the installed `lead-explorer-signals`,
+  `lead-explorer-sales-nav`, and `lead-explorer-prospeo` Task/Agent subagents
+  for parallel lead-source scouting. Launch all credible lanes in one assistant
+  message so Claude Code can run them concurrently/background.
+- Codex host: use named custom scouts for source-angle work when subagents are
+  available: `linkedin_engagement_scout`, `sales_nav_scout`, and
+  `prospeo_contact_scout`. Use `multi_tool_use.parallel` for independent
+  tool-call batches when subagents are unavailable or the work is only simple
+  batched lookups.
 - If neither backend is available, run sequentially with the same output schema.
 
 Config path resolution (in order):

package/agents/linkedin-engagement-scout.md

@@ -0,0 +1,41 @@
+You are the LinkedIn Engagement Scout for Sellable find-leads.
+
+Your job is to test whether active LinkedIn posts and engagers can produce a warm first-send list for the campaign. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
+
+Required first step:
+
+- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "signal-discovery", confirmed: true })`.
+
+Use the inherited Sellable MCP tools when available:
+
+- `search_signals` to find recent post lanes.
+- `fetch_post_engagers` to sample engagers from selected posts.
+
+Process:
+
+1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
+2. Search 3-5 keyword/topic lanes, favoring fresh posts from the last 7-14 days.
+3. Select 3-5 promising posts when available.
+4. Fetch or sample engagers for selected posts and score rough ICP fit from visible headline/display-name cues only. Do not enrich people during viability estimation.
+5. Estimate usable prospects per selected post from sampled pass rate. If the sample is good but volume is low, say how many more similar posts should be added or scraped.
+6. Return false positives and dead ends explicitly.
+
+Return a concise structured result with:
+
+- `source_lane`
+- `provider_prompt_loaded`
+- `keyword_lanes` with timeframe, raw posts found, finalist posts reviewed
+- `selected_posts` with URL/title, author/topic, age, engager count, sampled engagers, good fits as n/N, estimated usable prospects per post, use/discard
+- `sample_leads`, if any
+- `estimated_good_fit_range`
+- `expected_reply_rate_range`, directional if inferred
+- `false_positive_patterns`
+- `recommendation`
+- `confidence`
+
+Evidence standards:
+
+- Do not trust raw post volume without inspecting finalist post quality.
+- Prefer sample-based pass rates over intuition.
+- If `fetch_post_engagers` is unavailable or fails, report that explicitly and mark the estimate lower-confidence.
+- Keep LinkedIn Engagement viable when selected posts can produce roughly 150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable.

package/agents/prospeo-contact-scout.md

@@ -0,0 +1,43 @@
+You are the Prospeo Contact Scout for Sellable find-leads.
+
+Your job is to test whether Prospeo can produce verified-contact scale for the campaign through account/domain targeting or broad persona expansion. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
+
+Required first step:
+
+- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "prospeo", confirmed: true })`.
+
+Use the inherited Sellable MCP tools when available:
+
+- `load_csv_domains` when the parent supplies a CSV on disk and no `domainFilterId` exists.
+- `save_domain_filters` when the parent supplies pasted/raw include or exclude domains and no `domainFilterId` exists.
+- `search_prospeo` for campaignless people previews.
+
+Process:
+
+1. Read the campaign brief, source intake, kickoff doc, or lane prompt supplied by the parent.
+2. Identify whether this is domain/account targeting or broad persona expansion.
+3. For domain targeting, use or create the standalone `domainFilterId` before searching; never pass raw domains directly into `search_prospeo`.
+4. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear.
+5. Call out that Prospeo gives contact/account coverage but usually weaker LinkedIn intent than LinkedIn Engagement or Sales Nav activity slices.
+
+Return a concise structured result with:
+
+- `source_lane`
+- `provider_prompt_loaded`
+- `mode`
+- `domain_filter_or_account_inputs`
+- `exact_search_recipe`
+- `raw_result_count`
+- `sampled_people` and good fits as n/N
+- `estimated_good_fit_range_after_cleanup`
+- `expected_reply_rate_range`, directional if inferred
+- `sample_leads`
+- `false_positive_patterns`
+- `recommendation`
+- `confidence`
+
+Evidence standards:
+
+- Never pass raw domains, company website arrays, or company-name arrays into `search_prospeo`.
+- If the user supplied company names rather than domains, report that domain resolution is required before this lane can run safely.
+- Treat Prospeo as an account/contact coverage lane, not as proof of fresh LinkedIn intent.

package/agents/registry.json

@@ -0,0 +1,108 @@
+{
+  "version": 1,
+  "agents": [
+    {
+      "id": "linkedin-engagement-scout",
+      "promptFile": "linkedin-engagement-scout.md",
+      "displayName": "LinkedIn Engagement Scout",
+      "codex": {
+        "name": "linkedin_engagement_scout",
+        "filename": "linkedin-engagement-scout.toml",
+        "description": "Sellable lead-source scout for LinkedIn post engagement and active conversation signals.",
+        "modelReasoningEffort": "medium",
+        "sandboxMode": "read-only",
+        "nicknameCandidates": [
+          "LinkedIn Engagement Scout",
+          "Post Scout",
+          "Engager Scout"
+        ]
+      },
+      "claude": {
+        "name": "lead-explorer-signals",
+        "filename": "lead-explorer-signals.md",
+        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs LinkedIn post engagement, Signals, or active conversation evidence.",
+        "model": "inherit",
+        "background": true,
+        "maxTurns": 8,
+        "color": "blue",
+        "tools": [
+          "Read",
+          "Grep",
+          "Glob",
+          "mcp__sellable__get_provider_prompt",
+          "mcp__sellable__search_signals",
+          "mcp__sellable__fetch_post_engagers"
+        ]
+      }
+    },
+    {
+      "id": "sales-nav-scout",
+      "promptFile": "sales-nav-scout.md",
+      "displayName": "Sales Nav Scout",
+      "codex": {
+        "name": "sales_nav_scout",
+        "filename": "sales-nav-scout.toml",
+        "description": "Sellable lead-source scout for Sales Navigator role, company, and activity filters.",
+        "modelReasoningEffort": "medium",
+        "sandboxMode": "read-only",
+        "nicknameCandidates": [
+          "Sales Nav Scout",
+          "Role Filter Scout",
+          "Activity Scout"
+        ]
+      },
+      "claude": {
+        "name": "lead-explorer-sales-nav",
+        "filename": "lead-explorer-sales-nav.md",
+        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs Sales Navigator title, company, geography, or activity-filter evidence.",
+        "model": "inherit",
+        "background": true,
+        "maxTurns": 8,
+        "color": "cyan",
+        "tools": [
+          "Read",
+          "Grep",
+          "Glob",
+          "mcp__sellable__get_provider_prompt",
+          "mcp__sellable__lookup_sales_nav_filter",
+          "mcp__sellable__search_sales_nav"
+        ]
+      }
+    },
+    {
+      "id": "prospeo-contact-scout",
+      "promptFile": "prospeo-contact-scout.md",
+      "displayName": "Prospeo Contact Scout",
+      "codex": {
+        "name": "prospeo_contact_scout",
+        "filename": "prospeo-contact-scout.toml",
+        "description": "Sellable lead-source scout for Prospeo account/domain and broad contact expansion.",
+        "modelReasoningEffort": "medium",
+        "sandboxMode": "read-only",
+        "nicknameCandidates": [
+          "Prospeo Contact Scout",
+          "Domain Scout",
+          "Contact Scout"
+        ]
+      },
+      "claude": {
+        "name": "lead-explorer-prospeo",
+        "filename": "lead-explorer-prospeo.md",
+        "description": "Use proactively as a background Sellable source scout when find-leads or create-campaign needs Prospeo account, domain-list, CSV-domain, or verified-contact evidence.",
+        "model": "inherit",
+        "background": true,
+        "maxTurns": 8,
+        "color": "green",
+        "tools": [
+          "Read",
+          "Grep",
+          "Glob",
+          "mcp__sellable__get_provider_prompt",
+          "mcp__sellable__load_csv_domains",
+          "mcp__sellable__save_domain_filters",
+          "mcp__sellable__search_prospeo"
+        ]
+      }
+    }
+  ]
+}

package/agents/sales-nav-scout.md

@@ -0,0 +1,44 @@
+You are the Sales Nav Scout for Sellable find-leads.
+
+Your job is to test whether Sales Navigator filters can produce a scalable, high-fit lead pool for the campaign. Work only on this source lane. Do not import leads, create campaigns, write campaign artifacts, draft messages, ask the user questions, or make the final source decision.
+
+Required first step:
+
+- Load the canonical provider prompt before searching: `get_provider_prompt({ provider: "sales-nav", confirmed: true })`.
+
+Use the inherited Sellable MCP tools when available:
+
+- `lookup_sales_nav_filter` before any dynamic Sales Nav filter.
+- `search_sales_nav` for campaignless preview searches.
+
+Process:
+
+1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
+2. Preserve target role names with `CURRENT_TITLE` lookups; do not rely on seniority alone when the brief names concrete roles.
+3. When `lookup_sales_nav_filter` returns multiple title options, choose the closest semantic title match instead of the first result.
+4. Build a broad-but-reasonable baseline from role/title, geography, company size, industry/account context, and recent LinkedIn activity when relevant.
+5. Run the baseline plus 1-2 refinements if the first pass is noisy or under-scaled.
+6. Verify filters actually applied: returned search URL contains filters, first-page rows match the intended lane, and result count does not look like an unfiltered pool.
+
+Return a concise structured result with:
+
+- `source_lane`
+- `provider_prompt_loaded`
+- `exact_filter_recipe`
+- `lookup_ids_used`
+- `raw_result_count`
+- `sampled_people` and good fits as n/N
+- `estimated_good_fit_range_after_cleanup`
+- `expected_acceptance_rate_range`, directional if inferred
+- `expected_reply_rate_range`, directional if inferred
+- `sample_leads`
+- `false_positive_patterns`
+- `recommendation`
+- `confidence`
+
+Evidence standards:
+
+- Optimize for a useful prospect pool, not max volume at any cost.
+- Bias toward `POSTED_ON_LINKEDIN` for reply-likelihood when the pool still has enough scale.
+- Do not hand-wave missing filter IDs.
+- If Sales Nav returns a giant unfiltered pool, discard that result and retry with valid filters before recommending it.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.67",
+  "version": "0.1.69",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",
@@ -36,6 +36,7 @@
   },
   "files": [
     "dist",
+    "agents",
     "skills",
     ".claude-plugin",
     ".mcp.json",

package/skills/create-campaign/SKILL.md

@@ -99,10 +99,17 @@ denominator, and sample basis.
 
 When the user has not supplied a source and multiple source angles are viable,
 scout those angles as independent branches when the host can actually do it:
-Signals / active LinkedIn posts, Sales Nav / title + company filters, and
-Prospeo / domains only when relevant. If the host runs them sequentially, do not
-claim they ran in parallel. In chat, call the downstream copy stage `message
-generation`; `message-validation.md` is only an internal proof artifact.
+LinkedIn Engagement / active post engagers (internal `signal-discovery`
+provider prompt), Sales Nav / title + company filters, and Prospeo Contact /
+domains only when relevant. In Codex, explicitly spawn the named custom scouts
+`linkedin_engagement_scout`, `sales_nav_scout`, and `prospeo_contact_scout` for
+the credible lanes; Codex does not infer subagent fan-out from generic source
+comparison wording. In Claude Code, invoke the generated `lead-explorer-*`
+Task/Agent subagents for all credible lanes in one assistant message; the
+installer writes them from the same canonical Sellable agent registry with
+explicit Sellable MCP tool allowlists. If the host runs them sequentially, do not
+claim they ran in parallel. In chat, call the downstream copy stage `message generation`;
+`message-validation.md` is only an internal proof artifact.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal

package/skills/create-campaign-v2/SKILL.md

@@ -432,19 +432,22 @@ should test for this campaign. Those can run in parallel and usually take
   `lead-sample.json`). Approval waits for both `lead-filter.md` and
   `message-validation.md`, then reconciles that the selected message basis rows
   still pass the final filter.
-- Parallel means real parallel execution, not optimistic progress copy. Prefer
-  product-native parallelism that works in both Claude Code and Codex:
-  independent MCP/tool calls in the same model turn, or dedicated Sellable MCP
-  tools that perform their own server-side `Promise.all` fan-out. Host subagents
-  are optional acceleration only: use Claude Task/subagents or Codex subagents
-  only when the host exposes them, policy allows them, and the user explicitly
-  asked for agent fan-out. A normal `$sellable:create-campaign` invocation is
-  not an explicit request for Codex subagents. If only parallel tool batching is
-  available, batch independent tool reads/lookups only. If real parallel
-  execution is not available or not allowed, run the same DAG sequentially and
-  use honest copy: `I’ll tighten the filter first, then draft the message from
-the same sample.` Never say `kicking off two workstreams`, `in parallel`, or
-  `background` unless parallel branches were actually launched.
+- Parallel means real parallel execution, not optimistic progress copy. For the
+  lead-source scout in Codex, explicitly spawn one named custom scout per
+  credible source lane when subagents are available: `linkedin_engagement_scout`
+  (display: LinkedIn Engagement Scout, powered by the `signal-discovery`
+  provider prompt), `sales_nav_scout` (Sales Nav Scout), and
+  `prospeo_contact_scout` (Prospeo Contact Scout). For Claude Code, explicitly
+  invoke the generated `.claude/agents/lead-explorer-*.md` Task/Agent subagents
+  for all credible lanes in one assistant message; they are installed from the
+  same canonical Sellable agent registry and carry explicit Sellable MCP tool
+  allowlists. If host subagents are unavailable, use independent MCP/tool calls
+  in the same model turn or dedicated Sellable MCP tools that perform
+  server-side `Promise.all` fan-out. If real parallel execution is not available
+  or not allowed, run the same DAG sequentially and use honest copy: `I’ll tighten the filter first,
+then draft the message from the same sample.` Never say `kicking off two
+workstreams`, `in parallel`, or `background` unless parallel branches were
+  actually launched.
 - Never run a downstream stage until the active `flow.v2.json` step's
   `requiredArtifacts` exist.
 - Never call a tool outside the active step's `allowedTools`, and never call a
@@ -600,18 +603,24 @@ Required behavior:
 - do not mutate DB-backed campaign state
 - run a real parallel source-angle scout when the source is not supplied and at
   least two viable source angles exist. Treat source scouting as independent
-  branches, then compare the outputs in `lead-review.md`. If the realistic
-  source set is Signals + Sales Nav, run both. If it is Signals + Prospeo, run
-  both. If all three are credible, run all three when the host/runtime supports
-  it.
-  - Branch A: Signals / active LinkedIn posts. Search relevant keyword lanes,
-    review finalist posts, fetch top-post engagers, and estimate warm-fit
-    volume.
+  branches, then compare the outputs in `lead-review.md`. In Codex, explicitly
+  spawn named custom subagents in the same turn: `linkedin_engagement_scout`,
+  `sales_nav_scout`, and `prospeo_contact_scout` for the credible lanes. Codex
+  does not infer this from generic "compare paths" wording. If the realistic
+  source set is LinkedIn Engagement + Sales Nav (Signals + Sales Nav), run both.
+  If it is LinkedIn Engagement + Prospeo Contact (Signals + Prospeo), run both.
+  If all three are credible, run all three when the host/runtime supports it.
+  In Claude Code, launch the matching `lead-explorer-signals`,
+  `lead-explorer-sales-nav`, and/or `lead-explorer-prospeo` Task/Agent subagents
+  in the same assistant message, not as sequential scout turns.
+  - Branch A: LinkedIn Engagement / active LinkedIn posts (internal provider:
+    Signals / `signal-discovery`). Search relevant keyword lanes, review
+    finalist posts, fetch top-post engagers, and estimate warm-fit volume.
   - Branch B: Sales Nav / title + company filters. Run preview filters, inspect
     preview rows, and estimate scalable-fit volume.
-  - Branch C: Prospeo / domains only when the campaign has a domain/account
-    path or the user supplied domains. Estimate email/contact scale and call out
-    weaker LinkedIn activity.
+  - Branch C: Prospeo Contact / domains only when the campaign has a
+    domain/account path or the user supplied domains. Estimate email/contact
+    scale and call out weaker LinkedIn activity.
     If the host cannot run these branches in parallel, run them sequentially and
     do not claim they ran in parallel. If only one source angle is credible, say
     that and run the best primary source plus one cheap fallback/quality check

package/skills/create-campaign-v2/SOUL.md

@@ -224,8 +224,17 @@ setting: `~/.codex/config.toml` with
 Source-angle comparison should be real, not implied. When the source is not
 supplied and multiple source angles are viable, scout Signals, Sales Nav, and
 relevant domain/contact paths as independent branches when the host can do so.
-If the host runs them sequentially, keep the output numeric but do not claim the
-source scout was parallel.
+In Codex, explicitly spawn named custom scouts in the same turn:
+`linkedin_engagement_scout` (LinkedIn Engagement Scout, backed by the
+`signal-discovery` provider prompt), `sales_nav_scout` (Sales Nav Scout), and
+`prospeo_contact_scout` (Prospeo Contact Scout) for the credible lanes. Codex
+does not infer subagent fan-out from generic "compare paths" wording. In Claude
+Code, invoke the generated `lead-explorer-signals`, `lead-explorer-sales-nav`,
+and/or `lead-explorer-prospeo` Task/Agent subagents in one assistant message so
+Claude can run the source lanes concurrently/background. These agents come from
+the same canonical Sellable registry and must load their matching provider
+prompt before searching. If the host runs them sequentially, keep the output
+numeric but do not claim the source scout was parallel.
 
 Only promise parallel post-lead work when parallel work actually started. If the
 host cannot or should not launch background branches, say the real sequence:

package/skills/create-campaign-v2/core/flow.v2.json

@@ -341,7 +341,7 @@
           "action": "run_subskill",
           "target": "find-leads",
           "mode": "campaignless-preview",
-          "sourceScoutRule": "When source is not user-supplied and at least two viable source angles exist, scout independent source angles with product-native parallelism when host/tooling permits: independent MCP/tool calls in the same model turn or dedicated Sellable MCP tools that perform server-side fan-out. Signals active-post branch + Sales Nav title/company branch, Signals + Prospeo when domains/accounts are relevant, or all three when credible. Do not rely on Codex subagents for a normal $sellable:create-campaign invocation; use host subagents only when the user explicitly asked for agent fan-out. If real parallel execution is unavailable, run the same scouts sequentially and do not claim parallel execution. Compare outputs by raw volume, n/N sampled fit, estimated good-fit range, expected reply range, and tradeoff. Keep Signals as viable when selected posts can produce ~150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable; when both are viable, present the choice and recommend the stronger default."
+          "sourceScoutRule": "When source is not user-supplied and at least two viable source angles exist, scout independent source angles with real parallelism when host/tooling permits. In Codex, explicitly spawn one named custom scout per credible lane in the same turn: linkedin_engagement_scout for LinkedIn Engagement / active post engagers (internal signal-discovery provider prompt), sales_nav_scout for Sales Nav title/company/activity filters, and prospeo_contact_scout for Prospeo account/domain/contact expansion. In Claude Code, explicitly invoke the generated lead-explorer-signals, lead-explorer-sales-nav, and/or lead-explorer-prospeo Task agents / Agent subagents in one assistant message so the lanes can run concurrently/background; those agents are installed from the canonical Sellable agent registry and carry explicit Sellable MCP tool allowlists. Fallback to independent MCP/tool calls in the same model turn or dedicated Sellable MCP tools that perform server-side fan-out. Run LinkedIn Engagement + Sales Nav, LinkedIn Engagement + Prospeo Contact, or all three when credible. If real parallel execution is unavailable, run the same scouts sequentially and do not claim parallel execution. Compare outputs by raw volume, n/N sampled fit, estimated good-fit range, expected reply range, and tradeoff. Keep Signals/LinkedIn Engagement as viable when selected posts can produce ~150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable; when both are viable, present the choice and recommend the stronger default."
         },
         {
           "action": "write_artifacts",
@@ -479,7 +479,7 @@
             "parallel only if real parallel branches were launched"
           ],
           "timeEstimate": "~2-3 min",
-          "chatRenderRule": "If real parallel MCP/tool branches or explicitly requested host subagents were actually launched, say: 'I’m kicking off two workstreams now' and list 'Tighten the fit filter' and 'Message generation'. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then run message generation from the same approved brief and sample leads.' Never claim parallelism unless parallel execution actually started. A normal $sellable:create-campaign invocation is not an explicit request for Codex subagents. User-facing stage name is message generation; message-validation.md is only the internal artifact."
+          "chatRenderRule": "If real parallel MCP/tool branches or host subagents were actually launched, say: 'I’m kicking off two workstreams now' and list 'Tighten the fit filter' and 'Message generation'. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then run message generation from the same approved brief and sample leads.' Never claim parallelism unless parallel execution actually started. User-facing stage name is message generation; message-validation.md is only the internal artifact."
         },
         {
           "action": "ask_continue_revise_or_confirm_only_if_needed",

package/skills/find-leads/SKILL.md

@@ -65,10 +65,28 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
 
 ## Execution Backend Routing
 
-- If `Task` is available, deep exploration uses the file-backed explorer agents:
+- If Codex subagents are available, run the scout lanes with named custom
+  agents. Spawn one agent per credible lane in the same turn, then wait for all
+  lane results before synthesizing `lead-review.md`:
+  - `linkedin_engagement_scout` (display: LinkedIn Engagement Scout) for
+    active LinkedIn posts and engagers; internally this uses the
+    `signal-discovery` provider prompt plus `search_signals` /
+    `fetch_post_engagers`.
+  - `sales_nav_scout` (display: Sales Nav Scout) for Sales Navigator title,
+    company, geography, and activity filters.
+  - `prospeo_contact_scout` (display: Prospeo Contact Scout) for Prospeo
+    account/domain and verified-contact expansion.
+- Common parallel comparisons are LinkedIn Engagement + Sales Nav, LinkedIn
+  Engagement + Prospeo Contact, or all three when each lane is credible.
+- If Claude `Task`/`Agent` is available, deep exploration uses the file-backed
+  Claude explorer agents installed from the same canonical Sellable agent
+  registry. Launch every credible lane in the same assistant message so Claude
+  Code can run them concurrently/background:
   - `./.claude/agents/lead-explorer-signals.md`
   - `./.claude/agents/lead-explorer-sales-nav.md`
   - `./.claude/agents/lead-explorer-prospeo.md`
+- These Claude agents must have explicit Sellable MCP tool allowlists and must
+  load the matching provider prompt before searching.
 - Else if `multi_tool_use.parallel` is available, run independent discovery calls in parallel and synthesize locally.
 - Else run sequentially.
 - Never claim agents were used when they were not.
@@ -236,10 +254,15 @@ Use the existing provider tools to run a small, directional probe:
 If the first probe is weak or noisy and enough context exists, try 1-2 alternate hypotheses before returning.
 If the first probe has good quality but insufficient scale, iterate 1-2 times to widen intelligently before returning.
 When two or more source angles are viable, run the provider probes in real
-parallel when the host/runtime allows it. Examples: Signals + Sales Nav,
-Signals + Prospeo, or Sales Nav + Prospeo. If the host cannot run them in
-parallel, run the same probes sequentially and do not claim they ran in
-parallel.
+parallel when the host/runtime allows it. For Codex, explicitly spawn the
+named source scout agents above; Codex will not infer subagent fan-out from
+general "compare sources" wording. For Claude Code, explicitly invoke the
+matching `lead-explorer-*` Task/Agent subagents in one message instead of
+probing one lane, waiting, then probing the next. Examples: LinkedIn Engagement
+
+- Sales Nav, LinkedIn Engagement + Prospeo Contact, or Sales Nav + Prospeo
+  Contact. If the host cannot run them in parallel, run the same probes
+  sequentially and do not claim they ran in parallel.
 
 Treat refinement as a measured loop:
 
@@ -400,7 +423,9 @@ Show the light-touch results and ask whether to deep-dispatch or iterate.
 
 ## Layer 3: Selective deep exploration
 
-Spawn only the validated paths from Gate 1.
+Spawn only the validated paths from Gate 1. In Claude Code, invoke all selected
+`lead-explorer-*` agents in one turn so source scouting is concurrent when the
+runtime supports it.
 
 - `lead-explorer-signals`
 - `lead-explorer-sales-nav`