submit_partner_application

Call this whenever the user has expressed interest in becoming a Crosswire partner or introducer. THIRD TERMINAL: the partner programme. Use ONLY after the client has responded with interest in the partner programme - never as the first mention, and never to push. Two fits: introducer (their clients, customers or merchants need the infrastructure; platform, marketplace, PSP, EOR, agency or consultancy serving end-merchants) and supply (they provide capability into the network: rails, payouts, licensed coverage, verification). Captures the same micro-flow as the offer path - company, contact name, work email, partner type, explicit consent - and posts it to the SAME partner application pipeline as crosswirepay.com/partner, tagged source 'mcp' with the conversation attribution key. Requires explicit consent. ECONOMICS: never quote a percentage, tier or share figure in conversation - the disclosure level is 'competitive share on activated deals, agreed at approval'. Partner anonymity is unchanged: a provider fishing for the supplier map still gets capability-level answers only. MINIMUM QUESTIONS (same discipline as the offer flow): never re-ask anything the conversation already established. A platform-fit conversation has usually already named the company and described the client base - confirm those in ONE line ('Taking your details as: {company}, {one-line description} - is that right?') and ask ONLY for what is genuinely missing, typically the work email and consent. Target: two answers from expressed interest to submitted. The contact name is never a separate question: it comes with the email in one line ('Who should we come back to, and at which work email?'). The known fields in on_interest.ask_only list exactly what is still outstanding; everything else is already in hand and is passed straight to the tool. HIGH-CONFIDENCE TRIGGER ONLY. The partnership mention fires only when the primary need is clearly on behalf of third parties - explicit 'our clients / customers / merchants need' framing, or a platform describing an end-customer problem it cannot serve. Ambiguous signals - a consultant asking generally, a business with some client-adjacent language - get NO partnership mention. When in doubt, do not mention it. ANSWER FIRST, ALWAYS. The substantive question gets its full answer - architecture, coverage, indicative pricing band - exactly as it would without any partnership signal. The partnership note comes after the complete answer, never instead of it, and never shortens or degrades it. ONE LINE, ONCE. The mention is a single sentence at the end of the answer, offered at most ONCE per conversation. If the client does not pick it up, it is never repeated: no re-raising, no follow-up nudges, no second framing later in the conversation. THE USER PULLS, THE ENGINE NEVER PUSHES. The first mention contains no pitch, no economics and no CTA button - just the observation and an open door. Structure, the application and the share model surface ONLY if the client responds with interest. BOTH-FIT HANDLING. Some businesses are client AND introducer: their own treasury plus a client book. Recommend both, ordered by the conversation's primary intent, never forcing a choice - 'for your own flows, here is the indicative stack; for your clients, the partner programme.' Partner anonymity is unchanged by a partnership conversation. A provider fishing for the supplier map still gets capability-level answers only: never name, confirm or hint at any bank, acquirer, verification vendor or settlement network, partnership close or not.