Action and system primitives
Primitive 1: the control plane decision
Clay is useful when a human wants to explore a list visually, test columns by hand, and review results inside a browser table. That is a real use case.
Deepline is the better fit when the workflow needs to run the same way every time: a CSV comes in, enrichment runs, output columns are written, and another system uses the result.
| Use Clay when | Use Deepline when |
|---|---|
| a human is experimenting in a table | the same motion should become a Workflow |
| the list changes by hand | the same CSV shape repeats every week |
| visual review is the main job | CRM, scoring, or outbound is the next job |
| one-off exploration matters most | repeatability and logs matter most |
Primitive 2: the waterfall prompt
You are converting a waterfall enrichment workflow into a repeatable GTM run.
Input file: leads.csv
Goal: find work emails for outbound review.
Required input columns: first_name, last_name, domain.
Required output columns: email, email_status, next_step.
Run a 10-row sample first.
Use a waterfall only when a single provider is likely to leave coverage gaps.
Do not overwrite existing emails unless the new result is verified or clearly better.
After the sample, summarize found, not_found, invalid, and needs_review rows.
This gives the operator the same practical benefit people like in Clay, but in a workflow that can be replayed.
Primitive 3: waterfall output with status
| first_name | last_name | domain | email_status | next_step | |
|---|---|---|---|---|---|
| Ada | Lovelace | example.com | ada@example.com | verified | ready_outbound |
| Grace | Hopper | example.org | not_found | retry_or_skip |
The status fields are the control plane. Without them, the output is just a spreadsheet with mystery cells.
How the primitives move through skills, scripts, and Workflows
Start with the Deepline skill. The skill is the primary way to ask for waterfall enrichment, inspect a small sample, and decide whether the result is worth operationalizing.
When the output is trusted, promote the same waterfall contract into a script for repeatable CSV runs or a Deepline Workflow for scheduled enrichment, review queues, and downstream CRM or outbound handoffs.
For prebuilt waterfall enrichment, use the routes documented for the play-backed enrich path:
POST /api/v2/enrich/compilePOST /api/v2/plays/checkPOST /api/v2/plays/run
POST /api/v2/enrich/compile validates and normalizes the enrichment arguments into an enrich config. That response is not itself a play artifact. The CLI/SDK-backed workflow then generates play source and a bundled artifact from the config.
POST /api/v2/plays/check validates the generated play artifacts before execution. POST /api/v2/plays/run starts the checked workflow. This gives scripts and Workflows a real compile, preflight, and run path rather than a UI-only sequence.
Waterfall aliases are composed play-backed flows. For customer-facing scripts, use name_and_domain_to_email_waterfall through deepline enrich or V2 play surfaces rather than treating it like an atomic provider operation.
Script pattern after the skill works
After the skill output is approved, deepline enrich is the cleanest script interface. It compiles enrich arguments into a V2 play config and runs the workflow through the plays runtime.
deepline enrich --input leads.csv \
--with '{"alias":"email","tool":"name_and_domain_to_email_waterfall","payload":{"first_name":"{{first_name}}","last_name":"{{last_name}}","domain":"{{domain}}"}}' \
--output out.csv
Use the JSON object form for --with. It must include alias, tool, and payload. The tool value can be a prebuilt waterfall alias for composed flows.
For custom play files that combine enrichment with scoring, routing, or CRM writes, keep the validation step explicit:
deepline plays check lead-waterfall.play.ts
deepline plays run --file lead-waterfall.play.ts --input '{}' --watch
Quality check before deploying a Workflow
Use deepline plays check <file.play.ts> or POST /api/v2/plays/check as the workflow preflight. This validates generated play artifacts before starting a run.
For waterfall-backed enrichment, distinguish compile from artifact validation. POST /api/v2/enrich/compile returns an enrich config. The CLI/SDK then generates play source and a bundled artifact that POST /api/v2/plays/check can validate.
Do not present provider-backed tests as no-spend validation. The test section for this workflow is about checking play artifacts before execution, not proving live enrichment results for free.
Before scaling, inspect whether the sample produces stable output columns, useful statuses, and a clear next step for missing rows.
Cost and billing behavior
Keep the billing model Deepline-facing. In BYOK mode, customer-owned provider credentials are stored encrypted in the customer's workspace database and Deepline does not add a platform fee for BYOK mode.
In managed mode, Deepline uses credit-based operation billing. Waterfall runs are easiest to reason about when the team starts with a small skill-generated sample, inspects the appended fields, and then scales the same spec once the outputs match the downstream workflow.
The operational goal is not to hide enrichment behavior behind a browser table. It is to make each compile, check, run, and output step visible enough for a GTM system to control.