---
name: moltsets-attio-buying-committee-expansion
description: For an open Attio deal, find the stakeholders you do not yet have, enrich them with MoltSets, and create them as person records associated to the deal.
---

# Attio Buying Committee Expansion

## Triggers

- "For this open deal, find the rest of the buying committee and add them as contacts"
- "Expand this Attio deal with VP and Director stakeholders at the same company"

## What this skill does

Surfaces the rest of the buying committee for an open Attio deal. Starting from the deal's associated company, it searches MoltSets for people in the target titles and seniority levels, dedupes them against the people already linked to the deal, fills email gaps, creates the new person records in Attio, and links each one to the deal's people reference attribute. It finds the stakeholders your reps did not know to look for.

## Chain

```
Attio open deal record
  to attio/get-record                   (deal + associated company domain, read directly off the deal's reference attributes)
  to MoltSets:
      search_people                     (company_domain + target titles / seniority / department)
  to dedupe against existing deal-linked people + suppression rules
  to linkedin_to_best_email             (fill email gaps where search_people has none)
  to attio/create-record                (create new person records)
  to attio/update-record                (add new people to the deal's people reference attribute)
```

## Inputs

- **Deal** - the Attio deal to expand, or a filter for a set of open deals
- **Target roles** - the titles, seniority levels, and departments that make up your buying committee
- **Coverage** - how many people per account to add, and any hard caps
- **Suppression rules** - domains, existing records, and do-not-contact lists to exclude
- **Acceptable risk scores** - which A-F deliverability grades to keep (recommended: A, B, C and F; D excluded)

## Risk scores - confirm before enriching

Every email MoltSets returns carries a deliverability risk score - a grade from A to F. Ask which grades to keep before running anything:

> "MoltSets grades email deliverability risk from A (best) to F (no data). Which grades should I keep? I'd recommend **A, B, C and F** - and dropping **D**, since D is a confirmed bounce, complaint or spam trap."

| Grade | Meaning | Best practice |
| --- | --- | --- |
| A | Strongest engagement signal available | Safe to send immediately |
| B | Solid | Fine in regular sends; on a new or warming domain, send a smaller batch before scaling |
| C | Deliverability can't be confirmed | Segment separately from A/B, warm at low volume, watch engagement, suppress non-responders after 1-2 attempts |
| D | Confirmed bounce, complaint or spam trap | Never send - fastest way to trip spam traps and damage sender reputation for the whole list |
| F | No data - unknown risk, not "safe" | Re-verify before sending, or treat like C |

Use whatever set the user confirms. Treat the grade as a filter, not a guarantee - it lowers risk, it doesn't remove it. Pair it with the user's own sending domain reputation and list hygiene.

## `search_people` filter notes

- **Filters are free precision.** Execution cost comes from the free-text `query`, not the filters attached to it. A filters-only call (no `query`) runs **~40x cheaper**; a bare `query` is the least precise shape available and no cheaper than a filtered one. Never send `query` alone - at minimum attach `country` (~99% filled). Billing is unchanged either way: tokens are charged per record returned.
- **Full filter set:** `query`, `company`, `company_domain`, `country`, `state`, `city`, `seniority`, `department` *or* `functional_area` (same underlying data - never both), `industry`, `linkedin_industry`, `naics_code`, `employee_range`, `revenue_range`, plus `limit`/`offset`.
- **`employee_range` and `revenue_range` apply to the person's current employer**, so you can target by company size or revenue without a `search_companies` pass first. Prefer the numeric bands over legacy `"Small"`/`"Mid-Market"`/`"Enterprise"`/`"Unknown"`.
- **Three industry vocabularies:** `industry` (21 broad buckets), `linkedin_industry` (LinkedIn's ~150 niche labels), `naics_code` (any hierarchy level - "54" broad, "541120" surgical). Pick the one matching how specific the targeting actually is.
- **Fill rates:** `country` ~99%, `title` ~85%, `headline` ~65%, `seniority`/`industry`/`department` ~60%, `naics_code`/`linkedin_industry` ~50%. Every filter is exact-match and silently drops records with an empty field, so stacking three sparse ones can zero out a viable audience. Widen by dropping the sparsest filter first, not `country`.
- **Exact strings:** `"C Suite"` (space, not hyphen), `"Marketing & Advertising"`, `"Medical & Health"`, `"Texas"` not `"TX"`, `"United Kingdom"` not `"UK"`.
- **Size before you walk.** `search_linkedin_profile` with `count_only: true` returns a match count free of tokens; every search response carries `results.total`. Results are `_score`-ranked - the first page is the best page, 25 max per call.
- **Emails are already in the results** - records carry `business_email` and `business_email_risk_score`, so those rows need no enrichment call.

## How it works

1. Reads the deal record directly, resolving the associated company's domain from the deal's own reference attribute rather than a separate association call
2. Reads the people already linked to the deal so they can be excluded from the results
3. Runs `search_people` filtered on the company domain plus your target titles (via `query`), `seniority`, and `department` filters
4. Dedupes the returned people against existing deal-linked people and your suppression rules
5. Uses the `business_email` returned by `search_people` where present, and runs `linkedin_to_best_email` to fill any gaps
6. Creates the new person records in Attio and adds each one to the deal's people reference attribute

Before any write-back, every found address is checked against the accepted grade set. Out-of-range grades are reported in the table with their true score and skipped - never written to the CRM.

## Output

| Name | Title | Seniority | Company | Email | Risk | LinkedIn | New/Existing | Linked to Deal |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |

Show the risk score on every row that has an email, including grades outside the accepted set - flag those in `Action` (e.g. "held - grade D") rather than dropping them silently. Only emails inside the accepted set are written back to the CRM.

```
Deal company:            X
Existing deal people:    X
Candidates found:        X
New records added:       X
Emails found:            X/N (XX%)
MoltSets tokens used:    X

Email risk scores:
  A: X   B: X   C: X   D: X   F: X
  kept (accepted grades):  X
  filtered (excluded):     X
```

## Tips

- Requires the Attio MCP (mcp.attio.com) and the MoltSets MCP connected in the same client
- `search_people` returns a business email in many records, so check that field before spending a token on a separate email call
- Use `company_domain` for the account match rather than free-text company name, since domain is exact
- Set a per-account cap so a large company does not flood the deal with dozens of loosely relevant records
- Creating records and updating the deal's reference attribute changes the deal, so run a dry-run pass and confirm before writing
- This pattern works identically for a custom deal-like object, since the reference-attribute model is the same across standard and custom objects in Attio