> ## Documentation Index
> Fetch the complete documentation index at: https://deepline.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Plays
> Build repeatable GTM work as versioned Deepline code. Your agent can create, test, and improve each play while Deepline records every run.
## GTM is code
A play is repeatable GTM work, written as code. You describe the job to your
agent once, it builds the play in your repo, and Deepline keeps the runs and
versions that follow.
The important part is not the slogan. Code gives GTM work the same properties
as the rest of your product: it can be changed, reviewed, tested on a small
batch, rerun, and improved without rebuilding a canvas.
The broader idea is captured in [this post by Guillermo Rauch](https://x.com/rauchg/status/2079274102129304026).
Use a play when the work is worth doing again: enrich a list, research target
accounts, find the right people, clean CRM data, or route a new signal.
## Why this is better than a workflow builder
Most workflow builders ask you to draw a diagram, choose nodes, wire fields,
and keep the canvas in sync with the work you actually do. A play starts with
the outcome instead.
The play lives alongside the rest of your code, so Claude Code or Codex can
read it, change it, test it on a few rows, and improve it as your process
changes. You can use your normal code review and version control. You do not
need to rebuild the workflow in a separate visual editor.
Ask for the job in plain language:
```text Claude Code theme={null}
/deepline-gtm Build a play that takes a CSV of company domains, finds the VP of Sales at each company, and returns verified work emails. Start with 3 rows.
```
```text Codex theme={null}
$deepline-gtm Build a play that takes a CSV of company domains, finds the VP of Sales at each company, and returns verified work emails. Start with 3 rows.
```
The `deepline-gtm` skill gives your agent the Deepline contracts it needs to
write and run the play. You describe the outcome. The agent handles the code.
## Build it once, then keep improving it
Start with the smallest useful version. Run it on a few rows. Ask your agent
to change the logic when you learn what the result needs.
```text theme={null}
/deepline-gtm Update the company-prospecting play: only return companies with 50–500 employees, add the reason each company matched, then test it with 5 rows.
```
The play file is the current draft. Publishing creates a named version that
other people, schedules, and agents can run. Editing the file later does not
quietly replace the published version.
```bash theme={null}
# Your agent can run these for you. They are useful when you are in the terminal.
deepline plays check company-prospecting.play.ts
deepline plays run --file company-prospecting.play.ts \
--input '{"domains":["acme.com","example.com"]}' --watch
deepline plays publish company-prospecting.play.ts
```
## Run the same work again
Once published, a play has a stable name. Run it again when you have a new
list, a new date range, or a new batch of accounts.
```bash theme={null}
deepline plays run --name company-prospecting \
--input '{"domains":["acme.com","example.com"]}' --watch
```
Or ask your agent:
```text theme={null}
/deepline-gtm Run the published company-prospecting play for these 20 domains. Show me the companies that matched and the verified emails.
```
Each run is recorded. You can open a run in Deepline to see what happened,
which version ran, the tables it created, and the result it returned. That
history stays attached to the play, so a later edit does not erase the evidence
behind an earlier decision.
```bash theme={null}
deepline runs list --play company-prospecting
deepline runs get --json
deepline runs export --dataset result.rows --out companies.csv
```
## Make it automatic when the manual run is right
Do the work manually until the output is useful. Then ask your agent to attach
the right trigger.
| When it should run | Ask your agent |
| --------------------------- | ----------------------------------------------------------- |
| Every weekday | “Add a weekday 9 AM schedule to this play.” |
| When another system changes | “Add a webhook trigger and show me the payload.” |
| When a new signal appears | “Run this play when a monitor finds a VP Sales job change.” |
For example:
```text theme={null}
/deepline-gtm When a monitor finds a VP Sales job change, run the published account-router play with the changed person and company. Keep the manual run path too.
```
The trigger starts the same published play you tested. It does not create a
second workflow that can drift from the original.
## What Deepline keeps
* **Drafts** are changes still being worked on.
* **Published versions** are the versions other people and automations run.
* **Runs** show the inputs, outputs, tables, and status for each execution.
* **Archived plays** leave the active list without deleting the history.
This gives you a durable record of what changed, what ran, and what it
produced. Re-run an older version when you need to compare a change or explain
an earlier result.
## Where to go next
Give your agent a maintained starting point, then adapt it to your process.
Learn the TypeScript surface when you need to work directly in a play file.
Start a published play from time or an external event.
Watch for a signal, then route it into a play.