ClosedLoop AI

Build a sales proof packet from ClosedLoop AI evidence for sales decks, follow-up emails, reference snippets, and prospect conversations. Returns customer examples, proof points, talk track, caveats, verbatim evidence, and a follow-up action that logs an internal test record of the permission email. It does not claim permission and does not send email.

find_sales_proof

Find what a GROUP of customers shares: pass 2-50 customer ids and get the themes evidenced by multiple cohort members, ranked by how many of the cohort share each, with insight counts, deal-blocker counts, and the cohort's current ARR at stake per theme. Use this for churned-cohort post-mortems ("what did the accounts we lost complain about?"), at-risk triage, and segment comparison. Takes the `id` field of customer search results (not customer_scope_id), such as the accounts a customer search with churn_state="churned" returns. An id that matches no customer in this workspace is listed in cohort.unresolved_ids; when fewer than two customers resolve, the call returns an error instead, which says how many ids were not found when any were not. arr_at_stake = the current ARR (what they pay now: the customer-success figure, else won deals since the last churn; 0 for a customer that does not pay now) of the cohort customers evidencing that theme, and total_arr the same for the whole cohort; won_arr_at_stake and total_won_arr are every deal they ever won (bare annual value), which is what a churned cohort used to pay. deal_blocker_count counts distinct customers with a blocking insight within the window, at the requested customer_scope grain, matching the theme node definition over this cohort and period.

graph_cohort

Measure how important a defect is: who reported it, how badly, what it is worth, and whether it is still happening. Use this when someone asks whether a bug is worth fixing now, how many customers it affects, what revenue is exposed, or which customers to name in a triage decision. Returns an exposure score with every input published, per-customer rows that the totals decompose into exactly, verbatim evidence, a weekly trend, and a coverage block. Reflects REPORTED pain only; customers hitting the bug who have not contacted you are not represented. Read only.

get_bug_blast_radius

List your configured competitors with mention counts, switch-direction mentions (replacement/comparison/threat mentions from conversations), closed-lost deals with annualized value, and how many of your customers mention each. Use this when the user asks which competitors threaten them most. The names it lists are the competitor names the strategic intelligence search filters by; that filter matches name text, so mentions counted through a vendor alias may not appear there.

get_competitors

Get the full transcript of a specific conversation. For email, returns the full parsed email source as chronological structured messages plus extracted attachments, a compatible transcript string, ordered delivery IDs, and source_complete/warning_codes that disclose parser limits. For hubspot_email, returns the preserved HubSpot source used for analysis, with attributed body parts. Takes a conversation id and source, as a conversation list or the conversation pointer of an insight or strategic insight gives them.

get_conversation

Get full profile for a specific customer including CRM data, deals, contacts, feedback summary, and strategic insights. Takes a customer id from customer search results. Returns everything known about the customer across all data sources, including customer_family: the account family the customer is counted under, whether it pays now (is_paying) and its current ARR (arr), and each of its accounts with its current ARR, the CRM it came from (source) and its record id there (external_id).

get_customer

Get aggregated counts by dimension for the current feedback dataset. Use this to understand distributions: which categories, feature areas, emotions, or competitors appear most. Returns top values with counts for each requested dimension.

get_facets

Get a high-level summary: total insight count, unique customer count, deal blockers, churn (stated-churn insights from conversations + CRM-observed churned/at-risk account counts), and top categories. Use this when the user asks "how many customers", "how many insights", "what's going on?", or wants a general update. Returns aggregate numbers and trends. Stated churn counts both the churn_reason and general_dislike insight types. The `opportunities` counts are LIVE top-level THEMES the product currently shows: shipped and declined themes are excluded, and each team has an adaptive size floor, so very small themes are excluded too.

get_overview

Walk one hop from a node: returns connected nodes grouped by edge type. Theme connections (edge_type "related_theme") are UNDIRECTED co-occurrence: each carries relationship:"co_occurs" plus a relatedness `strength` (strong/moderate/weak); they say two themes show up together, NOT that one causes or leads to the other, and no direction or causation is returned. The grounded evidence for a causal or churn question is the theme's own insights and the CRM churn state of the customers behind them. For a LARGE theme, edge_type "has_child" lists its sub-themes (finer-grained pain inside the theme; sub-themes below the team minimum are left out); each sub-theme is a node of entity_type "feature" with its own edges. Vendor "lost_deal" edges attribute a closed-lost deal to a vendor only when the vendor was mentioned 3+ times in the 60 days before close, so an empty list means no ATTRIBUTED losses, not necessarily no losses. All other edge families (deals, contacts, evidence, mentions, churn) are deterministic facts.

