AgentSource

View saved version →

---
name: account-contacts
description: "Find and rank the right people at one target company: a contact shortlist for outbound, or a buying-committee map showing economic buyers, technical evaluators, influencers and coverage gaps. Use for 'get the HR leadership at miro.com', 'who are the decision-makers at Acme', 'map the buying committee at Globex', 'contacts at Stripe for a security pitch', 'who owns this at the account'. Not for finding people across many companies (use list-builder) or for looking up a named person (use enrich-contact)."
---

# Account Contacts

Pull the right people at one company, check how reachable they are, and say who to engage first.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

- **Company** (required): a domain (preferred) or a name.
- **Use case:** prospecting (default), deal acceleration, or renewal and expansion. For a buying-committee request, add the purpose: deal stage, who is already engaged, who is missing, and any hypothesis ("find the economic buyer").
- **Focus (optional):** a function (HR, security, finance, RevOps) or seniority (C-level, VP and above, Director and above), and how many people (default 25, up to 100).

If only a bare company is given, ask once what the contacts are for; if the user declines, build a general prospecting shortlist and say so.

## Workflow

1. **Match the company** with `match-business`. A big brand that resolves to 1-50 employees under "Corporate Managing Offices" probably hit a shell entity, so retry with the other domain. If several companies match, show the top 2-3 (industry, size, HQ) and ask.
2. **Turn the use case into a persona blueprint** before fetching:
   - *Prospecting:* broad coverage of the functions that would buy, weighted to Director, VP and C-level.
   - *Deal acceleration:* the economic buyer, a technical evaluator, procurement, and one Director-level champion candidate.
   - *Renewal or expansion:* current product-owner functions plus an executive sponsor, including Manager and Director levels.
   Apply any function or seniority the user named, and say which roles that dropped.
3. **Contact preference.** If the user did not say what contact data they want, ask using the options in the live `fetch-entities` description and set `has_contact_details` from the answer.
4. **Resolve titles.** `autocomplete` for `job_title`. A specific title uses `job_title` (add `job_level` for executives); a broad function uses `job_level` plus `job_department` only. Title filters are loose, so seniority keeps them tight. For "the CFO at Asana", do not try to match a title as a name: filter the company's prospects by title and level.
5. **Fetch** with `fetch-entities` for prospects, scoping to the company with `business_id` and the persona filters, at the requested count. Make one call that covers the whole blueprint. For adjacent functions the user named (procurement, legal, finance), add a second call so coverage gaps are visible.
6. **Enrich** the fetched people with `enrich-prospects`: `profiles` for tenure and prior roles, and `contacts` if the user wants contact data (`parameters.contact_types` to match their channel).
7. **Account signals (committee requests):** `fetch-businesses-events` for the last 90 days, because funding, new offices and hiring change who matters. A new joiner is a signal only; there is no executive-move event type. Check that an event names the company before using it.
8. **Rank** the returned people against the persona blueprint. All rows are visible, so rank the whole list.

## Reply

- **Target account:** one line with company, domain, industry, size bucket, revenue bucket, HQ, public or private.
- **Use-case frame:** what the shortlist optimizes for, and any overrides.
- **The people:** a table with, for each, name, title, seniority, department ("Unattributed" if empty), reachability, and one clause on the role they fill ("VP-level economic buyer in Sales"). Lead with the top ten when the list is longer.
- **Committee map (committee requests):** group by Economic Buyers, Technical Evaluators, Influencers (procurement, legal, operations, adjacent teams) and Potential Champions. Label a Champion only when the user supplied evidence of engagement; title alone is not enough. Mark each user hypothesis confirmed, contradicted or unresolved.
- **Coverage and risk:** gaps where the use case expected a role and nobody turned up, single-thread risk, and who to contact first with a reason each.
- **Next steps:** more people, deeper context with `account-research`, or career-change signals through `fetch-prospects-events` before a first touch.

## Limitations

- No contact data-quality sort; reachability is judged from the contact filter and enriched fields.
- No sub-department function filter; the finest cut is department plus title.
- Company type is only public or private; a subsidiary cannot be told apart from an independent private company.
- Department is empty for many senior cross-functional roles (Chief X Officer, President, Founder): "Unattributed".
- No CRM or engagement data, so champions depend on what the user tells you.
- Executives at well-known companies often have suppressed contact data; suggest LinkedIn.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: account-research
description: "Build a purpose-driven intelligence brief on one target company: firmographics, funding, hiring and workforce trends, tech stack, recent business events, and peers. Use for pre-call research, renewal or QBR prep, competitive evaluation, and outbound targeting, for example 'research stripe.com for outbound to finance leaders', 'account brief on Snowflake', 'profile this company before my call'. Not for a quick lookup of one data point (use enrich-company), a comparison of several rivals (use competitor-research), or a meeting agenda with attendee profiles (use meeting-prep)."
---

# Account Research

A brief on one company, framed around why the user needs it.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

- **Company** (required): a name or domain.
- **Purpose** (strongly recommended): one sentence on why the brief is needed and what decision it supports (renewal risk, competitive evaluation against Acme, outbound to finance leaders). If it is missing, ask once; if the user declines, produce general account intelligence and say so.

## Workflow

