tam-building

Tam building

State: to-be-approved. Deploy-verified against a live workspace: not yet. Treat Done when below as the acceptance test and review cargo-ai cdk plan before deploying. Make no outcome claim for this skill until it is approved.

The outcome

Your account universe, built from the Sales Navigator search that describes your whole market, even when that search returns far more than the extractor will hand over. Counted before it is extracted, split into sub-searches that each sit under the cap, resolved to real domains, and merged into the shared accounts model deduped.

The count is a design-time CLI call, not a deployed resource:

cargo-ai orchestration action execute --wait-until-finished \
  --action '{"kind":"connector","integrationSlug":"salesNavigator","actionSlug":"searchCompanyMetrics","config":{}}' \
  --data '{"url":""}'

It returns total_results and costs a fraction of a credit. Splitting order that usually works: industry first (descend the LinkedIn taxonomy only where a segment is still oversized), then geography, then headcount band. Recount every sub-search; split any that is still over.

Put it in your project

This folder is a worked example: real CDK resources written for some other company. The job is to end up with the code your company would have written, in your project, and an agent does the adapting. If the cargo-cdk skill is in your session it carries the long form of this; if not, this is enough.

1. Look first. grep -l '@cargo-ai/cdk' package.json says whether a CDK project already lives here; ls */models/*.ts */connectors/*.ts says what it already declares. If there is no project: cargo-ai cdk init --template blank && cd && npm install. That is the whole shell; this folder never ships one.
2. Copy this folder in as a sibling of what is there, then reconcile: for every model or connector this example carries that the project already has (an accounts model keyed on website, a HubSpot connector, an OpenAI connector), rewire the imports to the existing one and drop the copy. Two resources with one slug is a collision at deploy. Append this folder's .env needs to the project's .env.example; never overwrite it.
3. Adapt. Work the sections below in order: What should not change is what you argue back about (say what breaks, then do it if they still want it); What you can change is what you offer unprompted (nobody asks for a variant they do not know exists); What you will be asked is the floor, and you derive before you ask. If you are asking more than about four questions you have skipped lookups. Record what you changed and why under a ## Decisions section in your copy of this file.
4. Plan, then stop. npm run typecheck && cargo-ai cdk plan. Show the diff. Deploy only on an explicit yes: cargo-ai cdk deploy. Never cdk init --force into a non-empty directory.
5. Verify. Walk Done when line by line and report each with evidence. Deployed cleanly and produced nothing is the normal failure.

What you will be asked

Derive before you ask. An input with a lookup is looked up, not asked. Only the ones marked asked genuinely live in the operator's head.

Checked before moving on, not after the deploy:

• marketSearch: the URL is a linkedin.com/sales/search/company URL
• searchUrls: every sub-search count is strictly below config.limit; a count equal to the cap means it is still truncated and must be split again
• limit: at or below 1000

What you can change

The code is a worked example. These reshapes are expected, and the agent offers them rather than waiting to be asked. Every one costs something; that is what makes it a variation and not the default.

What should not change

However far you adapt, these hold. Ask for one anyway and the agent tells you what breaks, then does it if you still want it, and records why under ## Decisions in your copy of this file.

• Every company is resolved to a real domain before it is promoted into accounts. (plays/promote-to-accounts.ts) The shared accounts model keys on website. A domainless account cannot be deduped, so it forks into duplicates the first time the same company appears in another list. This is why a row that cannot be resolved is dropped rather than written.
• Every search is counted before it is extracted. (models/salesnav-companies.ts) Extracting blind is how you take a silently truncated list: the search holds 4,000 companies, the extractor takes 1,000, and nothing tells you the rest exist.
• No sub-search sits at or above the extraction cap. (models/salesnav-companies.ts) A search returning exactly the cap is truncated. That is the failure this whole skill exists to prevent, and it is invisible unless you check the number.

Done when

• the sub-search extractions sum to roughly the count of the original whole-market search
• no sub-search returned exactly the cap, which would mean it is still truncated
• promoted accounts appear in accounts with a website, deduped across overlapping sub-searches

What it costs

Counting is a fraction of a credit and is the cheapest insurance here. Promotion is the expensive step: every promoted company costs two credited calls (matchBusiness + enrichBusinessFirmographics), because Sales Nav returns no domain and both are needed to resolve one. A 5,000-company TAM is roughly 10,000 enrichment calls. That is the price of the outcome, not waste, but it is real money and it should be spent on purpose.

The control is upstream, where the rows are created: config.limit and how many sub-search URLs you add. To spend less, extract less. Start with one small sub-search, watch it land correctly, then widen.

Composes into

list-building (the same split tactic for people), contact-sourcing (the buyers at every account you just built), account-scoring, signal-based-tam (watch the universe you just built).