graph_edges

Get one knowledge-graph node: its properties plus a summary of the edges touching it (counts per edge type). Node ids are the same ids the other ClosedLoop AI tools return; a node carries a summary, not the full detail of a customer, theme, insight, strategic insight or conversation.

graph_node

Time-ordered events for a node. customer → churn/risk state transitions + closed deals; theme → weekly insight volume + lifecycle events (currently merges and dissolves, with counterpart themes named, e.g. which theme this one merged into); deal → close outcome; vendor → monthly mention volume (with threat-mention split) + closed-lost deals attributed to the vendor. The theme/feature weekly-volume and vendor monthly-mention series are FEEDBACK-derived, so the response carries feedback_since (the team's earliest insight date): buckets before it are absent because of feedback coverage, not inactivity, so the first non-empty bucket is not necessarily when the theme or vendor began (a note flags this when window_days reaches before coverage). customer/deal timelines are CRM-sourced real dates, so they carry no feedback_since. Other entity types have no tracked timeline yet and return an empty list with a note.

graph_timeline

Get time-bucketed insight counts for trend analysis. Use this to see how feedback volume changes over time for a topic, category, or the whole dataset. Returns weekly or daily counts. Use to detect spikes, declines, or seasonal patterns. The response carries feedback_since (the team's earliest insight date); periods before it are empty because feedback coverage had not started, not because activity was zero, so the first non-empty period is not necessarily the start of a trend (a note flags this when date_from predates coverage).

get_trends

Get full details for a specific product opportunity including all evidence, affected customers with whether each pays now (is_paying), its current ARR (arr, summed as total_arr) and every deal it ever won (won_deal_value, total_won_deal_value), and business impact assessment. Takes an opportunity id from opportunity search results. Returns top 50 customer quotes as evidence.

get_opportunity

Get full details for a specific product feedback item including verbatim content, pain point analysis, workarounds, and business impact assessment. Takes an insight id from insight search results. Returns a conversation pointer ({ id, source }) to the call, ticket, or other source the insight came from, or null when no openable source is stored; together the two values identify the full conversation transcript. Email insights also return every exact supporting evidence span in ordered evidence sequence.

get_insight

Get full details for a specific strategic intelligence item including verbatim content, context, and source information. Takes an item id from strategic intelligence search results. Returns a conversation pointer ({ id, source }) to the call, ticket, or other source the item came from, or null when no openable source is stored; together the two values identify the full conversation transcript. Email items also return every exact supporting span in ordered evidence sequence.

get_signal

Read one internal proof permission request by id. Returns the draft email body of the internal test record, test_status, selected customer/account, evidence snapshot, and approval state. It does not send email.

get_proof_permission_request

Return the catalog of predicates, operators, combinators, triggers, and actions for building a notification watch: a rule that alerts the user (Slack, Teams, email or a webhook) when something happens in their ClosedLoop AI data. Use this when a user wants to be notified or alerted about something. A watch rule IR is valid only when every key in it comes from this catalog.

get_watch_catalog

List all conversations (calls, support tickets, and canonical email threads) for a customer. Returns conversation metadata (title, date, source, participants, duration) without the actual transcript. With customer_id (a customer id from customer search results) it finds every conversation linked to the customer through feedback data; without one, it matches customer_name.

list_conversations

Log an internal test record of a proof permission email. This creates a proof permission request row and stores the draft email body, but never sends anything to a customer and never writes to the real sent-email log. Takes a candidate selected from a proof workflow's follow_up_actions entry.

create_proof_permission_request

Measure the EXACT magnitude of a problem. You supply a reproducible PREDICATE; this returns deterministic counts, so one concept gives one number. `source` picks the data layer: "signals" = strategic intelligence from conversations (churn/pricing/competitive themes; default), "insights" = product feedback (bugs / feature requests / UX; where most PRODUCT-problem evidence lives), or "both". Returns: customers_all (distinct accounts matching), customers_active (of those, currently paying, as every screen decides it), arr_at_risk_active (Σ the current ARR of the paying customers, the canonical "$ at risk" rule; not GMV), signal_count (matching strategic-intelligence rows), insight_count (matching feedback rows), and churn_overrepresentation (how much more common the predicate is among CHURNED accounts vs the active base, WITH its coverage denominator and an abstain flag when it rests on too few churned accounts to be reliable). It turns "X is a big problem" into "X affects N active customers / €M at risk". An empty predicate (no constraint applying to the chosen source) is rejected.

measure_cohort

Look up a specific customer by name, or browse/filter customers by industry, segment, deal status, or engagement. Returns CRM profiles with deal pipeline and feedback stats, whether each customer pays now (is_paying) and its current ARR (arr); won_deal_value is every deal it ever won, not what it pays now. Use this when the user asks about a SPECIFIC customer. Returns customer profiles, not aggregate totals of all customers and not individual product feedback.

search_customers

Find nodes in the knowledge graph by entity type. Covers every entity: "customer", "person", "deal", "pipeline_stage", "segment", "theme", "feature", "pm_feature", "initiative", "insight", "signal", "data_source", "vendor", "transcript". It matches names and titles (partial, case-insensitive) and does no semantic or topic search. Node ids are the same ids the other ClosedLoop AI tools return, and each node's properties, connections and history are read by its id.

graph_search

Find the biggest clustered product problems ranked by business impact. Use this when the user asks what to build next, what the top customer pain points are, or where the biggest product gaps exist. Each opportunity groups many individual insights into a single theme. Does not return individual feedback quotes. Large themes decompose into sub-themes: in the knowledge graph, each sub-theme is a "has_child" edge of its theme, carrying the finer-grained pain inside it. By default results are limited to the themes the product currently shows: each team has an adaptive size floor, so very small themes are excluded even when min_signals is low. A theme is sized through its LIVE features, so the floor cannot be evaluated for a finished one: shipped and declined themes are returned unfiltered by size. Under status 'all' that exemption covers only those terminal rows; live themes stay gated.

search_opportunities

Find specific product feedback about a topic, or browse feedback with filters. Uses hybrid search (full-text + semantic) to find results even when the exact words differ. Returns individual insights as 300-char content previews, with a customers_mentioned summary. It does not return clustered problem areas or strategic insights such as satisfaction or churn trends. With a query, semantic_matching_available: false means the semantic leg could not run (its query embedding gets at most 2 seconds) and the results are keyword matches only, so a missing match is not evidence that no customer raised it. With a query, keyword matches need every word of the query first; when that finds fewer than 20, they add insights with the query's rarest word together with any other word, then the rarest word alone, the next rarest word when one matches nothing, and finally any word, each step reading at most the 1,000 newest matches. Keyword and semantic matches form one ranked list of at most 300 insights that offset and sort page through, and total_matches is the size of that list, not a count of every insight that mentions the topic; pages only follow on from each other while semantic_matching_available stays the same between calls.

search_insights

Get strategic intelligence about market dynamics, customer satisfaction, and business risks. Uses hybrid search (full-text + semantic). Returns 300-char content previews. It does not return individual product feedback. With a query, keyword and semantic matches form one ranked list of at most 300 items that offset and sort page through, and total_matches is the size of that list; semantic_matching_available: false means the semantic leg could not run (its query embedding gets at most 2 seconds), so the results are keyword matches only and a missing match is not evidence that no customer said it, and pages only follow on from each other while that flag stays the same between calls.

search_signals

Send feedback about the ClosedLoop AI platform to the ClosedLoop AI team: a bug, a feature request, or praise about ClosedLoop AI itself. Use this when the user wants to tell the ClosedLoop AI team something about the product they are using. This is NOT for logging other people's feedback. `content` is the feedback in English (a faithful translation when the user wrote in another language, not a summary); it is stored as sent. Returns a confirmation that it was received.

send_closedloop_feedback

Update the test status of one internal proof permission request: marks the internal test record pending, approved, or denied, for testing only. It never sends email and never contacts the customer.

update_proof_permission_status

Validate a compiled notification-watch rule IR against the watch catalog (predicate keys valid for the subject, operator/type compatibility, enum values, required temporal windows, action config). Returns { valid, errors }. Validation only: it does not store the watch or dry-run it against history.

validate_watch

Re-ground the SPECIFIC accounts named in a finding against the raw records. Takes a predicate (the same shape as the cohort measurement predicate, including `source`) and a list of account name fragments; each is checked against the raw records: does the account exist, is it currently paying (is_active, as every screen decides it; null = synced since the last refresh, no answer yet, not "not paying"), what is its current ARR (arr) and its largest won-deal annualized value (won_arr), and does it actually have a matching record under THIS predicate (in the chosen layer)? Verdicts: "verified" (exists, EXACT name, has matching evidence), "verified_fuzzy_name" (matched only by a substring; could be a DIFFERENT account, e.g. "Acme Co" → "Acme Coaching Inc", so the entity is unconfirmed), "dropped" (not_found, or no_matching_evidence). Also returns name_match (exact/fuzzy), candidates (how many accounts the fragment matched; >1 = ambiguous), is_active, arr, won_arr, and a sample quote. Use this when a finding names accounts: it shows which of them are mis-attributed or churned.

verify_claims