1. **Anchor on purpose.** Restate it in one sentence and pick 2-4 themes (for renewal risk: workforce changes, executive moves, competing vendors, expansion signals). Themes decide which enrichments to add and how to filter peers.
2. **Match the company** with `match-business` using name and domain. A major brand that resolves to 1-50 employees in "Corporate Managing Offices" is likely a shell entity; retry with the other domain or the plain name. If there is no confident match, ask the user.
3. **Enrich in tiers** with one `enrich-business` call listing the chosen types in `enrichments`:
   - *Always:* `firmographics`, `company-hierarchies`, `funding-and-acquisitions`, `workforce-trends`, `linkedin-posts`.
   - *By purpose:* competitive evaluation adds technographics, webstack and competitive-landscape; renewal or QBR adds company-ratings, challenges and strategic-insights; outbound adds website-changes and website-keywords (keywords tied to the user's offering); investor or M&A adds financial-metrics (optional `date`); buying-intent questions add bombora-intent.
   - *Skip* the rest unless the purpose calls for them. Any enrichment that is skipped or empty gets a one-line note in its section so the reader can tell "not investigated" from "no data".
4. **Fetch business events** with `fetch-businesses-events` for the last 90 days. Useful types: `new_funding_round`, `new_product`, `new_partnership`, `new_office`, `closing_office`, `cost_cutting`, `merger_and_acquisitions`, `outages_and_security_breaches`, and the `hiring_in_*`, `increase_in_*` and `decrease_in_*` department types. Use `employee_joined_company` as a rough signal for leadership hires. Before quoting an event, confirm it actually names the target: industry-wide stories can be attributed to several companies.
5. **Peer set (directional, up to 5).** Derive a sub-category from the purpose, not from a broad industry label: for "vs Databricks", the data-platform sub-vertical; for outbound to finance leaders, the target's go-to-market sub-vertical. Run `fetch-entities` for businesses with those filters and include any competitor the user named, labeled "named by user". If fewer than 3 solid peers come back, skip the section and say so.
6. **Reconcile, then write.** If an event shows a newer funding round than the funding enrichment, trust the event and flag the lag. For public companies, add a one-line financial posture marked "verify". Mark past-dated milestones "verify". Cross-check signals (a new CTO plus a webstack change plus engineering hiring is a timing signal). Write the summary last.

## Reply

- **TL;DR:** the purpose, a 2-4 sentence "why now", the 3 most consequential facts, and 1-3 specific actions.
- **Snapshot:** domain, industry, headcount and revenue buckets, HQ, public or private, founded.
- **Sections:** funding and capital, workforce and hiring, tech stack and website activity, challenges and strategy, recent events (dated, grouped when there are four or more), peers. Skip sections with no data and say why.
- **Next steps:** actions tied to a named signal or person. Offer `account-contacts` for the people to contact and `meeting-prep` if a call is scheduled.

## Limitations

- Challenges, strategy and competitive landscape come from public filings: empty for private companies and 12-18 months old for public ones.
- No similar-companies model; peers are approximated from filters and are directional only.
- No executive-move event type. Leadership changes must be inferred from `employee_joined_company`, hiring events and posts, and flagged as inferred.
- Headcount and revenue are buckets.
- Matching returns no confidence score.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: clean-data
description: "Tidy a pasted list of companies or contacts before matching or enrichment: normalize company names, domains, countries and emails, flag invalid rows with a reason, match each row to AgentSource records, and remove duplicates that resolve to the same company or person. Use for 'clean this list', 'match these companies to domains', 'dedupe these contacts', 'which of these emails are valid', 'prep this list for enrichment'. Works on lists pasted in chat, up to roughly 100 rows. Not for building a new list (use list-builder)."
---

# Clean Data

Standardize and check a pasted list, then match it so duplicates collapse onto real company or person records. Nothing is deleted: every row stays, with a status and reason.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

A list of companies or contacts pasted in chat, or the text of an attached file. Roughly 100 rows is the practical limit in one conversation; for more, work in batches. Note which column is the company name, domain, email, LinkedIn URL, phone or country; ask only if it is unclear. For a very large file, suggest the user clean it in a spreadsheet first.

## Workflow

1. **Profile the input.** Report row count, fill rate for each field, and obvious problems: placeholder text ("N/A", "none", "-"), pasted addresses in the name field, many spellings of one country, free-email providers, and role addresses.
2. **Standardize,** keeping the raw value beside the normalized one:
   - *Company name:* trim, collapse spaces, remove stray punctuation, and drop a trailing legal suffix (Inc, LLC, Ltd, GmbH, S.A.) for matching only.
   - *Domain:* strip the protocol and `www`, keep the registrable domain, lowercase. Flag free-email domains separately.
   - *Country:* convert to ISO two-letter codes (`United States` → `US`, `UK` → `GB`, `Deutschland` → `DE`).
   - *Email:* trim and lowercase.
   - *LinkedIn:* keep the full profile URL.
3. **Validate** each field and tag the row; never delete one:
   - *Email:* syntax, role addresses (`info@`, `sales@`, `noreply@`, `support@`), well-known free or disposable providers. You cannot check deliverability or mail servers, so say that valid means well-formed.
   - *Domain:* looks like a real domain, no IP address or spaces.
   - *Country:* resolves to a code.
   Give each problem a short reason code (`role_address`, `free_provider`, `invalid_syntax`, `placeholder`).
4. **Match the valid rows.**
   - Companies with a name and/or domain: `match-business`, up to 50 per call.
   - People: `match-prospects`, up to 40 per call, by email, LinkedIn URL or phone number, or full name plus company name (add the company's `business_id` when you have it). Skip rows tagged as role addresses or disposable domains so you do not spend matching on them.
   Match results are complete, so read them directly. Check a resolved company for the shell-entity pattern (a big brand with 1-50 employees under "Corporate Managing Offices") and retry with the other domain. An email miss stays a miss; never retry it as a name search.
5. **Deduplicate on the IDs.** Rows that resolve to the same business ID or prospect ID are duplicates; keep the first, mark the others with the ID of the survivor. Different IDs are different entities even if the names look alike, and subsidiaries or brands under one parent (for example a parent and its product domains) are separate companies; `enrich-business` with `company-hierarchies` shows the tree.
6. **Report** and offer next steps.

## Reply

- **Profile:** a short before-and-after summary of fill rates and the issues found.
- **Standardization:** three to five example changes (`"  ACME, Inc. "` → `acme`, `"WWW.Acme.COM"` → `acme.com`).
- **Validation:** counts of valid and invalid rows and a frequency list of reason codes.
- **Result table:** the input row, normalized value, status (matched, unmatched, invalid, duplicate of row N), reason, and the matched name and domain. Show the first rows in chat and offer the rest in batches.
- **Next steps:** enrich the matched rows with `enrich-company` or `enrich-contact`, or score them with `score-leads`. If the match rate is low, suggest adding LinkedIn URLs, company domains or work emails.

## Limitations

- Validation checks format only: no deliverability or mail-server check, and no phone verification.
- Person-name parsing is simple; non-Western name orders and compound surnames may need the user's confirmation.
- Free-email addresses cannot be tied to a company by themselves; pair them with a name and company for a prospect match.
- Matching returns an ID or nothing, with no confidence score.
- Works in chat, so very large files need to be split.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: competitor-research
description: "Compare two to four rival companies side by side: size, funding, hiring trends, tech stack, recent strategic moves, and overlap with the user's target customers, with a short battlecard per competitor. Use for 'compare Gong and Chorus', 'size up our competitors', 'competitive landscape for X', 'battlecard for renewal'. Not for a deep brief on one company (use account-research) or for finding lookalike companies (use lookalike-accounts)."
---

# Competitor Research

A dated, fact-led comparison of a few named rivals.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

- **Competitors** (required): 2-4 names or domains. Beyond four, the side-by-side stops being readable; offer a second pass.
- **Purpose** (ask once if missing): battlecard, board update, win-loss prep, renewal.
- Optional: priority angles (pricing pressure, AI roadmap, a region), the user's target customers (to judge overlap), and hypotheses to confirm or contradict.

## Workflow

1. **Anchor.** Restate the purpose, angles and hypotheses in 1-2 sentences.
2. **Match all competitors** in one `match-business` call, with name and domain where available. Check each for the shell-entity pattern (a big brand showing 1-50 employees under "Corporate Managing Offices") and retry with the alternate domain. Drop and flag any that do not resolve confidently; do not proceed with the wrong company.
3. **Enrich** all matched competitors in one `enrich-business` call, listing the types in `enrichments`: firmographics, funding-and-acquisitions, workforce-trends, technographics, competitive-landscape, strategic-insights, challenges, company-ratings, linkedin-posts. Prioritize by the user's angles, and say which were skipped.
4. **Fetch events** with `fetch-businesses-events` for the last 90 days. Keep launches (`new_product`), funding (`new_funding_round`), `merger_and_acquisitions`, `new_office` and `closing_office`, `cost_cutting`, partnerships, and notable department hiring or cuts. Before using an event, check that it names the competitor.
5. **Judge overlap** per competitor (High, Partial, None) against the user's stated target customers, using firmographics. If none were given, write "Not assessed".
6. **Check each hypothesis** as confirmed, contradicted or unresolved, citing the data point behind the call.

## Reply

- **Purpose and hypothesis check** in two or three lines.
- **Side-by-side table:** company, domain, HQ, headcount bucket, revenue bucket, founded, public or private, latest funding, latest dated move.
- **Per competitor:** snapshot, recent moves (dated), positioning in the company's own terms from strategic-insights or competitive-landscape, workforce direction, challenges, overlap, and three discovery questions rooted in specific facts.
- **Data quality:** unresolved names, empty enrichments, stale records, contradictions.
- Offer `account-contacts` to map the buying committee at a specific account.

## Limitations

- Challenges, strategy and competitive landscape come from public filings: empty for private rivals and 12-18 months old for public ones. For private companies lean on funding, events, workforce trends, tech stack and posts.
- Headcount and revenue are buckets; compare buckets, not numbers.
- Review-site sentiment (G2, TrustRadius) and earnings-call content are not in the data.
- No similar-companies model. For rivals beyond the named ones, use `lookalike-accounts` or the competitive-landscape results, and label them as approximations.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: enrich-company
description: "Look up one company, or a pasted list of up to 50 names or domains, and add firmographics, tech stack, funding and acquisitions, workforce and hiring trends, ratings, company hierarchy, website changes, or LinkedIn posts. Use for 'enrich this company', 'what does acme.com use', 'how big is Stripe', 'funding history for Asana', 'add industry and headcount to this list of domains'. Not for finding new companies (use list-builder) or a full multi-section brief (use account-research)."
---

# Enrich Company

Resolve named companies to AgentSource records, then add the data the user asked for.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

One or more company names or domains, typed or pasted (up to 50 per match call). A name plus a domain matches best. Optional: which kinds of data the user wants.

## Workflow

1. **Match.** Call `match-business` with each company's `name` and/or `domain`. The result is complete, so read it directly.
2. **Check the match.** A well-known brand that resolves to 1-50 employees in a "Corporate Managing Offices" category probably landed on a registered-agent shell. Retry with the alternate domain or the plain company name. The match has no confidence score, so when the candidates look ambiguous, ask the user instead of guessing. Report unmatched rows and do not substitute other companies.
3. **Choose enrichments** from what the user asked for. With no preference, use firmographics plus technographics.

   | Need | Enrichment |
   |---|---|
   | Name, description, size, revenue, location, industry | `firmographics` |
   | Tech stack | `technographics` |
   | Web infrastructure | `webstack` |
   | Rounds, investors, IPO, acquisitions | `funding-and-acquisitions` |
   | Headcount and department trends | `workforce-trends` |
   | Employee-satisfaction ratings | `company-ratings` |
   | Parent, subsidiaries, org tree | `company-hierarchies` |
   | Public-company financials | `financial-metrics` (optional `parameters.date`) |
   | Keywords on their website | `website-keywords` (needs `parameters.keywords`) |
   | Site content changes | `website-changes` |
   | Recent company posts | `linkedin-posts` |
   | Buying-intent topics | `bombora-intent` (topics from `autocomplete` with `business_intent_topics`) |
   | Risks, competitors, strategy (from filings) | `challenges`, `competitive-landscape`, `strategic-insights` |

   Pass the chosen types together in the `enrichments` list of one `enrich-business` call, with up to 50 `business_ids`. Use the schema's exact enum names.
4. **Present** the returned values. For a list longer than five companies, show a table of the requested fields instead of cards.

## Reply

One short card per company (up to 5): name, domain, industry, headcount bucket, revenue bucket, HQ, public or private, then the enrichments requested. Leave out empty fields and name any enrichment that came back empty, so the user can tell missing data from data that was never requested.

## Limitations

- Risks, competitors and strategy come from public filings: empty for private companies and 12-18 months old for public ones. Use funding, workforce trends, events and posts for current signals.
- Headcount and revenue are buckets. Quote the bucket, not an exact number.
- Matching returns an ID or nothing, with no confidence score.
- Every enrichment type uses credits per company, so request only the types the user needs.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: enrich-contact
description: "Look up one person or a small pasted list of people and return their professional profile and contact details: work email, phone, LinkedIn, title, seniority, department, work history, and recent job changes. Identify people by email, LinkedIn URL, phone number, or full name plus company. Use for 'find the email for Jane Smith at Acme', 'enrich this contact', 'who is this person', 'background on these attendees'. Not for finding new people by role (use list-builder or account-contacts) or for drafting outreach."
---

# Enrich Contact

Resolve people to AgentSource records, then add the profile and contact data the user asked for.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

For each person, one of: an email, a LinkedIn URL, a phone number, or a full name with a company name or domain. A name without a company cannot be matched. Up to 40 people per `match-prospects` call. Optional: whether the user wants contact details, a profile, or career changes.

## Workflow

1. **Pick the strongest identifier** for each person: email, then LinkedIn URL, then phone, then name plus company. Do not fan out several strategies for one person. If the user gave a role instead of a name ("the CFO at Asana"), do not match on the title; use `match-business` to get the company, then `fetch-entities` for prospects filtered by title and seniority, and let the user choose.
2. **Match.** Call `match-prospects`. For a name plus company, add the company's `business_id` from `match-business` when you have it. Results are complete: a person is either matched or null. A typo in an email is a miss; do not retry it as a name search, since that could return a different person.
3. **Report misses.** Say which people did not match and why a retry might help: an email, LinkedIn URL or company domain improves the odds. Enrich only the matched people. Do not replace an unmatched person with someone similar.
4. **Enrich** the matched people with `enrich-prospects`, naming the types in `enrichments`:
   - `profiles` for title, location, work history and education.
   - `contacts` for email and phone. Set `parameters.contact_types` to `["email"]` unless the user needs phone numbers too; leaving it empty requests both.
   - `linkedin-posts` for the person's recent posts, if asked.
   Company context, if asked for, comes from `enrich-business` with `firmographics` on the employer's `business_id`.
5. **Career changes,** if asked: `fetch-prospects-events` with `prospect_changed_role` or `prospect_changed_company` and a `timestamp_from`. These are the only people-level event types.
6. **Present** the returned values. For more than five people, use a table instead of cards.

## Reply

A card per person (a table for more than five): name, title, company, seniority, department ("Unattributed" if empty), professional email, phone, LinkedIn. When the user asked for background, add a 3-5 sentence synopsis written only from the returned data: current role, one or two earlier roles, tenure, and any recent change. Say "not available" for thin profiles instead of guessing.

## Limitations

- High-profile executives often have suppressed contact data. Suggest LinkedIn instead of cold email.
- No per-contact accuracy score and no "last updated" date. Treat a professional email plus a phone as the practical quality signal.
- Seniority and department are coarse; department is empty for many Chief X Officer, President and Founder roles.
- Do not use contact data for anything beyond the lookup the user asked for.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: list-builder
description: "Build a targeted list of companies or people from a plain-language description of the audience: job titles, seniority, department, industry, company size, location, tech stack, buying-intent topics, or recent company events such as funding or a new office. Use for requests like 'find 50 CISOs in Texas', 'companies using Snowflake in the UK', 'build a target account list', 'companies that opened a new office in California', or 'heads of demand gen at fintechs'. Not for a single named company or person (use enrich-company or enrich-contact), for counting a market without pulling rows (use market-sizing), or for sending outreach."
---

# List Builder

Turn a plain-language audience description into a list of companies or people. Results come back in full, one page at a time.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Parse the request

Pull these out of the user's message:

- **Entity type:** `prospects` if any person attribute is named (title, seniority, department, skills); `businesses` only when the request is about companies with no people.
- **Roles:** titles, seniority, department.
- **Company traits:** industry, size, revenue, company age, public or private.
- **Geography:** country, state or region, US city. Note whether it describes the person or the company.
- **Signals:** tech stack, buying-intent topics, recent events (funding, new office, hiring, M&A) with a 30-90 day window.
- **Count:** use the exact number requested; default 30. Set `page_size` to the count, up to 500; for more, page with `next_cursor`. Confirm before pulling more than 100 rows, because each row uses credits.
- **Extras:** contact details (emails, phones), people per company.

Examples: "100 VP Engineering at Series B SaaS in the US that use Snowflake", "50 CISOs based in TX with 5+ years of experience", "500 companies that opened a new office in CA in the last 90 days", "50 CFOs at public manufacturers that raised funding in the last 90 days".

## Workflow

1. **Ask what is missing, once.** Skip any question the user already answered.
   - *Location (prospects only):* if "in <place>" could mean where the person lives or where the company is headquartered, ask which, or both. Clear wording such as "companies in Germany" or "prospects based in New York" needs no question.
   - *Contact details (prospects only):* unless the user already said what contact data they want, ask using the options in the live `fetch-entities` description, then set `has_contact_details` to match. It filters availability only; it does not return the values.
2. **Resolve values.** Run `autocomplete` for every controlled-vocabulary filter you will use. Use ISO codes directly for countries (`US`) and regions (`US-CA`), and the schema enums for company size, revenue, age, job level and job department.
3. **Build the filters.**
   - **Roles:** broad seniority or department asks ("engineering VPs") use `job_level` plus `job_department` only. A specific title uses `job_title` (from autocomplete); for executive titles add `job_level`. Title filters are loose, so seniority keeps them tight.
   - **One industry taxonomy:** `linkedin_category` or `naics_category`, never both. Start with LinkedIn. Switch to NAICS only if the best LinkedIn match is a parent industry that would pull in many unrelated companies.
   - **One location level per side:** `company_country_code` or `company_region_country_code`; `prospect_country_code` or `prospect_region_country_code`.
   - **Experience:** "5+ years of experience" means `total_experience_months` with `gte: 60`; time in the current role uses `current_role_months`.
   - **Buying intent:** "who needs", "is looking for", "interested in" a product means `business_intent_topics`, with values from autocomplete.
   - **Events:** `events` works for businesses only, with `values` (for example `new_office` for "opened a new office", `new_funding_round`, `new_product`, `merger_and_acquisitions`) and `last_occurrence` of 30-90 days. It selects companies that had the event; it does not add event columns. A completed office-opening event does not establish future office demand. For office-seeking intent, resolve an appropriate intent topic or explain that the requested intent cannot be expressed; do not substitute the event silently.
   - **Ambiguous words** ("designers", "security", "consulting"): offer specific sub-categories and an "all relevant" option, and do not silently pick the broadest.
4. **Fetch once.** Combine everything into a single `fetch-entities` call. Set `max_per_company` only if the user gave a number. Do not call `match-business` or `match-prospects` afterwards, because the IDs are already in the result.
5. **Enrich only on request,** passing the returned IDs (up to 50 per call). Contact enrichment (`enrich-prospects` with `contacts`) follows the user's contact answer: set `parameters.contact_types` to match the channel they chose. For company details on prospect results, use `enrich-business` with their `business_id` values.
6. **Event details:** if the fetch used `events` and the user did not already ask for event details, ask before running `fetch-businesses-events` or `fetch-prospects-events`.
7. **Present** the rows in the format below.

## Reply

- **Results Found:** `[key qualifier] [entity type]`, with the rows returned and `total_results` if the response gives it.
- **Results table:** the rows, with the columns that matter for the request.
- **Criteria applied:** a short bullet list of the filters that landed. Say plainly if a request was approximated or could not be expressed.
- **Next steps:** if `total_results` exceeds the rows returned, offer the next page and say it uses credits; never page without a yes. Add one or two concrete refinements: tighten or widen a bucket, switch location level, add a recent-event filter, pull the people at these companies, add an enrichment.

## Limitations

- Company size and revenue are buckets, not exact figures, and results cannot be sorted by them.
- No metro-area filter: use a US `city_region` or a state or country code.
- No sub-department job-function filter: use the department plus a title.
- No Inc 5000 or Fortune ranking filter; approximate with size, revenue and the public-company flag.
- Contact data arrives only through enrichment. `has_contact_details` filters availability.
- Results cannot be sorted; `fetch-entities` returns matches in its own order.
- Department is empty for many cross-functional senior roles (Chief X Officer, President, Founder); group them as "Unattributed".

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: lookalike-accounts
description: "Find companies that resemble a seed company by rebuilding its industry, size, region and tech-stack profile and searching for others that share it. Use for 'find companies like Stripe', 'lookalike accounts for Acme', 'similar companies to our best customer', 'expand my territory', 'extend this account list'. Not for similar people (use list-builder) or for comparing named rivals (use competitor-research). Results are an approximation, not a similarity score."
---

# Lookalike Accounts

Rebuild the profile of one seed company, then search for companies that share it.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

- **Seed company** (required): a name or domain. If the user gives a person, or asks for similar contacts, use list-builder instead; this skill returns companies.
- **Count:** default 25, up to 100.
- **Overrides (optional):** country or region focus, size or revenue bucket, public-only, and extra tech-stack requirements.

## Workflow

1. **Match the seed** with `match-business`, using name and domain. If several candidates return, pick the one whose domain matches and say which you chose. If none resolves, ask for a domain.
2. **Check the seed.** A big brand that resolves to 1-50 employees under "Corporate Managing Offices" is a shell entity. Retry with the other domain, since a wrong seed produces unrelated results.
3. **Read the seed's profile** with `enrich-business` and `firmographics` plus `technographics`. Take: industry (LinkedIn or NAICS, whichever is populated), headcount and revenue bucket, country (or the region the user asked for), and the top 3-5 technologies, favoring category-defining tools (CRM, marketing automation, data warehouse, cloud) over ubiquitous ones. Skip anything that comes back empty and do not guess.
4. **Resolve values** with `autocomplete` for the industry and each technology. For flagship vendors, try the product-qualified name first ("Snowflake Data Cloud", "Stripe Payments"), because the bare name often returns noise. Drop anything that does not resolve cleanly, and tell the user.
5. **Apply overrides,** replacing or extending the profile. Keep one industry taxonomy and one location level.
6. **Size the pool** with `fetch-entities-statistics` (`entity_type: businesses`, same filters). If it is smaller than the count asked for, relax the most restrictive filter first (the last technology, then the others, then widen the headcount bucket to an adjacent one) and re-check. If it is far larger than needed, add a technology back or narrow the region. For a country-scoped pool, read the per-location breakdown, because the headline count may include other countries.
7. **Fetch** with `fetch-entities` for businesses with the final filters, plus `business_id` set to the seed's ID from the match with `negate: true`, because a company matches its own profile. Set `page_size` to the count.

## Reply

- **Header:** "Lookalikes for [seed] ([domain])" and the profile used: industry, headcount bucket, revenue bucket, country or region, technologies. State the size of the pool.
- **Pattern notes (2-4 bullets):** dominant geography, size concentration, how dense the tech overlap is (tech data is not populated on every company), and any widening you had to apply ("industry widened because the seed had no LinkedIn category").
- **Results table:** name, domain, industry, headcount and revenue buckets, country.
- **Next steps:** offer the next page, `list-builder` for the people at these accounts, or `enrich-company` to go deeper on one.

## Limitations

- There is no similarity model or score. Results are companies that match the rebuilt filters, in fetch order, not ranked by closeness.
- Technology data is incomplete, so stacking several technologies can shrink the pool faster than expected.
- If neither industry taxonomy is populated on the seed, the match falls back to size, region and technology, which is looser. Say so.
- Headcount and revenue are buckets; a seed near a bucket edge can look further from a neighbor than it is.
- No metro-area filter.
- Returns companies only, not similar people.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: market-sizing
description: "Size a market: count how many companies match an ideal customer profile, refine the filters with the user until the number makes sense, and return the final filter set. Use for 'how many companies match', 'size the market for X', 'TAM for fintech in the UK', 'is my ICP too broad', 'territory sizing', or a rough SAM estimate. Counts and breakdowns only, with no list of companies unless asked. Not for building the list itself (use list-builder)."
---

# Market Sizing

Refine a company-level ICP and report how many companies match, using statistics instead of pulling rows.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

- **ICP** in plain language, or "my ICP" with details to ask for.
- **Use case (optional):** territory design, investor sizing, or ICP sharpening (default).
- **SAM inputs (optional):** an addressable fraction (0-1) and average revenue per account in USD.

## Workflow

1. **Parse the ICP** into filter dimensions and note which the user stated. Persona details ("CTOs", "VP Sales") are recorded but do not change a company count.
2. **Disambiguate regions first.** "EU" can mean EU member states or all of Europe; "Americas" can mean North America or the US and Canada. Ask one question, then count.
3. **Resolve free-text values** with `autocomplete`, then sort each into one of three outcomes before counting:
   - *Clean match:* an unambiguous canonical value. Use it.
   - *Parent or brittle match:* only a parent or sibling exists (for example "fintech" maps only to "Financial Services"). Stop and show the nearest entries, then ask whether to approximate with the parent, use a technology or intent proxy, or drop it. Do not substitute silently.
   - *No match* after 2-3 phrasings (bare term, full product name, vendor plus suffix): say there is no matching value and offer the same options.
   For flagship vendors, try the product-qualified name first ("Snowflake Data Cloud", "Stripe Payments").
   One industry taxonomy per query: try `linkedin_category` first and use `naics_category` only when LinkedIn has no clean match.
4. **Count** with `fetch-entities-statistics` (`entity_type: businesses`) on the resolved filters. For a country-scoped count, add the per-location breakdown for the requested countries instead of the headline total, because the headline may include other countries. State the numbers you used.
5. **Compare filter impact** whenever a tech-stack or intent filter is applied. Count with and without that filter and show both. A small filtered share can reflect a selective criterion or incomplete coverage; the ratio alone cannot distinguish them. Keep the filtered count as the count matching the requested ICP. Describe the unfiltered count as a broader comparison pool, and do not drop a requested criterion without the user agreeing.
6. **Classify the working number:** over 50,000 is too broad; 5,000-50,000 healthy, so suggest tiers; 1,000-5,000 is a sweet spot; 250-1,000 is niche, so check capacity; under 250 is too narrow, so suggest widening.
7. **Sample accounts only when needed.** The default is counts only. Run `fetch-entities` (businesses) with a small `page_size` (10) if the user asked for names, if a filter produces questionable matches, or if you accepted a parent approximation and want to see whether it captured what the user meant. The sample is directional, not ranked; do not compute percentages from it. If the rows reveal irrelevant matches, describe the examples, refine the filters with the user, and re-count. Do not extrapolate a noise rate or adjusted market count from a small unsorted sample.
8. **SAM (only if both inputs were given):** companies × fraction, then × revenue per account. Label it a hypothesis, not a forecast.
9. **Offer refinements,** each naming a dimension and the likely effect on the count, and re-count after any change. Finish by offering `list-builder` with the final filter set.

## Reply

- **Headline:** "about [count] companies" rounded to two significant figures, and the band. Show raw, filtered and unfiltered numbers when the filter-impact comparison was run.
- **Filters applied:** dimension, value, and source (stated by the user, assumed, or approximated). Persona criteria are marked "not applied to the company count".
- **Sample accounts** (only if run): why it was run, and the noise you found.
- **Refinements** or the final filter set.
- **SAM** if requested.

## Limitations

- Size and revenue are buckets, and revenue buckets look like an estimate derived from headcount, so one bucket often dominates. Do not slice revenue after fixing size.
- Samples are unsorted and directional.
- No metro-area filter; geography is country, region or US city.
- Persona criteria are never applied to the company count.
- No Inc 5000 or Fortune ranking filter; public or private is the only company-type flag.
- Flagship vendor names sometimes autocomplete poorly; surface that instead of substituting.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: meeting-prep
description: "Prepare a 30-minute call brief for a target account: headline signals, attendee profiles, ranked talking points, discovery questions, a suggested agenda, and what to avoid. Use for 'prep me for a call with Acme', 'I have a meeting with Jane at Globex tomorrow', 'pre-meeting research', renewal or QBR meetings. Not for general research with no meeting (use account-research) or for a standalone person lookup (use enrich-contact)."
---

# Meeting Prep

Gather the company, signal and attendee evidence, then write a tight brief the user can read in five minutes.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Input

- **Account** (required): a company name or domain.
- **Attendees** (recommended): names with the company, or emails. Without them the brief stays generic.
- **Meeting context** (strongly recommended): purpose, stakes, deal stage, what the user wants to walk out with, known tensions, competitors, what they are selling, and hypotheses to test. If it is missing, ask once; otherwise prepare general notes and say so.

## Workflow

1. **Anchor.** Restate the purpose and desired outcome in 1-2 sentences and pick 3-5 priority topics and any hypotheses.
2. **Match the company** with `match-business`, checking for the shell-entity pattern (big brand, 1-50 employees, "Corporate Managing Offices") and retrying with the alternate domain.
3. **Enrich the company** in one `enrich-business` call, listing the types in `enrichments`: firmographics and technographics, funding-and-acquisitions, strategic-insights and challenges, workforce-trends, competitive-landscape and company-hierarchies, linkedin-posts and website-changes. Gather broadly now; decide what matters at the writing step.
4. **Fetch events** with `fetch-businesses-events` on a 30-90 day window. Keep only events that name this company and tie to the meeting.
5. **Match the attendees** with `match-prospects`, by email when known, otherwise full name plus company (add the `business_id`). Report anyone who does not match; never invent their role. Enrich matched people with `enrich-prospects` and `profiles` for title, tenure and prior roles, plus `linkedin-posts` for recent topics they post about. Add `contacts` only if the user wants to reach out, with `parameters.contact_types` set to `["email"]` unless phone is needed.
6. **Write the brief,** then the TL;DR last. Choose what matters for this meeting, drop generic press, and mark past-dated milestones "verify". Describe engagement or objections only when the user supplied direct interaction evidence. Without it, write 'Engagement unknown'; tenure, prior employers and public company activity do not establish an attendee's attitude toward the user or offering.

## Reply

- **TL;DR:** purpose and desired outcome, the top 3 things to know, a one-line check of each hypothesis (confirmed, contradicted, unresolved), and a suggested opening line.
- **Company snapshot:** industry, size bucket, revenue bucket, HQ, and one paragraph on strategy and challenges.
- **Signals worth raising,** grouped by funding, hiring, tech stack, events, voice and competitors.
- **Attendees:** name, title, department ("Unattributed" if empty), seniority, tenure, contact details if enriched, engagement evidence or "Engagement unknown", why they matter for this meeting, and 1-2 specific talking points. "Profile data limited; verify elsewhere" when thin.
- **Talking points (3-5)** and **discovery questions (3-5),** each tied to a specific fact.
- **Suggested agenda (30 minutes):** open, explore, develop, close on a specific next step.
- **What not to do:** 1-3 concrete failure modes for this meeting.

## Limitations

- Strategy and challenge data come from public filings: empty for private companies and 12-18 months old for public ones.
- No CRM history or deal-stage data; engagement status depends on direct interaction evidence supplied by the user, not profile or public company activity.
- No executive-move event type; infer leadership changes from workforce trends and profiles.
- Size and revenue are buckets; quote them as such.
- Attendees who cannot be matched stay unresolved.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: score-leads
description: "Score and tier a list of target accounts (A, B, C by ICP fit, buying intent, recent trigger events and hiring momentum) or a list of people (Hot, Warm, Cold against a buyer persona and ICP), with a one-line 'why now' per row. Use for 'score these accounts', 'rank this list by ICP fit', 'prioritize my leads', 'which of these should I call first', 'tier my inbound leads'. Works on lists pasted in chat. Not for building a new list (use list-builder) or for research on a single company (use account-research)."
---

# Score Leads

Resolve a list, gather evidence for each row, then apply a transparent rubric the user can adjust. The scoring is your reasoning over the returned data; there is no built-in scoring engine.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Choose a mode

- **Accounts:** the list is companies (names, domains). Output is a tier A/B/C with a score per account.
- **People:** the list is leads (emails, LinkedIn URLs, or name plus company). Output is Hot, Warm or Cold per person.

## Input

- **The list** (required), up to 50 accounts or 40 people per match call.
- **ICP** (required): industries, headcount and revenue buckets, countries or regions, optional tech vendors, optional intent topics. For people, also the **buyer persona**: titles, seniority, department.
- **Optional:** a source label per lead (demo request, pricing inquiry, webinar) passed through as given; weights; tier thresholds; trigger window (default 90 days).

If the ICP is missing, ask for it; do not invent one.

## How many rows to score

Every enrichment and event call returns full values, but each one uses credits per row. Score up to 50 rows in one pass; for more, score the first 50 and offer to continue in batches.

## Workflow

1. **Lock the rubric.** Restate the ICP and persona. Resolve free-text values with `autocomplete`, one term at a time. If an intent topic does not resolve, drop it and mark that axis "not configured" instead of "no intent".
2. **Resolve identities.** Run `match-business` (accounts) or `match-prospects` (people); results are complete, so read them directly.
   - An email is a unique key: a miss is a miss, never a fallback to a name search.
   - A name plus company match at a large company can be ambiguous; mark it "Verified, check".
   - A role without a name ("the CFO at Asana") does not match as a name: match the company, then use `fetch-entities` filtered by title and seniority and let the user pick.
   - Check each resolved company for the shell-entity pattern (a big brand with 1-50 employees under "Corporate Managing Offices") and retry with the alternate domain.
   - Tag each row: resolved, verified-check, ambiguous (ask the user), or failed. Never drop a row silently.
3. **Gather evidence,** naming several types per enrichment call and passing up to 50 IDs:
   - Accounts: `enrich-business` with firmographics, technographics, workforce-trends, funding-and-acquisitions, linkedin-posts and website-changes, then `fetch-businesses-events` (20 companies per call) for the trigger window.
   - People: `enrich-prospects` with `profiles` (add `contacts` if the user wants contact data), `enrich-business` with `firmographics` for their employer, and `fetch-businesses-events`. For job-change signals, `fetch-prospects-events` (`prospect_changed_role`, `prospect_changed_company`).
   - Intent: a `fetch-entities` scoped with `business_id` values and `business_intent_topics` shows which accounts have the topic; `enrich-business` with `bombora-intent` adds topic scores.
   Before using an event, check that it names the account; industry-wide stories get attributed to several companies.
4. **Score.**
   - *Accounts, 0-100:* default axis weights are Fit 45, Intent 25, Trigger 25, Workforce 5.
     - **Fit:** use only criteria specified in the ICP. Maximum points: industry 25, headcount 20, revenue 20, geography 15, company age 10, named technology 10. Industry earns 25 for a match or 10 for an explicitly accepted adjacent category. Headcount and revenue earn 20 for the requested bucket, 12 for one bucket off, 4 for two off. Geography earns 15 for a match or 8 for an explicitly accepted broader region. Age and technology earn 10 for a match. Other evidenced mismatches earn 0. Exclude unspecified criteria; report missing evidence and exclude that criterion from the denominator. Fit score = 100 times earned points divided by maximum points for the criteria actually assessed. If none can be assessed, Fit is unknown.
     - **Intent:** 90, 70 or 50 for three or more, two or one resolved topics active; 0 only when a completed topic check finds none. Without configured topics or sufficient coverage, mark the axis unknown.
     - **Trigger:** use the strongest returned event. Type score: funding or M&A 95; product launch, hiring surge or large site change 75; partnership or new office 55; generic company news 25. Multiply by recency: 0-14 days 1.0, 15-30 days 0.7, 31-60 days 0.4, 61-90 days 0.2. Use 0 if a completed event query returns no qualifying events; if the query fails or coverage is unknown, mark the axis unknown. Do not infer a CEO change from a generic employee-joined event.
     - **Workforce:** use 90 for evidenced strong growth or a hiring surge in the target department, 55 for modest growth, 20 for flat or shrinking. Cite the returned trend; do not infer exact growth percentages from headcount buckets. Without sufficient evidence, mark the axis unknown.
     - **Total:** sum(axis score times axis weight) divided by sum(available axis weights), rounded to the nearest integer. Report missing axes and assessed fit criteria. If no axes have evidence, leave the score and tier unassigned. Default tiers: A at 75 or more, B at 50-74, C below.
   - *People, three checks:* persona fit (title, seniority, department against the persona), account fit (ICP), and a trigger (account event or a recent role change for them). Hot needs persona fit, account fit and one trigger; Warm needs persona plus either; everything else is Cold. A lead missing both a professional email and a phone gets "verify contact data before outreach".
5. **Write "why now"** as one sentence anchored on the strongest signal, never the score restated. Be explicit when a strong trigger sits on a poor fit ("fresh funding, but the size bucket keeps this in C").

## Reply

- **TL;DR:** counts resolved, ambiguous and failed; the tier distribution; the top 3 with their "why now".
- **Ranked table:** rank, account or person, tier, score or checks, axis detail, why now. Use "-" for a redistributed axis.
- **Resolution summary:** input, resolved to, status; list ambiguous rows with candidates for the user to pick.
- **Rules used:** weights, thresholds, window, and anything redistributed.
- **By tier:** A or Hot for personal outreach within a day; B or Warm for a sequence that opens with the "why now"; C or Cold to watch. Offer to adjust the weights and re-rank without new calls.

## Limitations

- No scoring engine or per-row confidence; the score reflects the data fetched and your reading of it.
- Headcount and revenue are buckets, so banded scoring is the right resolution.
- Filing-based challenge and strategy data is empty for private companies and 12-18 months old for public ones; use events, funding, workforce trends and posts for current state.
- No CRM engagement data (deal stage, last activity); workforce momentum is the substitute and the gap is stated.
- One industry taxonomy and one location level per query.
- Department is empty for many Chief X Officer, President and Founder roles: "Unattributed".

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: talent-sourcing
description: "Source candidates from a job description or role brief, or map the talent bench for a function across target or competitor companies with movement signals such as layoffs and leadership changes. Use for 'find candidates for a senior Go engineer in Berlin', 'build a talent pipeline for a VP Sales', 'who could fill this role', 'map the data engineering teams at our competitors', 'where can we hire from'. Recruiting and talent intelligence only. Not for sales prospecting (use list-builder) or for researching a named person (use enrich-contact)."
---

# Talent Sourcing

Turn a role brief into a candidate search, or map where a function's talent sits across companies.

## Connector rules

Use only the AgentSource tools in your tool list. Each tool's live description and input schema are authoritative; if this skill disagrees with a tool, follow the tool.

- **`tool_reasoning`** is required on every call: the user's original request in their exact words (up to 2000 characters), reused unchanged across chained calls for the same task. Never replace it with a per-step rationale or add personal data the user did not write.
- **Sessions:** reuse `session_id` from the previous response while continuing the same request; omit it to start a new request. Never invent one.
- **Chaining by ID:** pass `business_id` and `prospect_id` values from `match-business`, `match-prospects` or `fetch-entities` results. Do not re-match entities that a fetch already returned.
- **`autocomplete` first**, one concept per call, for `linkedin_category`, `naics_category`, `company_tech_stack_tech`, `job_title`, `interests`, `skills`, `business_intent_topics`, and US `city_region`. Use the returned values as-is. Use ISO codes directly for countries (`US`) and regions (`US-CA`).
- **What you see:** every tool returns full results inline. `fetch-entities` returns up to `page_size` rows per call (at most 500) and a `next_cursor` for the next page; `fetch-entities-statistics` returns aggregates over every match.
- **Credits:** every data call uses credits on the user's AgentSource account. Request only the rows and enrichments the task needs, count with `fetch-entities-statistics` before a large pull, and confirm with the user before fetching more than 100 rows or enriching contact details for more than 50 people.
- **Limits per call:** `match-business` 50 companies, `match-prospects` 40 people, `enrich-business` and `enrich-prospects` 50 IDs, `fetch-businesses-events` 20 companies. Name several enrichment types in one `enrichments` list rather than one call each.
- **Presenting:** show returned records in a table with the fields that matter for the task. Never mention session IDs or internal table names.
- **Event details:** if a fetch used the `events` filter and the user did not already ask for event details, ask before calling `fetch-businesses-events` or `fetch-prospects-events`.
- **Lists:** work from lists pasted in chat or text from attached files, in batches that respect the limits above.

## Choose a mode

- **Pipeline:** the user has a role to fill and wants candidates.
- **Bench map:** the user wants to see who does a function across a set of companies and where talent may be open to a move.

## Fair-hiring and privacy rules

- Never filter, score or comment on protected characteristics (age, gender, ethnicity, religion, disability, nationality, family status) or on proxies for them, such as graduation year to infer age or a name to infer gender or origin. If the brief asks for that, decline that criterion and say why.
- Use only job-related evidence that the data shows. Mark a skill the profile does not show as "unverified" instead of inferring it.
- Use contact data only for recruiting outreach about a real role, and remind the user to honor opt-outs and local rules (GDPR, CCPA).
- Do not pull personal contact data during a bench map.

## Pipeline mode

### Input

Role (title, seniority, function); must-haves and nice-to-haves (propose a split and confirm if the brief does not separate them); the source-company profile or named target companies; exclusions (current employer, no-poach clients); geography; the number wanted (default 30, up to 150).

### Workflow

1. **Blueprint.** Translate the brief into a candidate profile and a source-company profile. Expand the title into 3-6 adjacent titles a strong candidate might hold today, and note a step-up pool one level below if the role is a promotion for most people. Show the blueprint and confirm before searching.
2. **Resolve values** with `autocomplete` for titles, skills, interests, industries and technologies.
3. **Source companies.** For named companies, `match-business` and check for shell entities; for a company profile, set the company filters directly on the prospect search. Drop excluded companies using `business_id` with `negate: true`.
4. **Encode the must-haves as filters:** titles with `job_title` plus `job_level` and `job_department`, location, `skills` or `interests` where the brief names them, `total_experience_months`, and `current_role_months` for tenure (candidates 2-4 years into a role are often the most movable; under 12 months rarely are). Title filters are loose, so pair every title with seniority.
5. **Fetch** with one `fetch-entities` call for prospects at the requested count. If the pool is very large or tiny, check it with `fetch-entities-statistics` first and suggest tightening or broadening. Add `enrich-prospects` with `profiles` for work history, tenure and prior employers. Add contact enrichment only once the user is ready to reach out, with `contact_types` as the user chooses.
6. **Movement signals,** if asked: `fetch-businesses-events` on the source companies for `cost_cutting`, `merger_and_acquisitions`, `decrease_in_*_department` and `new_funding_round`, and `fetch-prospects-events` for recent role changes. Someone who changed jobs in the last six months is rarely movable; mark them, do not drop them.
7. **Rank** the returned candidates. Score each 0-100: must-have fit 50 (a missing must-have caps at 49), nice-to-have fit 20, movability 20, reachability 10.

### Reply

Role blueprint as confirmed; the candidates shown (name, current title, employer, tenure, location, why they fit in one clause); pool read (matching count, any must-have the data cannot evidence, thin geographies); the first people to contact and a specific angle drawn from their trajectory; and next steps (contact enrichment, the next page, step-up pool, bench map of the best source companies).

## Bench map mode

### Input

A function (required), a company set (named, or a profile capped at 15 companies), optional seniority focus (default Manager and above plus senior individual contributors), geography, and depth: overview (default) or named leaders.

### Workflow

1. **Resolve the companies** with `match-business`, checking for shell entities. If a profile matches more than 15 companies, ask the user to tighten it.
2. **Define the function** as a department plus 4-8 discovered titles across the ladder (individual contributor to C-level). Confirm, since "data" alone can mean analytics, engineering or science.
3. **Count per company** with `fetch-entities-statistics` (`entity_type: prospects`, `business_id` for that company, the department and level filters). Read the aggregates.
4. **Name leaders** only for "named leaders" depth: `fetch-entities` for Directors and above in the function across the set, with `page_size` sized to the roster. Skip contact enrichment.
5. **Signals,** last 180 days: `fetch-businesses-events` for `cost_cutting`, `merger_and_acquisitions`, `closing_office`, `decrease_in_*_department`, `new_funding_round`; `enrich-business` with `workforce-trends` for headcount direction; `fetch-prospects-events` for role changes among leaders. Check each event names the company.
6. **Rate each company as a talent source:** bench depth (35: counts relative to the other companies), movement pressure (40: layoff or restructuring 90-100, new function leadership in the last six months 70-85, acquisition 70, declining headcount 50-70, flat 30, strong growth or a fresh large round 10-20), and tenure ripeness (25: the share 2-4 years into role, if you can see it). Do not score individuals here.

### Reply

Map scope (function, titles, levels, companies, any that failed to resolve); a ranking table (company, bench size, directors and above, headcount trend, key signal, source score, why); a short block per company; a market read (deepest benches, most pressure now, feeder companies); and next steps (pipeline mode on the top three, re-run in 60-90 days, `lookalike-accounts` seeded on the best source).

## Limitations

- Profiles show what people publish: skills, scope and team size are often missing, so absence means unknown.
- No skills or certification filter beyond `skills` and `interests` autocomplete values.
- No sub-department function filter; use department plus discovered titles.
- No executive-departure event type; leavers show up only indirectly.
- Headcount and revenue are buckets, so company-size cuts are approximate.
- Compensation, visa status and willingness to move are not available.
- Large companies can return thousands of matches; the map relies on counts beyond what you can read.

Referenced files: 1 — file references are metadata, not package contents.