Automation
Deterministic GTM workflows with runs you can read
An automation nobody can inspect is a liability. A workflow here is a versioned graph with a durable run: every node, attempt, retry, approval, and cost is stored where you can open it.
The visual automation tools taught everyone the shape and left them owning the plumbing: a server to keep alive, credentials pasted into nodes, and a graph that is one screenshot away from being the documentation. A workflow here is a versioned definition inside your own workspace, fired by API call, webhook, cron, or an internal event.
Execution is durable, not hopeful. Nodes cover tools, set, filter, switch, loop, merge, wait, typed code, and an approval that parks the run until a person decides. Three modes matter: smoke test writes nothing, dry run reports what a live pass would do and what it would cost, and live is the only one that reaches outside.
Example searches
Ask for it the way you'd say it
Every search below runs on the same hosted Tables, with the cost previewed before anything is spent.
Trigger on new rows
when a row lands in my inbound table, enrich it and enroll the ones that clear our bar
The run shows each node, its inputs, its outputs, and where a row branched away, so a surprise has an address.
Rehearse before it spends
run the whole thing without calling any provider so i can see the shape first
Smoke test writes nothing and spends nothing; dry run reports what a live pass would do and what it would cost.
Pause for a human midway
hold this before anything gets sent and let me approve the list first
An approval node parks the durable run until someone decides, and the run resumes from exactly where it stopped.
Plays
Three motions you can run this week
Each one is a chain of Oxygen primitives — the same hosted objects your workspace already has, composed.
Automate the boring half of sourcing
New accounts get enriched, scored, and routed without anyone opening the table that morning.
- 1Author the graph locally, lint it, and apply it as a draft revision first.
- 2Run it in dry mode against real rows, then publish and arm the trigger with a ceiling.
oxygen workflows applyMake one motion callable
A finished automation becomes a capability any MCP client or teammate can invoke by name.
- 1Publish the workflow and opt it in to tool exposure so clients can discover it.
- 2Call it with typed inputs and read the run it produced, not a chat transcript.
oxygen workflows callWatch a run instead of guessing
A failing automation explains itself with the node, the attempt, and the provider error behind it.
- 1Tail the run until it finishes or parks in waiting or awaiting approval.
- 2Open the failures view to retry the specific step rather than the whole graph.
oxygen workflows tail
Capabilities
What you get
A graph that is the truth
Nodes and edges are declarative data, so what you read back is what the worker executes. There is no generated source hiding the actual configuration from you.
Three modes before live
Smoke test proves the wiring, dry run prices the pass, live is the only mode that crosses outward. Rehearsing costs nothing and is the normal way to start.
Approvals inside the run
A run can park on an approval node and wait, sometimes for days, then continue from the same checkpoint. Human judgment becomes a step rather than an interruption.
Durable, leased execution
Runs live in Postgres with retries, attempt history, and leases, so a restart resumes instead of losing work. Nothing depends on a process staying alive overnight.
Boundaries
What Workflows does not own
Workflows own deterministic graphs. A goal you cannot write as steps belongs to Agents, which call workflows as child actions. Cadence, enrollment, and suppression stay in Sequences, and a simple row dependency is a chained Tables column, not a graph.
Data sources
What the data actually comes from
Every value lands with its provider and cost recorded on the cell.

Firecrawl
Site scraping and page extraction as a tool node, which is where a lot of enrichment graphs actually begin.

Serper
Search, maps, and places results for the node that has to find something before the graph can act.

Exa
Neural search for grounding an AI step inside a run rather than trusting a model's memory of the web.
- Pa
Parallel
Deep research for the branch where one careful answer beats ten shallow ones.

Apify
Actor-based scraping for public sources that need a purpose-built collector instead of a generic fetch.
Run these on Oxygen's managed credits, or connect your own provider keys and pay the vendor directly — the same columns, the same runs, the same provenance either way. See every integration.
Limits
Where this stops
- A workflow can schedule, request, and prepare, but it cannot approve on your behalf. Publishing and external sends keep their human gate, which does bound how unattended a pipeline can honestly be.
- Loops are clamped and typed code runs in an isolated sandbox with no network, credentials, or workspace scope. That is deliberate, and it means a graph is not a general-purpose server.
FAQ
Questions people ask first
How is this different from a self-hosted automation tool?
What do the three execution modes do?
Can a workflow spend money on its own?
Can other tools call my workflow?
What happens when a step fails?
Do workflows cost credits?
Run deterministic gtm workflows with runs you can read on your own workspace
Sign up, get a working workspace with a one-time credit grant, and run the first play from the web app, the CLI, or your AI assistant over MCP.