Fivos Contact Sourcing

Fivos Contact Sourcing

Contact-level sourcing at already-sourced accounts. Runs after account-level work is done.

Hard rules

• AI Ark and Clay are the only contact sources. Per the TAM Mapping and Contact Sourcing Plan - 2026. No Apollo, no PDL, no Hunter, no Crustdata for contact discovery (they are still used for enrichment in the next step).
• Persona spec is required before any provider is called. No "go find some execs" runs - the engineer provides target titles, seniority, departments.
• Contacts-per-account caps are enforced. The strategist decided this number per play shape. Do not exceed it.

Inputs

• Enriched account CSV from fivos-account-enrichment (required).
• Persona spec (required):
• target_titles - specific titles (e.g. "VP of Revenue Operations", "Head of Data").
• seniority - {c-suite, vp, director, manager, ic} filter.
• departments - {sales, marketing, rev-ops, data, engineering, ...}.
• exclude_titles - optional exclusion list (e.g. "intern", "recruiter").
• Contacts per account (required, from fivos-campaign-strategist - usually 1 for static plays, 2-3 for ABM).
• Client tag + campaign tag (required for DB tagging).

Outputs

1. Contact CSV with columns: contact_id, company_domain, first_name, last_name, full_name, title, seniority, department, linkedin_url, country, region, city, source, sourced_at, client, campaign.
2. Account foreign-key column linking back to the account CSV.
3. Coverage report - contacts found vs target, per account.
4. Spend ledger.

Workflow

Step 1 - Translate persona to filters

Render the persona spec into AI Ark + Clay filter shapes.

AI Ark people filter:

{
  "account": { "domains": ["", "", ...] },
  "contact": {
    "titles_any": ["VP of Revenue Operations", "Head of RevOps", "Director of RevOps"],
    "seniority_any": ["vp", "director"],
    "departments_any": ["sales", "rev-ops"],
    "exclude_titles_any": ["intern", "recruiter"]
  },
  "page": 0,
  "size": 100
}

Clay: drive contact-finding via a Clay table that ingests the enriched account CSV and calls AI Ark Contact Search + Clay's native People Finder in parallel. See handoff below.

Step 2 - Estimate + Gate 1

For each provider, run the count endpoint first:

• AI Ark: mcp__ai_ark__people_count (free).
• Clay: estimate from mcp__claude_ai_Clay__get-credits-available plus historical hit rates (no free count endpoint).

Output:

Contact sourcing estimate -  / 

Accounts in scope: N
Target contacts per account: K
Expected unique contacts: ~N*K (after dedup)

Providers + cost:
  - AI Ark People Search: $X (0.5 credits/result)
  - Clay People Finder: $X (per-credit)
Total: $X

Proceed? Manager approval required.

Step 3 - Run AI Ark first

AI Ark is the lower-cost primary path. Call the MCP directly:

mcp__ai_ark__people_search({
  account: { domains: ["", "", ...] },
  contact: {
    titles_any: ["VP of Revenue Operations", "Head of RevOps", "Director of RevOps"],
    seniority_any: ["vp", "director"],
    departments_any: ["sales", "rev-ops"],
    exclude_titles_any: ["intern", "recruiter"]
  },
  page: 0,
  size: 100
})

Paginate until you hit contacts_per_account for each domain, or exhaust AI Ark's returns.

MCP status: mcp__ai_ark__* is being connected. Until then, fall back to AI Ark REST (POST /people/search with X-TOKEN header).

Step 4 - Top up with Clay

For accounts where AI Ark fell short of contacts_per_account, hand the remaining domains to Clay:

mcp__claude_ai_Clay__find-and-enrich-contacts-at-company({
  companies: [ { domain: "", target_contacts:  }, ... ],
  persona: {
    titles: [...],
    seniority: [...],
    departments: [...]
  },
  table_name: "__contacts"
})

Clay's strength is persona matching on fuzzy titles and department inference - use it for the residual where AI Ark's exact-title filters missed.

Step 5 - Dedup

Dedup on linkedin_url first, then email (when present), then full_name + domain as a fallback.

When a contact appears from both sources, prefer AI Ark for title and seniority (its taxonomy is tighter) and prefer Clay for department (its department inference is stronger).

Step 6 - Coverage report

Coverage report -  / 

Accounts: N
Contacts found: M
Mean contacts/account: M/N
Accounts at target (>= K contacts): P
Accounts short (: 0 contacts (reason: no titles matched the persona)
  - ...

If >15% of accounts are under-covered, flag for engineer review before handoff - usually the persona spec is too narrow.

Step 7 - Upload to internal DB + handoff

Upload the contact CSV to the Workflows DB, tagged with client + campaign + "contacts sourced ".

Hand off to fivos-contact-enrichment to waterfall email + phone.

Why only AI Ark + Clay

Decision from the TAM 2026 plan:

• Consolidating spend to two providers keeps vendor sprawl down.
• AI Ark covers 80% of cases cheaply with structured filters.
• Clay covers the residual with fuzzy-matching and the native Clay workflow engineers already use.

Other contact-discovery providers (Apollo, PDL, Hunter) are not used here. Their enrichment capabilities are still used in fivos-contact-enrichment - they just aren't used to find contacts at this step.

References

• ~/.agents/skills/gtm-meta-skill/provider-playbooks/ai_ark.md - People Search endpoint schema.
• ~/.agents/skills/gtm-meta-skill/finding-companies-and-contacts.md - discovery-order rules.
• TAM Mapping and Contact Sourcing Plan - 2026 (Google Doc).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: fivosaresti
• Source: fivosaresti/workflows-outbound-skills
• License: MIT

Install and usage instructions live in the source repository linked above.