OXYGENOXYGEN

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

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.

    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. 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. 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. 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?
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 inside a ceiling you approved. A cron, webhook, or event trigger stores a per-delivery credit cap as bounded standing permission, and a trigger armed without one falls back to a plan-tier default rather than running open-ended.
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 anything. Triggers, filters, switches, loops, merges, waits, set steps, and typed code are platform control flow and bill nothing, so graph shape is never a pricing decision.

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.