@sellable/mcp 0.1.233 → 0.1.235

package/dist/tools/leads.js

@@ -522,7 +522,7 @@ search_prospeo_companies({
   }
 })
 Do not invent company_oids. When seedCompanies or seedDomains are present, omit company_oids and let the backend resolve real Prospeo company IDs.
-For customer, best-customer, top-customer, or past-company lookalikes, never substitute the sender's current company or domain as a lookalike seed and never use the sender's current company/domain as a silent substitute. Use explicit customer/account/company/domain input first, then verified customer/worked-with/past-company evidence from research/proof, then ask for the missing seed or switch to non-lookalike company filters if YOLO requires moving without a seed. Label profile/work-history seeds as past-company/public proof clues, not confirmed customers unless the source proves customer status. If the user asks for a geography like Germany, preserve it in company discovery where supported and in the follow-on people search.
+Route lookalike seed selection by campaign intent. For outbound/sales prospecting, use explicit target/account/customer domains or company names first, then verified past-customer/account evidence from research, CRM, or proof; never substitute the sender's company/domain or employer history unless it is confirmed as a target/customer seed or the user asks for sender-company peers. For job-search/application campaigns, current/past employers can be lookalike seeds because they define the candidate-fit lane. If intent or seed source is ambiguous, ask target/customer domains vs current/past employers, or switch to non-lookalike filters under YOLO. If the user asks for a geography like Germany, preserve it in company discovery where supported and in the follow-on people search.
 After account approval, copy the companySearchToken exactly into confirm_prospeo_company_accounts; package-backed MCP may return a short mcp-prospeo-company-search-token:* reference to avoid long-token copy errors.
 For accounts in the news: { "company_news": { "categories": ["Funding & Investment"], "timeframe_days": 90 } }.
 For awards: { "company_awards": { "include": ["G2"], "match_mode": "CONTAINS" } }.
