account-scoring

Account scoring

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

Every account scored against your ICP, tiered, and written back to the CRM with the rationale, so a rep can always see why an account is tier A. The criteria are not point weights in code: they are the ICP markdown in your context repo, versioned in git and shared with every other agent. Edit the ICP and accounts re-score against it as they come due.

Two failure modes worth knowing before you start. If the CRM properties do not exist, the run looks successful and the scores land nowhere, which wastes the whole batch. And cargo_score plus cargo_tier must be selected as columns on the accounts model, or the tier segments filter on a column they cannot see.

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:

• icp: the file names at least one disqualifier, not only fit signals
• crmScoreProperties: all four exist, and cargo_score plus cargo_tier are selected as columns on the accounts model so the tier segments can filter on them
• tierThresholds: every tier the agent can emit is either covered by a segment or deliberately excluded

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.

• The scorer looks the account up before judging it. (agents/scorer.ts) A score guessed from the domain name is unfalsifiable and the rationale cites nothing. The evaluator exists to fail exactly this, and a book scored that way is worse than an unscored one because people trust it.
• ICP disqualifiers cap the score, they are not just negative weight. (agents/scorer.ts) Without a cap, a disqualified account with many fit signals still scores high and reaches a rep. The disqualifiers are the half of an ICP that actually protects the team's time.
• cargo_score and cargo_tier are selected as columns on the accounts model. (segments/tiers.ts) The tier segments filter on a column they cannot see, so they come back empty while everything upstream reports success.
• Every tier the scorer can emit is either covered by a segment or excluded on purpose. (segments/tiers.ts) The shipped segments cover A and C. The agent also emits B, so tier B accounts land nowhere and quietly disappear from the book.

Done when

• a test account run shows the agent's lookups in the trace, not a score guessed from the domain name
• the CRM record carries a score with a rationale citing real evidence and named ICP criteria
• the evaluator scores at least 0.8
• after the next model refresh the account appears in the matching tier segment

What it costs

One LLM call plus up to two Cargo database calls (matchBusiness, enrichBusinessFirmographics) per account, on arrival and again on the weekly sweep of accounts last scored three or more months ago. It scales with accounts in the model times re-scores, so a TAM built by tam-building scores at that size. Score a sample before the book.

Composes into

routing-engine (territories and capacity over the scored book), rep-cockpit, ai-sdr.