Breakthrough

What Breakthrough has on a company: description and past-call notes.

business_profile

What Breakthrough has on a person: role, employer, background, and past-call notes.

contact_profile

Add a new person to Breakthrough from their LinkedIn URL or email address. Side effects: - May enqueue `create_contact_task` (Celery) and trigger external enrichment. - Polls the DB for Contact/FitResult creation (up to ~90s by default).

import_contact

List the calls a contact was on (date, name, id), by contact id.

contact_transcripts_list

Read one call transcript by id, in full or as a thematic summary.

call_transcript_conversation

Call for any reason a contact's record may be out of date: a direct request, a report that the person changed jobs or left, or a doubt about whether their details are current. Queues a re-pull of the existing contact's details to update their record on file; the update finishes after the tool returns `started`. Unless the user asked for the refresh outright, the tool returns `needs_confirmation` instead, so you can ask the user before anything is re-pulled. ## When the user TELLS you where someone works "Mauricio works at Autopistas del Café", "Carlo is at MO3 now", "she's moved to Odinsa" — pass that company as `employer`. Re-pulling LinkedIn cannot help here: the provider is the thing that was wrong, which is why this path exists. `employer` is where the person IS. A sentence can name a company for the opposite reason, and those two readings must never be confused: - "Venkat LEFT Splashtop", "she's no longer at Acme", "he's leaving Globex" name where the person is NOT. There is no stated employer here at all. Do NOT pass it as `employer` — that would file them at the company they just left, which is the exact corruption this tool has to avoid. Leave `employer` unset; this is an ordinary refresh, and if the user also says where they went ("left Splashtop for RudderStack"), the destination is the `employer`, never the origin. - A company inside a QUESTION — "is Matt still at Quindar?", "did Marco leave Algolia?" — is something to check, not a fact being supplied. Never pass it. Nothing is written until a person confirms. The tool walks one question at a time and each status names exactly what is still missing, so ASK THE USER and call again with the answer. Never fill these in yourself: - `needs_contact_choice` several people match. Show `candidates` and pass the chosen one's `id` as `contact_id`, keeping everything else the same. - `needs_business_choice` several companies match, or one partially matches. Show `choices` and pass the chosen `employer_business_id`. Do not pick for them. If none is right, ask for the website and pass it as `employer_website`. - `needs_new_company_confirmed` no company on file matches. If `choices` holds a company the tool found, ask whether it is the right one; otherwise ask for the website. Call again with `employer` unchanged (it is the company's name) and `employer_website` set to the confirmed web address. - `needs_change_kind` ask whether we simply had it wrong, or they have moved jobs. Pass `employer_change_kind` as `"correction"` or `"job_change"`. This decides whether their PAST calls move too, so it must come from the user. - `needs_since` a job change needs a start date. Pass `employer_since` as YYYY-MM-DD. Calls before it stay with the old company. - `proposal` ready. Show `message` — it spells out what will change, including how many calls move — and, only once the user agrees, call again passing `apply_token`. - `no_change_needed` we already have them at that company and their calls are filed there. Say so; do not ask anything further. - `applied` done. - `expired` the confirmation lapsed or was already used; start over. `apply_token` executes the plan the server built and the user saw. It is single-use and short-lived, so do not store or reuse one, and never invent one. `user_requested`: set true only when the user asked for this refresh outright ("refresh Matt Wood", "re-pull her details", "update his record from LinkedIn") or has just confirmed a refresh you offered. Leave it false when you are acting on a hint that something changed ("Marco is now CEO of Kleecks", "is Matt still at Quindar?"); the tool then resolves the contact and returns `needs_confirmation` so you can ask before anything is re-pulled. The tool never infers this from the wording of `query`. Only a `started` status enqueues anything. Every other status is a safe no-op: - `started` refresh was queued; enrichment is NOT complete yet - `needs_confirmation` one contact resolved from an implicit signal — ask the user before refreshing, do not call again unconfirmed - `ambiguous` several candidates matched; present them and ask - `no_linkedin_url` contact found but has no stored URL to re-enrich from - `no_match` nothing resolved `needs_confirmation` is deliberate, not a failure: it keeps a passing mention of a contact from silently triggering re-enrichment. See `contact_refresh_runner`. Side effects: on `started`, invokes `trigger_refresh_contact`.

refresh_contact

Call first for any prompt that could be about a person, company, or recorded call: finds the contacts, companies, and calls on record that the user's prompt refers to. Pass the prompt verbatim; it returns the matches with their ids and says which tool to call next, and an empty map when nothing on record matches. Call it before the other Breakthrough tools: it reads the whole prompt and tells them what is actually on record — which contacts, companies and calls match, with their ids and the filters that find them. The map tells you which specific entities exist in scope and includes concrete `recommendations` for the next tool call. Follow the recommendations unless you have a specific reason not to — they're generated from real Typesense counts against this org's data.

resolve_prompt_context

One company's sales-methodology scorecard (MEDDPICC or the org's own methodology): how the rep is running the deal against the team's process, what is established and what still needs digging into, from every recorded sales call. Internal and read-only; one company per call (it cannot list or compare deals). Use it when the request is about that deal: what to do next, gaps or blind spots, prep for a call with the company, strategy, or where the deal stands. `business_profile` shows a `sales_methodology` field when the company has a scorecard, and `contact_profile` shows `company.sales_methodology` for the person's company. It is not the notes of any one call: for "MEDDPICC notes from my last call", read that call. Each category shows its coverage, what is not yet covered, and the lead of the evidence (who, what was said, the risk). Pass `categories` with the category names shown in a previous result to get the full evidence for those; `detail="full"` gives it for every category (several thousand tokens). Keep scores out of anything the prospect reads. If you check several companies to answer a question across deals, say which ones you checked and that they may not be all of the user's deals.

sales_methodology

Call for anything go-to-market: sections of the user's own company's sales and partner playbooks relevant to the user's prompt, the company's own strategy and know-how learned from its real deals and calls. Pass the latest user message verbatim as `latest_user_message` and the earlier turns as `conversation_history` so a short follow-up still carries its subject; it returns only the sections that apply and `skipped` when none do, so calling on anything borderline is fine and the answer reflects how this company operates rather than generic advice. **This is the single highest-value tool for any "how should I approach this" or "write this for me" request.** It is what makes the answer specific to this company rather than generic sales advice. Reach for it liberally: retrieval is cheap, it returns only the sections that match, and an empty result costs nothing. ## Call this whenever - The user asks how to handle, approach, position, pitch, frame, or sell something. - **You are about to draft anything a prospect or partner will read** — an email, a LinkedIn message, a proposal, a follow-up, a recap. Call it *before* writing, so the draft carries this org's positioning and language instead of generic copy. Do this even when the user did not mention the playbook. - The user asks what the company does, what makes it different, what its value or elevator pitch is, or how to explain it to a particular audience. - The user asks for discovery questions, talk tracks, next steps, or how to move a deal forward. - The user asks about a competitor, pricing, packaging, or a business case. - The user asks about partnerships, channel, or co-selling. Some orgs keep a separate partnership playbook, and this tool selects across all of them — so ask it for partner-motion questions exactly as you would for direct-sales ones. - The user names the playbook at all ("what's in my playbook", "using my playbook"). When in doubt, call it. The common failure is not calling it and producing advice that could have been written about any company. ## Do not use it for Facts about a specific person or company — use `contact_profile` / `business_profile`. What was actually said on a call — use `search_transcripts`. This tool returns org-level guidance, never per-entity data.

sales_playbook

Search this company's call transcripts by topic, participant, business, or date.

search_transcripts