Workflows
Put an agent on the task permanently.
A workflow is a prompt and a trigger. Describe the task once and the agent runs it forever — on a schedule, on a signed webhook, or the moment something happens in GitHub, Slack, or Plain.
When a pull request is labeled `needs-review`, read the diff, check it against our conventions, and leave a review. Escalate to #eng-leads if it touches billing.
- github·fetch diff for PR #2841
- github·read CONTRIBUTING.md at head
- code·analyze changed paths
- github·post review · 3 inline comments
- slack·notify #eng-leads
Review posted · run succeeded
- Flagged an unhandled error path in sync.ts:142
- Touches billing — escalated to #eng-leads
- Output: markdown · 41s · full trace kept
Definition
Three things make a workflow.
Describe the task in plain English, give it the context it needs, and say when it should happen.
A prompt
The task, written in plain English. Name the tools it should reach for, the judgment calls it should make, and the shape of the answer you want back.
Context
Pin the GitHub repositories the task should carry, and give it variables and secrets — encrypted, and reusable across every workflow you run.
A trigger
When the task should happen: on demand, on a schedule, on a signed webhook, or on an event from a tool your team already uses.
Triggers
Four ways a task starts.
Pick the one that matches how the work actually arrives.
Manual
Run it yourself, whenever. The way you test a task before you trust it to a schedule.
Cron
Write the schedule the way you would say it — "every weekday at 8am, New York time" — and Helios turns it into a cron expression for you.
Webhook
Call the workflow from your own systems. Every request is signature-verified with a shared secret you can rotate on demand.
Integration events
React the moment something happens in GitHub, Slack, or Plain — with filters so only the events you care about wake the agent.
Integration events
React to what happens in your tools.
Filters run before the agent does. Match on a repository, a label, a branch, or a channel, and only the events that pass wake a run.
GitHub
Pull requests opened, closed, synchronized, or labeled. Issues opened, closed, or labeled. Pushes, tags, releases, comments, and finished Actions runs. Filter by repository, branch, or label.
Slack
Messages in a public or private channel, filtered to the channel you name — so an agent watches #support and nothing else.
Plain
A thread is created or a customer replies, so an agent can triage the conversation before anyone opens the queue.
Runs
Every run leaves a record.
See what fired the task, which tools the agent reached for, what it produced, and how long it took.
A run moves from queued to running, then lands as succeeded, failed, or cancelled. Open any run to replay the trigger payload and the steps the agent took to get to its answer. Results come back typed — as markdown, plain text, or JSON — so whatever reads the output next knows what it is holding.
Every night, check yesterday's failed CI runs and file an issue for anything that failed twice.
- github·list workflow_runs · conclusion=failure
- code·group by job · find repeats
- github·open issue · label=flaky
Run succeeded · 1m 12s
- 2 repeat failures · 1 issue filed, 1 already open
- Output: json · handed to the on-call dashboard
Keep going
Tasks teams already hand off
Use case
PR review & digest
An agent reviews every pull request as it opens and digests the week for the people who missed it.
Integration
GitHub
The full GitHub API plus the event catalog that wakes an agent the moment a PR lands.
MCP
Extend the toolbox
Attach an MCP server and your workflows gain tools of your own — your internal services, your vendor's server.
Describe the task once.
Start free, write the prompt, pick the trigger, and let the agent hold the task from here.