HELIOS DOCS

Workflows

A Helios workflow is an agent prompt attached to one or more triggers. Describe the task in plain English and choose when it should run.

A workflow is an agent you've put on a task permanently. It has two essential parts:

  1. A prompt - the task, written in plain English.
  2. One or more triggers - when the agent should pick it up.

That's the whole model. Each time a trigger fires, Helios starts an agent in a fresh sandbox, hands it your prompt and the trigger's payload, and records the result as a run.

Creating a workflow

Workflows live inside a project. From your project, choose Create Workflow, give it a name, and write the prompt.

A workflow won't run until it has a prompt. Triggering an empty workflow returns an error.

Writing the prompt

The prompt is a standing instruction. It runs every time the trigger fires. Two things make a large difference:

Be explicit about when to act. The agent runs unattended and sees the trigger payload alongside your prompt. Tell it what to do when the event doesn't apply.

When a pull request is opened in acme/api:

- If it only touches files under docs/, add the "documentation" label and stop.
- Otherwise, review the diff for changes to authentication or billing code.
  If you find any, comment on the PR listing the specific files and why they
  need a second reviewer.
- If nothing is risky, do nothing. Don't comment.

Ask it to verify first. Agents are told to gather context with tools and to stop with a clear error when the context is unclear. Prompts that say "check the current state of X before deciding" get better results than prompts that assume state.

What the agent can reach

Every workflow run has the full agent toolkit: a shell and filesystem, code execution, web search and scraping, your connected integrations, your databases, and any MCP servers attached to the project.

Two things are configured per workflow:

  • Integration resources - pin specific GitHub repositories so the agent has authenticated access to them and knows which repo "the repo" means.
  • Variables - variables visible to the workflow's project are passed into every run as context the agent may use.

Each workflow has a model setting. The default is Helios's frontier agent model.

Carrying work between runs

Each run starts in a fresh sandbox. Files the agent should read on every run belong in the Library, which Helios mounts under ~/context. An agent can propose edits to those files. A person approves or discards each one, and only approved files are there for the next run.

Anything written outside ~/context (for example under $TMPDIR) disappears when the run ends. See context.

Running a workflow by hand

Any workflow can be dispatched manually, whatever triggers it has. Manual runs can carry an arbitrary JSON input payload, which the agent receives as trigger context - handy for testing a prompt before you attach a schedule to it.

Next

  • Triggers - manual, schedule, webhook, and integration events.
  • Runs and outputs - statuses, transcripts, output formats, and cancellation.

Last updated on