Automations

An Automation is a series of tasks (tasks) executed sequentially. Each task is either a deterministic command (such as execute_sql, which runs a named SQL query) or an agent given a prompt. Tasks compose by passing results from one to the input of another — the output of each task is accessible with Jinja as {{ name_of_task }}. You build, run, and replay Automations from the Oxygen IDE. Each Automation is stored as an .automation.yml file (the older .procedure.yml extension is still recognized for back-compat).

Automation components

Automations are DAGs comprised of tasks. Each task has a few common properties:

Component	Description	Type
name	Identifier for the task. Output of the task can be referenced as `{{name}}`.	required
type	The tool to use for this task. See Task types.	required

Specific task types have additional property requirements — see Task types for the full set.

A complete example

workflows/monthly_report.automation.yml

tasks:
  - name: raw_sql_calculation
    type: execute_sql
    sql_file: month_over_month_overall_performance.sql # A sql file to execute deterministically
  - name: month_over_month_metrics # An identifier for the task. Results can be referenced by jinja-wrapping this name
    type: agent
    agent_ref: default # The agent .yml file to use for this task
    prompt: Calculate month-over-month performance of views and clicks for the entire ad portfolio. # The prompt given to the agent
  - name: monthly_report
    type: agent
    agent_ref: local
    prompt: |
      Create a report using the provided data that looks as follows:
      The overall portfolio brought in X views and Y clicks in MM/YYYY, up A% and B%, respectively.
      {{month_over_month_metrics}}

Automations vs. chains

An Automation is similar to a “chain” in the prompt-engineering parlance, but with a few key differences:

Automations are DAGs. Whereas chains can become arbitrarily complex with arbitrarily nested loops, complex reply logic, and opaque branching structures, Automations are DAGs, which enforce a clearer, more predictable flow from input to output.
Automations separate logic from execution. Because Automations are written in YAML, the DAG definition is entirely separate from the execution engine, while other code-based systems keep these tightly coupled and so ultimately become difficult to build and maintain.

These choices generally reduce the flexibility of Oxygen when compared to say, langchain or llama_index, but they also dramatically reduce the complexity of the system. You can think of Oxygen’s Automation paradigm as a domain-specific chain-builder for data workflows, where most (if not all) tasks simply pass results around between different agents.

Next steps

Task types

agent, execute_sql, formatter, and sub-automations

Loops

Iterate over values with loop_sequential

Variables

Parameterize an Automation with typed inputs

Get started

Data Infrastructure

World Model

Agentic Intelligence

SDK

Automations

Data Apps

Integrations

Edge fleet

Manage

Workspaces

Authentication

Observability

Enterprise

Reference

REST API

Resources

Troubleshooting

Automations

Automation components

A complete example

Automations vs. chains

Next steps

Task types

Loops

Variables

​Automation components

​A complete example

​Automations vs. chains

​Next steps

Task types

Loops

Variables

Automation components

A complete example

Automations vs. chains

Next steps