Workflows

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.

Writing the prompt

The prompt is a standing instruction, not a one-off question. 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, not assume. Agents are told to gather context with tools and to stop with a clear error rather than guess. 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.

Persisting work between runs

Each workflow has its own persistent workspace at ~/workspace, backed by durable storage and scoped to that workflow. Files written there are available to every subsequent run — useful for state an agent needs to carry forward, like "the last issue number I processed."

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

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, cron, webhook, and integration events.
• Runs and outputs — statuses, transcripts, output formats, and cancellation.