leadbay_refine_audience

Refine the Leadbay audience prompt to: <The refinement (e.g. 'focus on hospitals running their own IT'). Set to plain English. If not provided in the user's most recent message, ask once before proceeding.>

PHASE 0 — GATE: RESOLVE THE REGION, STRIP THE COUNTRY, THEN CLASSIFY (may end the run)

A refine prompt shapes the KIND of company, never WHERE it is. Before any tool call:

Step 1 — if a COUNTRY is named at all, find out which country this workspace serves, and do it FIRST. Every later step turns on whether the country I named is this workspace's own, and you cannot tell that from my message: "French hospitals across France" is a redundant clause on an FR backend and an unsupported ask on a US one, and the language I write in says nothing about it. Do NOT guess from the country I named, from my language, or from the fact that the request sounds plausible — strip first and you will have already decided, silently and possibly wrongly, that the country was redundant. Every Leadbay tool result carries the fact at _meta.region (us | fr | custom); if no call this session has returned one, call leadbay_account_status — read-only, writes nothing — and read _meta.region from it. custom means the backend's country is unknown: claim nothing about which country it holds. Only a place BELOW country level ("in Paris", "Texas") skips this step.

Step 2 — now strip, and do not stop. With the region known, if my instruction names this workspace's own country or a whole-country scope ("nationwide", "the whole US", "partout en France"), remove that phrase and KEEP THE REST. It is redundant, never a filter — but it is almost never the whole instruction. "Hospitals running their own IT nationwide" is a refinement about hospitals; "hospitals in Paris, France" is Paris plus hospitals. Losing the rest because a country rode along is the worse error of the two. A country that is NOT this workspace's own is not stripped — it is the whole answer, and Step 3 handles it.

Step 3 — classify what REMAINS, and act on every part of it:

• Nothing remains (the country was the entire instruction) → STOP HERE. Call NOTHING. Do not continue to PHASE 1: leadbay_refine_prompt would overwrite my qualitative audience prompt and kick off an intelligence recompute to express a scope this workspace already has. Tell me there is nothing to set because the workspace already covers exactly that, offer the axes that do narrow an audience (sector, size, or a sub-country region / state / county / city), and end your turn.
• A DIFFERENT country ("partout en France" on a US workspace) → STOP HERE too, but do not say "there is nothing to set" — that is false. The ask is UNSUPPORTED, not already-satisfied: this workspace holds only its own country's companies, so there are no leads there to scope to. Say so plainly, do not offer an unfiltered view as if it answered the request, and end your turn. If a qualitative part rode along with it, say it cannot be applied to a country that is not here either.
• A supra-national scope ("EU-wide", "EMEA") → stop as well: name what the workspace covers and ask whether I want that instead, rather than assuming it.
• A sub-country place ("prospects in Texas", "restrict to Indre-et-Loire") → a place is not a qualitative refinement: route it to leadbay_adjust_audience({locations: [...]}) and say why. If a qualitative part ALSO remains, continue to PHASE 1 with that part — do not drop half the request.
• A qualitative refinement → continue to PHASE 1, passing the STRIPPED text and never the raw instruction.

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.