leadbay_setup_team_prospecting

Set up manager-led prospecting for me: turn the audience into a lens, validate candidates, then persist as named campaigns.

Audience: <Natural-language audience description (e.g. 'plumbing companies with 10-50 employees in Seine-Maritime'). The lens-creation step (leadbay_refine_prompt → leadbay_create_lens) interprets it. A country name is not a scope here — this workspace already covers exactly one country, so drop it and keep the rest of the description; a DIFFERENT country cannot be targeted at all. If not provided in the user's most recent message, ask once before proceeding.> <if the user supplied this argument, render the short block derived from it; otherwise empty. Source: Optional: how to split the validated leads into per-rep campaigns. Free text — e.g. 'split by city' or 'one campaign per rep: John gets Tulsa, Sarah gets OKC'. Splitting by country is not a split — the workspace is single-country.>

GATE — DEFER TO TOOL RENDERING. When you call a Leadbay composite that ships its own RENDERING block (every composite in 0.9.0+ does), render the response using that block's recipe verbatim — score bars, glyph palette, column order, hide-list, link priorities, all of it. Do NOT substitute prose, a numbered list, or a different column structure even when an orchestrating prompt's body suggests alternate framing. Prompt-specific commentary (motivational nudges, summaries, next-action recommendations) belongs ABOVE or BELOW the canonical table, never in place of it.

If the prompt's body and the tool's RENDERING appear to conflict, the tool's RENDERING wins for the structural layout; the prompt's voice wins for the commentary that surrounds it.

PHASE 1 — INTERPRET INTENT INTO A LENS

One workspace = one country — a country name is NEVER a location filter. The admin-area index holds no country nodes, so "France" matches the commune of Francs and "United States" matches Statesboro: the call is silently fenced to one village and every conclusion from it is wrong. City AND country named? Keep the city, drop the country.

On code: "COUNTRY_LEVEL_LOCATION" read country_locations[].axis and [].kind — the recovery differs per case and they are NOT interchangeable, and do NOT retry with another spelling or a nearby city.

axis: "include":

• home_country, or "nationwide" / "everywhere" → drop that ONE value. Omit the geo argument (city / locations / location_ids) only if nothing else was on it — then the result covers the whole workspace. If other values remain, keep them and describe the result as those places.
• foreign_country ("leads in France" on a US workspace) → unsupported, not unfiltered. Do NOT re-run without the argument: whole-workspace results are US leads and answer nothing about France. Say the workspace holds only its own country's companies.
• supranational ("EU", "EMEA") → name what the workspace covers, then offer the whole-workspace view as an explicit choice rather than assuming it.
• country_indeterminate (custom/staging backend) → its country is unknown, so claim nothing about what it holds.

axis: "exclude" reverses all of that — never "omit the argument", which returns the very companies the user asked to remove. Excluding this workspace's own country would empty it; excluding any other country is a harmless no-op. Either way drop the value and ask what to carve out instead.

On a lens-WRITING tool (new_lens, adjust_audience, update_lens_filter) write NOTHING, with no re-call in any form: when the country was the only scope; for ANY foreign_country or supranational INCLUDE however much else came with it — the sectors and sizes were QUALIFYING that territory, not a second request, so writing them alone saves a real audience for a territory nobody asked about; and for ANY non-foreign_country exclude hit, likewise — dropping it and writing the rest inverts the ask.

Never infer WHICH country this workspace serves from the user's wording — "the whole US" does not make it one. Read _meta.region on any tool result — it outranks any recalled memory; on custom, claim nothing.