Skip to Content
Helix AutomationsBuilding an Automation

Building an Automation

There are two ways to create a Helix. Both produce the same thing — a pipeline of steps you can edit, test, and run — so pick whichever fits how you’re thinking.

Two ways to build

Describe your intent

Tell Helix what you want in plain language:

“When a rental application comes in, screen the applicant, draft a reply, get a manager to approve it, then send it.”

Helix proposes a complete pipeline — the steps, their order, and how they connect — that you can accept as-is, edit, or refine. This is the fastest way to get a working first draft, and a good starting point even if you plan to customize heavily.

Guided build editor

Prefer to assemble the pipeline yourself? The build editor gives you a visual canvas where you add steps one at a time, connect them, and configure each one. Every step has an inspector panel where you set its inputs, dependencies, and options. Use this when you want precise control, or to fine-tune an automation that started as a described intent.

You can move freely between the two — describe an intent to scaffold the pipeline, then open the editor to adjust it. Under the hood, Helix records how each automation originated (from chat, hand-declared, AI-proposed, built in the editor, or imported), so you can always tell whether something was authored by a person or drafted by AI.

Goal and definition of done

Every Helix starts with a goal: a plain-language description of what it’s for, plus what a successful run has to actually produce. The goal has three parts:

  • Deliverables — what a successful run must produce.
  • Must-pass checks — hard pass/fail conditions a run has to satisfy.
  • Constraints — things a run must never do.

This isn’t just documentation — after every run, Helix judges the run’s real evidence (what steps actually ran, what they actually produced) against these criteria and returns a pass/fail verdict with its reasoning. Write your deliverables and must-pass checks as specifically as you’d explain “done” to a new hire: vague acceptance criteria produce a vague verdict.

Steps, dependencies, and the pipeline

An automation is a pipeline of steps connected by dependencies rather than a rigid top-to-bottom line — see Step Types for the five kinds of step and everything you can configure on each one.

  • Steps are the units of work. Each has a kind, an intent, and its own configuration.
  • Dependencies define order, not just sequence. A step runs only once every step it depends on has succeeded; steps that don’t share a dependency run in parallel automatically.
  • A failed dependency skips its dependents. If a step a later step depends on permanently fails, that later step is correctly skipped rather than running on incomplete data — a failure doesn’t silently propagate bad results forward.
  • Data flows forward. A step’s result is available to the steps that depend on it, so you can pass a screening score into a decision, or an extracted field into a drafted reply.

Because steps are connected by dependencies rather than a rigid line, your automation can fan out, branch, and rejoin — a condition on a step can send the run down one path or another, and an agent step’s loop can repeat work over a list.

Auto vs. manual execution. Every automation runs in one of two modes: auto lets steps start as soon as their dependencies are satisfied, so independent branches run concurrently and the pipeline moves as fast as its dependency graph allows. Manual is stricter and more sequential. Auto is the right default for most automations; reach for manual when you need tighter, one-at-a-time control over ordering.

A worked example

A simple applicant-intake automation might look like this:

Stimulus: webhook — application submitted
   │
   ▼
1. extract-details      (agent)   → pull applicant fields from the submission
   │
   ▼
2. screen                (action)  → run a background/credit check via a connector
   │
   ├── qualified == true  ─▶ 3. draft-welcome   (agent)
   │                              │
   │                              ▼
   │                         4. send-welcome     (action, hitl: true)  → a manager signs off
   │
   └── qualified == false ─▶ 5. draft-decline    (agent)
                                  │
                                  ▼
                             6. send-decline      (action)

Each step passes its result to the next: the screening outcome (steps.screen.data.qualified) is what steps 3 and 5’s conditions check, and only an approved welcome reply — gated by hitl: true on step 4 — actually goes out.

Next: Step Types · Triggers · Controls & Policy

Last updated on
OverviewStep Types