Action and system primitives
Primitive 1: timing, not proof
Buyer intent data can help prioritize accounts, but it should not override fit. A weak intent signal from a poor-fit account is still a poor-fit account.
| Scoring question | Intent field to inspect | Human rule |
|---|---|---|
| Is the account in-market? | topic, category, recency | only count signals tied to ICP topics |
| Should a rep act now? | signal age, strength if available | recent signals beat stale signals |
| Is this a good account? | fit fields plus intent | fit comes before timing |
| What should happen next? | reason, next action | route only when the reason is explainable |
Primitive 2: the intent-scoring prompt
You are reviewing buyer intent data for account prioritization.
Goal: rank accounts for sales follow-up.
ICP topics: data enrichment, outbound automation, GTM engineering.
Required output fields: account, signal_topic, signal_recency, fit_status, score_change, score_reason, next_step.
Run a small sample first.
Do not label an account high intent unless the signal matches an ICP topic and the account has basic fit.
For every score change, write a plain-English score_reason.
Mark weak or stale signals as review, not ready_for_sales.
The reason field is what makes intent data usable. It lets a human audit why an account moved up or down.
Primitive 3: explainable scoring output
| account | signal_topic | fit_status | score_change | score_reason | next_step |
|---|---|---|---|---|---|
| Example Co | data enrichment | fit | +15 | recent matching topic from fit account | sales_review |
| Sample Inc | generic AI | weak_fit | 0 | topic is broad and account fit is weak | hold |
Intent should explain timing. It should not become a vague urgency label.
How the primitives move through skills, scripts, and Workflows
Start with the Deepline skill. The skill is the primary way to ask for intent signals, inspect false positives, and decide whether the signal changes account priority.
When the scoring reason is explainable, promote the same criteria into a script for repeatable scoring runs or a Deepline Workflow for scheduled routing and CRM handoffs.
Provider-backed intent workflows use the integration execution surface:
POST /api/v2/integrations/{toolId}/execute
The {toolId} must be a real provider tool id. Because buyer intent data workflows are provider-specific, scripts and Workflows should use tool discovery and description before execution:
GET /api/v2/tools/search
GET /api/v2/integrations/{toolId}/get
This keeps the workflow tied to documented tool schemas instead of generic intent claims. After execution, the script or Workflow can map returned signals into lead scoring criteria used by CRM updates, outbound sequencing, or account routing.
Script pattern after the skill works
Use the CLI to discover candidate provider tools after the skill has narrowed the intent job:
deepline tools search intent --json
deepline tools describe <provider-tool-id> --json
Then execute the selected provider action only with a payload copied from the described schema. Scripts and Workflows must not execute a guessed generic buyer-intent payload:
deepline tools execute <provider-tool-id> \
--input '<schema-specific-json-from-tools-describe>'
The next step should be a scoring rule, not an implicit handoff. For example, the script or Workflow can add points when a returned intent signal matches the ICP topic list, reduce confidence when required fields are missing, and write the reason into the account record.
Quality check before deploying a Workflow
No no-spend workflow-specific test route is currently documented for provider-backed buyer intent data workflows. POST /api/v2/integrations/test should not be documented as safe validation for paid provider-backed intent work unless the endpoint map explicitly confirms that behavior.
Use the skill to validate the scoring logic first, then run small scripted samples only when real execution is acceptable.
Before scaling, inspect whether intent signals are changing the right decisions. If the output cannot explain topic, recency, fit, and next action, it is not ready for automated scoring.
Cost and billing behavior
Keep billing language Deepline-facing. In BYOK mode, customers bring their own data-provider keys and Deepline does not add a platform fee for that mode. In managed mode, Deepline uses credit-based operation billing.
Intent signals should be sampled before they become scoring criteria. Inspect false positives, missing fields, and fit with your ICP before scaling the workflow across the full pipeline.