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, one that survives a restart: every node, attempt, retry, approval, and cost is stored where you can open it.

try
Start freeRead the docs

Self-hosted automation tools taught everyone the shape and left them owning the plumbing: a server to keep alive, credentials to guard, 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 and dry run stub every paid call and spend nothing, live is the only one that writes outside, and a preview prices the live pass.

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

    Both rehearsal modes spend nothing and stub every paid call; a preview shows what a live pass would touch and the least it costs.

  • 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. 2List failed runs, then retry one from its first failed step: completed steps are kept, so nothing replays from the top.
    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 and dry run prove the wiring for free, and live is the only mode that spends or writes outside. A preview shows the least a live pass costs before you approve it.

  • 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

    On your own Parallel key, web search and page extraction for a node that needs a second view of the web.

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 or guarding its credential store: connections live in the workspace, 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 and dry run behave the same: real workspace reads, paid provider calls stubbed, no outside writes, no credits. Live is the only mode that spends or writes outside. A preview shows what a live run would do and the least it costs.
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 ends in a failed state with a timeline you can read, and you retry it from the failed 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.

Try Workflows in 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