@@ -1499,7 +1499,7 @@ export const leadToolDefinitions = [
     {
         name: "search_prospeo_companies",
         description: 'Search Prospeo for company/account results through the public /search-company lane. Requires get_provider_prompt({ provider: "prospeo" }) first. Use this first for company lookalike/account asks such as "find companies like Red Rover that use AI and have an API", "find founders at companies like our best customers", or "find accounts in the news about funding or partnerships". Results are accounts, not finished people leads. Review the returned accounts with the user, then call confirm_prospeo_company_accounts with the companySearchToken to create a domainFilterId before using search_prospeo for people at those accounts. Supports company lookalike, confirmed AI Attributes including pricing, company news, awards, website search, products/services, integrations, key customers, operating languages, Google discovery, headcount by location, structured company ICP, and experimental website traffic/key executive filters. Do not invent company_oids; when seedCompanies or seedDomains are present, omit company_oids and let the backend resolve real Prospeo IDs. company_intent and support-channel guesses like phone/email/chat/ticket/social are unsupported. Public API rows do not include lookalike tier/score/reason. If output includes omittedFilters or warnings, report them as truthful MCP/backend safety handling rather than claiming Prospeo enforced those omitted constraints. ' +
-            "For best-customer, top-customer, customer, or past-company lookalikes, never substitute the sender's current company/domain as the seed unless current-company peers were explicitly requested; use explicit or verified customer/account/past-company seeds and preserve geography like Germany in account or people filters. " +
+            "Route lookalike seeds by campaign intent: outbound uses explicit target/account/customer domains or verified past-customer accounts, not the sender company/domain; job-search/application campaigns may use current/past employers as existing-company seeds. Preserve geography like Germany in account or people filters. " +
             prospeoCompanyAccountWorkflowGuidance,
         inputSchema: {
             type: "object",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.233",
+  "version": "0.1.235",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.md

@@ -220,19 +220,21 @@ reference to avoid long-token copy errors. Account rows are not people leads
 yet. The confirmation creates the `domainFilterId` that constrains the follow-on
 `search_prospeo` people search.
 
-For lookalike seed selection, treat "best customer", "top customer", "past
-companies", "companies I worked with", and similar wording as customer/account
-or past-company seed asks. Never substitute the sender's current company or
-domain as a lookalike seed; never use the sender's current company/domain as a
-silent substitute unless the user explicitly asks for companies like the current
-employer, sender company, or its direct peers/competitors. Seed priority is:
-explicit user-provided customer/account/company/domain; verified
-customer/worked-with/past-company evidence from research/proof; then ask for the
-missing seed or switch to non-lookalike company filters if YOLO requires moving
-without a seed. If using profile/work-history seeds, label them as
-past-company/public proof clues, not confirmed customers unless the source proves
-customer status. If the user asks for a geography like Germany, preserve it in
-account discovery where supported (`company_location_search` or
+For lookalike seed selection, route by campaign intent. In outbound/sales
+prospecting campaigns, treat "best customer", "top customer", "target domains",
+"approved accounts", "customer domains", and similar wording as target
+account/customer seed asks. Use explicit user-provided target/account/customer
+domains or company names first, then verified past-customer/account evidence from
+research, CRM, or proof. Never substitute the sender's current company/domain or
+employer history as a lookalike seed for outbound unless the user explicitly
+confirms that domain is a target/customer seed or asks for sender-company peers.
+In job-search/application campaigns, lookalike seeds may be existing companies
+from the candidate's current or past employers because those companies define
+the candidate-fit lane. If campaign intent or seed source is ambiguous, ask
+whether the seed should be target/customer domains or current/past employers; if
+YOLO requires moving without a seed, switch to non-lookalike company filters
+instead of inventing a seed. If the user asks for a geography like Germany,
+preserve it in account discovery where supported (`company_location_search` or
 `company_icp.geographic_markets`) and in follow-on people search
 (`person_location_search`); do not drop geography when moving from lookalike
 accounts to people leads.

package/skills/create-campaign/core/providers/prospeo.json

@@ -24,13 +24,13 @@
     "useWhen": [
       "You want Prospeo filters or domain-based search",
       "You need company lookalike account discovery before finding people",
-      "You want companies like X, best-customer/top-customer/past-company lookalikes, or accounts using AI/API/SSO/Chrome extensions",
+      "You want companies like X, target-domain, best-customer/top-customer, or job-search employer lookalikes, or accounts using AI/API/SSO/Chrome extensions",
       "You need companies hiring for specific roles using job-posting filters",
       "You need high deliverability from Prospeo"
     ],
     "avoidWhen": ["You need LinkedIn activity filters"],
     "reason": "Strong for hiring-led search, company/account lookalikes, Prospeo-specific filters, verified contacts, and domain lists.",
-    "prose": "Since you're targeting **{icp}**, I'd recommend **Prospeo**.\n\nHere's why:\n- Prospeo can discover lookalike accounts first, then turn approved accounts into a domainFilterId for people search\n- Prospeo can filter for companies hiring specific roles with job-posting filters\n- We can pair those company signals with buyer/referrer titles and verified-contact coverage\n\nFor lookalike accounts, I will show an account sample first; those account rows are not people leads yet. After approval, I will use the companySearchToken to confirm the accounts, then search people at the returned domainFilterId. For best-customer, top-customer, or past-company lookalikes, I will use explicit customer/account/past-company seeds, not the sender's current company, unless you explicitly ask for current-company peers.\n\nShould I search Prospeo for {icp}?"
+    "prose": "Since you're targeting **{icp}**, I'd recommend **Prospeo**.\n\nHere's why:\n- Prospeo can discover lookalike accounts first, then turn approved accounts into a domainFilterId for people search\n- Prospeo can filter for companies hiring specific roles with job-posting filters\n- We can pair those company signals with buyer/referrer titles and verified-contact coverage\n\nFor lookalike accounts, I will show an account sample first; those account rows are not people leads yet. After approval, I will use the companySearchToken to confirm the accounts, then search people at the returned domainFilterId. For outbound lookalikes, I will use target/account/customer domains or verified past-customer accounts, not the sender's company. For job-search/application lookalikes, I can use current or past employers as existing-company seeds.\n\nShould I search Prospeo for {icp}?"
   },
   "askOption": {
     "label": "Prospeo",

package/skills/create-campaign/references/provider-selection-strategy.md

@@ -99,7 +99,7 @@ Is your ICP LinkedIn-active (founders, sales, marketing, GTM, engineers)?
 Need hiring-by-role filters? -> Prospeo (has company job-posting filters)
 Need tech stack targeting? -> Apollo (has technology filters)
 Have specific company names/domains? -> Sales Navigator for small lists or Prospeo with domainFilterId
-Need companies like X, best-customer/top-customer/past-company lookalikes, AI/API/SSO/Chrome extension filters, news/awards/integrations/key customers? -> Prospeo account discovery first; use explicit customer/account/past-company seeds, not the sender's current company unless current-company peers were requested
+Need companies like X, target-domain lookalikes, best-customer/top-customer lookalikes, job-search employer lookalikes, AI/API/SSO/Chrome extension filters, news/awards/integrations/key customers? -> Prospeo account discovery first; outbound uses target/account/customer domains or verified past-customer accounts, while job-search/application campaigns can use current/past employers as existing-company seeds
 ```
 
 ## ICP-to-Provider Quick Reference

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

@@ -188,19 +188,21 @@ Show the account sample first, ask approval, then pass the returned
 `confirm_prospeo_company_accounts`. The confirmed `domainFilterId` constrains
 the follow-on people search; account rows are not people leads yet.
 
-For lookalike seed selection, treat "best customer", "top customer", "past
-companies", "companies I worked with", and similar wording as customer/account
-or past-company seed asks. Never substitute the sender's current company or
-domain as a lookalike seed; never use the sender's current company/domain as a
-silent substitute unless the user explicitly asks for companies like the current
-employer, sender company, or its direct peers/competitors. Seed priority is:
-explicit user-provided customer/account/company/domain; verified
-customer/worked-with/past-company evidence from research/proof; then ask for the
-missing seed or switch to non-lookalike company filters if YOLO requires moving
-without a seed. If using profile/work-history seeds, label them as
-past-company/public proof clues, not confirmed customers unless the source proves
-customer status. If the user asks for a geography like Germany, preserve it in
-account discovery where supported (`company_location_search` or
+For lookalike seed selection, route by campaign intent. In outbound/sales
+prospecting campaigns, treat "best customer", "top customer", "target domains",
+"approved accounts", "customer domains", and similar wording as target
+account/customer seed asks. Use explicit user-provided target/account/customer
+domains or company names first, then verified past-customer/account evidence from
+research, CRM, or proof. Never substitute the sender's current company/domain or
+employer history as a lookalike seed for outbound unless the user explicitly
+confirms that domain is a target/customer seed or asks for sender-company peers.
+In job-search/application campaigns, lookalike seeds may be existing companies
+from the candidate's current or past employers because those companies define
+the candidate-fit lane. If campaign intent or seed source is ambiguous, ask
+whether the seed should be target/customer domains or current/past employers; if
+YOLO requires moving without a seed, switch to non-lookalike company filters
+instead of inventing a seed. If the user asks for a geography like Germany,
+preserve it in account discovery where supported (`company_location_search` or
 `company_icp.geographic_markets`) and in follow-on people search
 (`person_location_search`); do not drop geography when moving from lookalike
 accounts to people leads.
@@ -231,7 +233,7 @@ Discovery", "lead-source scouting", "source scouting", "lane", "provider",
 pain", or "ICP". Only the approval question after that visible plan, or an
 explicit post-plan source choice, satisfies this gate. Do not ask a second
 source-plan question or call `search_signals`, `search_sales_nav`,
-`search_prospeo`, `search_prospeo_companies`, `fetch_post_engagers`, or provider subagents until approved.
+`search_prospeo`, `fetch_post_engagers`, `search_prospeo_companies`, or provider subagents until approved.
 Only then persist `leadSourceType`, `leadSourceProvider`, and provider `currentStep`.
 
 Source work stays inline in the parent thread in normal create-campaign runs.
@@ -290,79 +292,15 @@ customer-facing source-choice labels.
 
 ## Prospect Setup Workstreams
 
-After `confirm_lead_list` copies a non-empty source into the campaign and
-records the compact review batch, ask the filter-choice question immediately.
-Do not call
-`get_post_find_leads_scout_registry`, load filter/message subskill prompts, or
-spawn Message Drafting before that question. The only
-customer-facing work before the question should be a short setup summary and the choice:
-add filters, skip filters, or revise source. Do not include another watch link
-in this summary; the existing app view updates through campaign state.
-
-After filter choice, the only normal background worker is Message Drafting
-(`post-find-leads-message-scout`). The registry lookup is not a launch. Call
-the registry, then start Message Drafting via `Task`, `spawn_agent`, or host
-equivalent before loading `references/filter-leads.md` or `save_rubrics`. YOLO
-already grants permission; do not ask for another permission click. If no
-background tool is callable, start the same full branch inline before filter
-drafting or return `blocked` / `retry-needed`. Do not wait until filters are
-saved and then call the registry. Debug artifacts are optional only.
-
-The parent thread is the orchestrator and the filter writer. On the filters
-path, immediately start Message Drafting in the background, then load
-`references/filter-leads.md`, draft production rubrics in the parent, call
-`save_rubrics`, and ask for filter approval. Do not render message review, queue
-cells, or move past Filter Rules until saved filters are approved and
-`messageDraftRecommendation` is ready.
-
-Keep the Message Drafting handoff lean: `campaignId`, `workflowTableId`, a
-concise brief summary, concise source summary/source-use rule, and 3-5 sample
-workflow-table rows with `rowId`, name, title, company, and signal. Optional:
-campaign name, `selectedLeadListId`, and filter choice. Do not paste copied row
-counts, brief hashes, review-batch hashes, full row ID lists, broad row data, or
-local debug artifacts. The branch loads the current brief/context and sample
-rows through Sellable tools before drafting.
-
-When the user chooses filters, immediately call
-`update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
-so the app is on Filter Rules while Message Drafting runs. After
-`save_rubrics`, keep Filter Rules visible so the user can approve saved
-criteria. Only after approval should
-`update_campaign` move to `apply-icp-rubric` / Filter Leads and show
-`Filters saved + waiting for message approval` until the template is approved.
-Do not queue enrichment/filtering/Generate Message cells until message
-approval. Tell the user Message Drafting is preparing the template in the
-background.
-
-Codex: outside YOLO/autonomous mode only, ask once if worker permission is
-missing. Use generic `gpt-5.5` / `xhigh` Message Drafting if needed.
-
-If the user critiques or edits the template before `approve-message`, route the
-feedback back to Message Drafting with current `messageDraftRecommendation`,
-basis token, campaign/table basis, and latest user text. Do not rewrite copy in
-the parent or call `update_campaign_brief`. Message Drafting must load the full
-`generate-messages` prompt, all referenced assets, and
-`create-campaign-v2-validation`, then return a revised
-`messageDraftRecommendation`; parent renders it and asks approval. Message QA
-and validation before approval also belong to Message Drafting, but validation
-is an internal gate. Do not render `renderedFallbackSample`, `concerns`, or a
-full `qaReceipt` in the normal happy path.
-
-Run `post-find-leads-message-scout` as Message Draft Builder when exposed. It
-must load:
+After `confirm_lead_list` copies a non-empty source into the campaign and records the compact review batch, ask the filter-choice question immediately. Do not call `get_post_find_leads_scout_registry`, load filter/message prompts, or spawn Message Drafting before that question. Customer-facing work before the question: short setup summary plus add filters, skip filters, or revise source; no extra watch link.
 
-```text
-get_subskill_prompt({ subskillName: "generate-messages" })
-get_subskill_asset(...) for every required message asset named by generate-messages Mode 0
-get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })
-```
+After filter choice, the only normal background worker is Message Drafting (`post-find-leads-message-scout`). The registry lookup is not a launch. Call the registry, then start Message Drafting via `Task`, `spawn_agent`, or host equivalent before loading `references/filter-leads.md` or `save_rubrics`. YOLO already grants permission; do not ask for another permission click. If no background tool is callable, start the same full branch inline before filter drafting or return `blocked` / `retry-needed`. Do not wait until filters are saved and then call the registry.
+
+The parent thread is the orchestrator and the filter writer. On the filters path, start Message Drafting, then load `references/filter-leads.md`, save rubrics, and ask users to approve saved criteria. Keep `currentStep` on Filter Rules and show `Filters saved + waiting for message approval`; do not queue cells until message approval. Tell the user Message Drafting is preparing the template in the background.
+
+Keep the handoff lean: `campaignId`, `workflowTableId`, concise brief/source summary, source-use rule, and 3-5 sample rows (`rowId`, name, title, company, signal). Do not paste copied row counts, hashes, full row IDs, broad row data, or local debug artifacts.
 
-After candidate generation/revision and before returning `ready`, Message Draft
-Builder must load `create-campaign-v2-validation` through MCP as the final gate.
-No alternate, examples-only, or local-artifact prompt. If the agent cannot
-launch, the parent fallback runs the same gate from live state. Render review
-only after `messageDraftRecommendation` proves current campaign/table basis.
-Handoff: labeled Markdown, not raw JSON.
+Route user copy feedback before `approve-message` back to Message Drafting; parent does not rewrite. The branch loads the full `generate-messages` prompt, every required asset, then `get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`; do not render `renderedFallbackSample`, concerns, or `qaReceipt` in the happy path. Generic fallback is `gpt-5.5` / `xhigh` Message Drafting. Handoff is labeled Markdown, not raw JSON.
 
 ## Hard Gates
 

package/skills/find-leads/SKILL.md

@@ -391,22 +391,25 @@ Use first for broad persona expansion, ABM/domain targeting, hiring-led targetin
 - For companies like X, our best customers, lookalike accounts, companies that use AI, companies with API/SSO/Chrome extension, or
   news/award/integration/key-customer account filters, use
   `search_prospeo_companies` before people search.
-- For lookalike seed selection, treat "best customer", "top customer", "past
-  companies", "companies I worked with", and similar wording as
-  customer/account or past-company seed asks. Never substitute the sender's
-  current company or domain as a lookalike seed; never use the sender's current
-  company/domain as a silent substitute unless the user explicitly asks for
-  companies like the current employer, sender company, or its direct
-  peers/competitors. Seed priority is: explicit user-provided
-  customer/account/company/domain; verified customer/worked-with/past-company
-  evidence from research/proof; then ask for the missing seed or switch to
-  non-lookalike company filters if YOLO requires moving without a seed. If using
-  profile/work-history seeds, label them as past-company/public proof clues, not
-  confirmed customers unless the source proves customer status. If the user asks
-  for a geography like Germany, preserve it in account discovery where supported
-  (`company_location_search` or `company_icp.geographic_markets`) and in
-  follow-on people search (`person_location_search`); do not drop geography when
-  moving from lookalike accounts to people leads.
+- For lookalike seed selection, route by campaign intent. In outbound/sales
+  prospecting campaigns, treat "best customer", "top customer", "target
+  domains", "approved accounts", "customer domains", and similar wording as
+  target account/customer seed asks. Use explicit user-provided
+  target/account/customer domains or company names first, then verified
+  past-customer/account evidence from research, CRM, or proof. Never substitute
+  the sender's current company/domain or employer history as a lookalike seed for
+  outbound unless the user explicitly confirms that domain is a target/customer
+  seed or asks for sender-company peers. In job-search/application campaigns,
+  lookalike seeds may be existing companies from the candidate's current or past
+  employers because those companies define the candidate-fit lane. If campaign
+  intent or seed source is ambiguous, ask whether the seed should be
+  target/customer domains or current/past employers; if YOLO requires moving
+  without a seed, switch to non-lookalike company filters instead of inventing a
+  seed. If the user asks for a geography like Germany, preserve it in account
+  discovery where supported (`company_location_search` or
+  `company_icp.geographic_markets`) and in follow-on people search
+  (`person_location_search`); do not drop geography when moving from lookalike
+  accounts to people leads.
 - Use Prospeo company/account search when the ask depends on website traffic
   (`company_website_traffic`), confirmed AI Attributes including `pricing`,
   `uses_ai`, `has_api`, `has_chrome_extension`, `has_sso`, `has_open_source`,

package/skills/providers/prospeo.md

@@ -87,19 +87,21 @@ backend resolves real Prospeo company IDs. Do not invent company_oids such as
 placeholder IDs from examples. Only send `company_lookalike.company_oids` when
 they are real Prospeo company IDs returned by a prior tool/search.
 
-For lookalike seed selection, treat "best customer", "top customer", "past
-companies", "companies I worked with", and similar wording as customer/account
-or past-company seed asks. Never substitute the sender's current company/domain
-as a lookalike seed, and never use the sender's current company/domain as a
-silent substitute unless the user explicitly asks for companies like the current
-employer, sender company, or its direct peers/competitors. Seed priority is:
-explicit user-provided customer/account/company/domain; verified
-customer/worked-with/past-company evidence from research/proof; then ask for the
-missing seed or switch to non-lookalike company filters if YOLO requires moving
-without a seed. If using profile/work-history seeds, label them as
-past-company/public proof clues, not confirmed customers unless the source proves
-customer status. If the user asks for a geography like Germany, preserve it in
-account discovery where supported (`company_location_search` or
+For lookalike seed selection, route by campaign intent. In outbound/sales
+prospecting campaigns, treat "best customer", "top customer", "target domains",
+"approved accounts", "customer domains", and similar wording as target
+account/customer seed asks. Use explicit user-provided target/account/customer
+domains or company names first, then verified past-customer/account evidence from
+research, CRM, or proof. Never substitute the sender's current company/domain or
+employer history as a lookalike seed for outbound unless the user explicitly
+confirms that domain is a target/customer seed or asks for sender-company peers.
+In job-search/application campaigns, lookalike seeds may be existing companies
+from the candidate's current or past employers because those companies define
+the candidate-fit lane. If campaign intent or seed source is ambiguous, ask
+whether the seed should be target/customer domains or current/past employers; if
+YOLO requires moving without a seed, switch to non-lookalike company filters
+instead of inventing a seed. If the user asks for a geography like Germany,
+preserve it in account discovery where supported (`company_location_search` or
 `company_icp.geographic_markets`) and in follow-on people search
 (`person_location_search`); do not drop geography when moving from lookalike
 accounts to people leads.
@@ -126,8 +128,9 @@ Avoidable-400 guardrails:
 - For seeded company lookalikes, keep the first call simple: seed company/domain + `company_lookalike.minimum_tier` + confirmed attributes, headcount, or industry. Do not add `company_website_search`, `company_keywords`, or `company_icp` until the account sample proves the seed works.
 - For seeded company lookalikes, do not combine `has_api` and `has_sso` in the first call; start with `has_api` and refine after a valid account sample if SSO still matters.
 - Do not send placeholder seed names such as `another approved best-customer seed`; use only concrete company names or domains you have actually resolved.
-- Do not silently use the sender company as a customer lookalike seed; use
-  explicit customer/account/past-company evidence instead.
+- Do not silently use the sender company as a customer lookalike seed for
+  outbound; use explicit target/account/customer domains or verified
+  past-customer evidence instead.
 - If the user references another approved seed but does not name it, ask for the
   seed or run a one-seed lookalike without `match_all`; do not invent a second
   seed from examples, competitors, or exclusions.
@@ -294,10 +297,11 @@ Preference rules:
 - Run `company_key_customers` as a standalone first-pass filter. Do not combine `company_key_customers` with ICP, website-search, keyword, attribute, industry, or headcount filters until the standalone pass proves useful.
 - For seeded lookalikes, avoid first-call `company_website_search`, `company_keywords`, and `company_icp`; use resolved seeds plus lookalike tier and simple attributes/headcount/industry first.
 - For seeded lookalikes, avoid first-call `has_api` + `has_sso`; use one confirmed attribute first, then refine.
-- For customer, best-customer, top-customer, or past-company lookalikes, never
-  use the sender's current company/domain as a silent substitute; use explicit
-  customer/account/past-company evidence, then label profile-derived seeds as
-  past-company/public proof clues unless customer status is verified.
+- For outbound customer, best-customer, or top-customer lookalikes, never use the
+  sender's current company/domain as a silent substitute; use explicit
+  target/account/customer domains or verified past-customer evidence. For
+  job-search/application campaigns, current/past employers may be the lookalike
+  seeds because the campaign is about finding similar employers.
 - If the user gives geography like Germany, keep that geography in the company
   discovery or follow-on people filters instead of dropping it after account
   confirmation.

package/skills/research/config.json

@@ -0,0 +1,9 @@
+{
+  "parallelMode": "wide",
+  "agentCount": 6,
+  "maxToolCallsPerAgent": 2,
+  "senderMaxAgents": 2,
+  "senderMaxToolCallsPerAgent": 3,
+  "progressMode": true,
+  "debugMode": true
+}