fivos-account-sourcing

Fivos Account Sourcing

Single entry point for company-level sourcing. Encodes the "TAM Mapping and Contact Sourcing Plan - 2026" two-gate approval model. No company search runs outside this skill.

Hard rules

• Internal DB first. Always query the Workflows Supabase (Danny's layer) before spending on any external provider. If 80%+ of the need is covered internally, stop and deliver.
• Company search only. Contact search lives in fivos-contact-sourcing (AI Ark + Clay only). Do not pull people here.
• EasyScraper is the only alternative to the three databases, reserved for niche directory scraping where none of the three cover the ICP.
• Two approval gates, enforced in code:
  • Gate 1: before paid providers run. Shows expected company count + projected spend.
  • Gate 2: before the full qualification runs. Shows hit-rate from the 10-row sample.
• Every upload is tagged by client + campaign + list-contents description, so past lists stay filterable and reusable.

Inputs

• Filter JSON blocks from fivos-icp-segmentation (one per tier).
• Client tag (required) - the client this list is built for.
• Campaign tag (required) - the specific campaign this list feeds.
• Budget ceiling (optional) - hard cap that blocks Gate 1 if exceeded.

Outputs

1. Clay-ready CSV with these columns minimum: company_name, domain, linkedin_url, industry, headcount, hq_country, hq_region, funding_stage, last_funding_date, tech_highlights, source, source_confidence, client, campaign, sourced_at.
2. Spend ledger - what was spent per provider + running total.
3. Provenance log - which source each row came from and which source won each field during dedup.
4. Database upload confirmation - rows pushed to the internal Workflows DB with tags applied.

Workflow

Step 0 - Query the internal database (OPTIONAL - skip if you don't have one)

The internal database is a store of companies you've already sourced across past campaigns - firmographics, tech stack, funding, the tags client + campaign + list-contents. If your team has one, query it first to find overlap with the new ICP; any company already in there is free.

If you don't have an internal database yet, skip this step. The rest of the flow works fine. You just source everything from the external providers. Start building the database from Step 8 onward - every qualified CSV this skill produces gets uploaded, so the database grows with every campaign.

When the database exists, query it like:

python _query_internal_db.py \
  --filter-json <path> \
  --client <client-tag> \
  --campaign <campaign-tag>

(Wire this script to whatever DB you use - Postgres, BigQuery, Supabase, Snowflake. The skill doesn't care which, as long as the query takes a filter JSON and returns matching companies.)

If the internal DB returns enough coverage, you can skip the external providers entirely. Report to the engineer, get their go/no-go before calling paid APIs.

Step 1 - Fan out estimates across external providers

Run estimate-only calls on Discolike, AI Ark, and Ocean.io via their MCPs in parallel. No credits are spent on count endpoints. Produce:

Provider	MCP	Expected count	Projected spend	Notes
Discolike	mcp__discolike__*	X	$Y	weak on employee count
AI Ark	mcp__ai_ark__*	X	$Y	strong structured filters
Ocean.io	mcp__ocean_io__*	X	$Y	strong EMEA coverage

See disco-like.md, ai-ark.md, and ocean-io.md for per-provider syntax.

MCP status: the Discolike, AI Ark, and Ocean.io MCPs are being connected (expected tool prefixes mcp__discolike__*, mcp__ai_ark__*, mcp__ocean_io__*). Update the tool names inline once they're registered in this environment.

Step 2 - Gate 1 approval

Output a condensed approval block:

Account sourcing estimate - <client> / <campaign>

Tier: <Bullseye | Expansion | Experimental>
Internal DB coverage: X accounts (free)
External sources:
  - Discolike: ~N accounts, ~$S
  - AI Ark: ~N accounts, ~$S
  - Ocean.io: ~N accounts, ~$S
Estimated unique after dedup: ~N
Total projected spend: ~$S

Proceed? Manager approval required.

Do not run until the engineer returns explicit approval ("approved" / their manager's name + "ok").

Step 3 - Execute the search

Run all three MCPs in parallel once approved. Respect each provider's rate limits (see sub-files). Record every response to /tmp/sourcing-<client>-<campaign>-<timestamp>.jsonl for audit.

Step 4 - Dedup + source trust

Consolidate the same company across sources into a single row. Use the following source-trust table when fields conflict:

Field	Preferred source	Reasoning
company_name	Ocean.io > AI Ark > Discolike	Ocean.io normalises best
domain	AI Ark > Ocean.io > Discolike	AI Ark canonicalises subdomains
headcount	AI Ark > Ocean.io > Discolike	Discolike is weak on employee count
funding stage/date	Crustdata (via enrichment) > AI Ark > Ocean.io	Crustdata has the deepest funding graph
industry	Ocean.io (NAICS) + AI Ark (plain)	Keep both fields
hq_country	all three agree >99% of the time	use majority vote
tech_highlights	BuiltWith (enrichment step) > source providers	source providers are imprecise

Always emit a source column listing every provider that returned the row, and a source_confidence score (simple: number of sources that agreed, divided by 3).

Step 5 - 10-row qualification sample

Hand the first 10 deduped rows to fivos-lead-scoring in sample mode. That skill scores in-session through Claude (or swaps to a dedicated qualification model if you've wired one) and returns per-row reasoning.

Step 6 - Gate 2 approval

After the sample, output:

Qualification sample - <client> / <campaign>

Rows run: 10
Pass: X (X0%)
Fail: Y with reasons: <top 3 reasons>

Re-projected full run:
  - Accounts to qualify: N
  - Projected qualification cost: $S
  - Projected kept-after-qualification count: ~M

Proceed to full run? Manager approval required.

Pause until explicit approval.

Step 7 - Full qualification

Re-invoke fivos-lead-scoring on the full set once approved. Output the CSV with a tier column appended.

Step 8 - Upload to internal DB (OPTIONAL - skip if you don't have one)

If you skipped Step 0, skip this too. If you have an internal DB (or are building one starting this campaign), upload the qualified CSV with tags:

python _upload_to_db.py \
  --csv <path> \
  --client <client-tag> \
  --campaign <campaign-tag> \
  --contents "<short description: ICP cut, geo, sourcing date>"

Every upload must carry the client + campaign + contents tags so the list can be filtered and reused later. This is how the internal DB compounds over time - each campaign makes the next one cheaper.

Step 9 - Handoff

Invoke fivos-account-enrichment with the qualified CSV. That step adds custom data points (tech stack, funding, hiring signals) before contacts are pulled.

EasyScraper fallback

Use only when:

• The ICP is a niche directory (e.g. certified installers, association members, conference attendees).
• None of Discolike / AI Ark / Ocean.io return meaningful coverage.

The agent detects this case during Step 1 (low estimate counts across all three) and proposes EasyScraper as an alternative. Follow ~/.agents/skills/firecrawl-crawl/ or ~/.agents/skills/firecrawl-agent/ for implementation. Route output through the same Steps 4-8.

Sub-files

• disco-like.md - Discolike filter syntax, pricing, weaknesses.
• ai-ark.md - AI Ark structured-filter examples, credit costs, pagination.
• ocean-io.md - Ocean.io filter schema, complementary coverage.

References

• ~/.agents/skills/gtm-meta-skill/provider-playbooks/ai_ark.md
• ~/.agents/skills/gtm-meta-skill/provider-playbooks/crustdata.md
• ~/.agents/skills/gtm-meta-skill/provider-playbooks/apollo.md (fallback only - generally not used in TAM 2026 plan)
• ~/.agents/skills/gtm-meta-skill/recipes/build-tam.md
• TAM Mapping and Contact Sourcing Plan - 2026 (Google Doc).