Skip to main content
A Play is versioned code that Deepline runs to perform repeatable GTM work. A Play can enrich a list, research accounts, route a lead, update a CRM, or produce an audience. It receives an input, runs the logic you define, and records the resulting run. Use a Play when the work is worth doing again, changing deliberately, or explaining later.

​
What a Play owns

A Play is the place for the business logic: which data to read, which tools to use, how to validate a result, and what to do next. It can return an output, create datasets for that run, and write to approved destinations. This boundary matters: a Monitor supplies data, the Database preserves it, and a Play decides what to do with it.

​
A Play has a lifecycle

This is why a Play is more than a one-off prompt. You can pilot a small input, review the output, publish the version that worked, and later see exactly which version made an earlier decision.

​
Run and inspect a published Play

Once a Play is published, you can run the same tested version with a new list, date range, or batch of accounts.
Every run keeps its input, the published version that ran, its status, logs, datasets, and returned result. A later edit does not change the evidence from an earlier run.
Use runs get --full to find the returned dataset paths before exporting a specific dataset. runs export writes the selected rows to a local CSV; it does not start another run.

​
The same Play can start in several ways

A trigger decides when a published Play runs; the Play decides what it does. The same tested code can be started from different entry points. Do the work manually until the output is useful. Adding a trigger then starts the published Play you already tested; it does not create a second workflow that can drift from the original. The Monitor writes the event; the Database listener starts the same published Play. Keep a manual path so you can reproduce and review the work without waiting for the next event.

​
Code is the durable description of the work

When a Play is authored in your codebase, a coding agent can inspect its logic, make a focused change, and test a small input before you publish it. Its source can use the same review and version-control practices as other code. You can also begin with a prebuilt Play. The important boundary remains the same: a Play contains executable logic; it is not a Monitor, a Database table, or an agent skill.

​
Skills and interfaces help you use a Play

A skill gives a coding agent the instructions it needs to author or run a Play. The CLI, SDK, MCP, and Claude plugin are interfaces for working with it. They all access the same Play lifecycle; none replaces the Play itself.

Run your first Play

Pilot one workflow and inspect the result before you scale it.

Example Prebuilt Plays

Start with a maintained example when it matches the work you need to do.

Schedules and webhooks

Configure the time- or event-based triggers for a published Play.

SDK reference

Read the TypeScript authoring surface and exact command reference.