Key concepts
Agents, chats, workflows, triggers, runs, sandboxes, integrations, projects, and roles - what each term means in Helios.
Agent
An AI model working a task inside its own sandbox, with access to a shell, a filesystem, code execution, the web, your integrations, your databases, and any attached MCP servers.
There is one agent runtime. You reach it through chat or through a workflow.
Chat
An interactive session with an agent. Attach files, pin a repository, fork the conversation, share a read-only transcript. See chat.
Workflow
An agent put on a task permanently: a prompt plus one or more triggers. There is nothing to wire up - the prompt is the task. See workflows.
Trigger
What causes a workflow to run. Four types:
| Type | Fires when |
|---|---|
| Manual | You dispatch it, optionally with an input payload. |
| Schedule | A cron expression matches. Schedules run in UTC. |
| Webhook | A signed HTTP request arrives at the trigger's URL. |
| Integration | An event arrives from GitHub, Slack, or Plain. |
See triggers.
Run
One execution of a workflow. A run records the trigger context, the agent's full transcript, the
result, and a status: queued, running, succeeded, failed, pending_cancel, or cancelled.
See runs and outputs.
Sandbox
The isolated cloud computer an agent runs in. Its filesystem is discarded when the run ends. Shared
files come from the Library, mounted under ~/context. Outbound network access is closed by default and opened per host, with
credentials injected at the network layer so the agent never holds them. See
sandboxes.
Integration
An external service connected to Helios. The credential behind it is stored server-side and never reaches the agent. Helios indexes the service's entire API, and agents search that index and call whatever endpoint the task needs - not a curated list of actions. See integrations.
Integration resource
A specific object inside an integration, pinned to a chat or workflow. GitHub repositories can be pinned. Pinning both disambiguates ("the repo") and grants scoped, credential-free access. See integration resources.
Project
The container for related workflows, chats, integrations, variables, and secrets - and the unit of access control. Resources inherit access from their project. Everyone gets a Personal project. See projects and sharing.
Roles
Two layers. Your organization role is admin, member, or viewer, and says what you can
create. Your resource role on a given project or workflow is viewer, operator, editor, or
admin, and comes from a grant. A grant can name a person, a group, a service account, or everyone
in the organization. See roles and permissions.
Group
A named set of people and service accounts. Grant a role to the group once and every member gets it.
Service account
The identity a workflow runs as. Every project has a default service account, and you can create named ones. A service account holds resource roles like a person does, and can be disabled.
Environment
The image a sandbox starts from. Helios ships a default environment. You can build your own from a Dockerfile, with versions and build logs.
Library
The shared file store. It has organization, project, and personal trees, mounted into every sandbox. Agents propose changes to it. People review and approve them. See the Library.
Visibility
Whether a resource is restricted (explicit grants only) or organization (everyone gets a role). Managed for projects and integrations. Workflows inherit from their project.
Variables and secrets
Variables are plaintext configuration, passed into every run as context. Secrets are envelope-encrypted, write-only, and never enter an agent's context. Both are scoped at the organization, project, user, or workflow level, with the most specific level winning. See variables and secrets.
Credits
Usage is metered in Helios credits, derived from actual model spend. See pricing.
MCP
The Model Context Protocol. Attach external MCP servers to give your agents more tools; or drive Helios itself over MCP from your own agent. See MCP servers.
Last updated on