Skip to main content

​
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. 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:
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.
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.

​
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.
Or ask your agent:
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.

​
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. For example:
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

Start from a template

Give your agent a maintained starting point, then adapt it to your process.

Read the SDK reference

Learn the TypeScript surface when you need to work directly in a play file.

Add a schedule or webhook

Start a published play from time or an external event.

Create a monitor

Watch for a signal, then route it into a play.