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.

try
Start freeRead the docs

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 someone decides. A run has 3 modes. 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

Each example is a request in plain words, with what it returns underneath.

  • 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.

    1. Signals
    2. Workflows
    3. Tables
    4. Sequences
    1. 1Author the graph locally, lint it, and apply it as a draft revision first.
    2. 2Run it in dry mode against real rows, then publish and arm the trigger with a ceiling.
    oxygen workflows apply

  • Make one motion callable

    A finished automation becomes a capability any MCP client or teammate can invoke by name.

    1. Workflows
    2. Tables
    3. Observability
    1. 1Publish the workflow and opt it in to tool exposure so clients can discover it.
    2. 2Call it with typed inputs and read the run it produced, not a chat transcript.
    oxygen workflows call

  • Watch a run instead of guessing

    A failing automation explains itself with the node, the attempt, and the provider error behind it.

    1. Workflows
    2. Observability
    3. Dashboards
    1. 1Tail the run until it finishes or parks in waiting or awaiting approval.
    2. 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. A decision 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

Data sources and CRM connections

  • 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.

Use managed credits where available, or connect a supported provider key on an eligible paid plan. Your provider bills its calls; OXYGEN adds a per-call platform fee. Signed-in CRM connections such as HubSpot have no per-call fee. Connected sending accounts reserve monthly credits. See pricing and supported integrations.

Limits

Where this stops

  • Arming a cron, webhook, or event trigger that calls tools needs an approval for that exact revision, and each new revision needs another.
  • 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?
You are not running the server, the credentials sit in the workspace rather than in nodes, and the run is durable state you can query later. The graph is also data, so exporting and reading it gives you what actually executes.
What do the three execution modes do?
Smoke test exercises the wiring and writes nothing anywhere. Dry run reports what a live pass would do and what it would cost without calling a provider. Live is the only mode that touches the outside world.
Can a workflow spend money on its own?
Only through a trigger you armed. A cron, webhook, or event trigger stores a per-delivery credit cap as bounded standing permission, and one armed without a cap takes your plan's default. On a plan without a default, set the cap yourself; your balance and any budget still bound every delivery.
Can other tools call my workflow?
Yes. A published workflow can be opted in to tool exposure, which makes it callable by name from an MCP client with typed inputs. A motion you built once becomes a capability your agent can use.
What happens when a step fails?
The attempt is recorded with its error and retried within the step's budget. A run that exhausts retries parks in a failed state with a timeline you can read, and you retry the specific step rather than replaying everything.
Do workflows cost credits?
Only the tool nodes draw credits, each time one runs: a small step fee plus the tool's own price. Triggers, filters, switches, loops, merges, waits, set steps, and typed code bill nothing. A tool node inside a loop bills on every pass, and a retried step bills again.

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.

Start freeSee pricing