Agents
An agent is a reusable, named set of instructions that Co-Scientist runs on your behalf in a Seqera Platform workspace. A Co-Scientist conversation is interactive and starts empty each time. An agent captures a task you repeat, such as investigating failed runs or summarizing results. Anyone in the workspace can then run it without rewriting the prompt.
Agents are workspace-scoped. Every agent in a workspace is visible to everyone with permission to read agents, not only the person who created it. An agent acts as the service account bound to it rather than as the person who starts it. It reaches private repositories through a GitHub App credential in its workspace.
Enable agents
Agents are available from Seqera Platform Enterprise 26.2. Once TOWER_AGENT_BACKEND_URL is set, they are enabled in every organization unless an administrator restricts them.
| Environment variable | Effect |
|---|---|
TOWER_AGENT_BACKEND_URL | Origin of the Co-Scientist agent backend. While it is empty, agents are off in every organization, whatever the allow-list says. The Platform Helm chart sets it when the agent-backend subchart is enabled. Chart 1.0.4 enables that subchart by default. Set it by hand only if you deploy some other way. See Co-Scientist configuration. |
TOWER_AGENT_CONFIGURATION_ALLOWED_ORGANIZATIONS | Which organizations have agents. Leave it unset, or set it empty, to enable agents in every organization. Set it to a comma-separated list of organization IDs to enable them for those organizations only. |
Agents are organization-scoped. They are never available in a personal workspace, whatever the allow-list says.
The allow-list controls the Agents pages, the Trigger agent button, Actions that target an agent, and the agents API. In an organization where agents are off, the /agents endpoints return 404.
The same variables govern service accounts. Enabling agents for an organization also enables service accounts for it. With service accounts enabled, you can configure an agent's identity.
GitHub App credentials need no configuration in Enterprise. They are available in every workspace.
Agents, chat, and coding agents
Seqera uses "agent" for three things:
- Agents — reusable instruction sets you create in a workspace and run against your pipelines, described here.
- Co-Scientist chat — the interactive assistant panel in Seqera Platform.
- Coding agents — third-party tools such as Claude Code or Codex, which you connect to Seqera through a skill.
Agents are also unrelated to Tower Agent, the component that connects Seqera Platform to an HPC cluster.
Agents compared with Co-Scientist chat
Agents and Co-Scientist chat are the same assistant reached two ways. Both work inside a Seqera Platform workspace and can read your runs and act on them. They differ in who they act as, who sees them, and what starts them.
| Agent | Co-Scientist chat | |
|---|---|---|
| Where it runs | In the background, once started | In the Co-Scientist panel in Seqera Platform, while you watch |
| Instructions | Written once and saved, reused on every run | Written fresh in each conversation |
| Acts as | The service account bound to the agent | You, with your own permissions |
| Who sees it | Everyone in the workspace who can read agents | Only you, in your own session |
| What starts it | You, from a run | You, by typing in the panel |
Permissions
Two things control agents. Workspace grants decide who can see and manage them, and the bound service account decides what an agent can do when it runs.
Who can manage agents
Four workspace grants control access to agents:
| Grant | Allows |
|---|---|
Agent_Read | View and search the workspace's agents |
Agent_Write | Create and edit agents, and pause or resume them |
Agent_Execute | Run an agent |
Agent_Delete | Remove an agent |
Agents appears in the navigation only for users with Agent_Read.
Agent identity and permissions
An agent acts as a service account, not as the person who starts it. Binding one is required. Select it under Agent permissions when you create or edit the agent. Every run of that agent then uses that account's roles. Whoever runs it, the agent can only reach what the service account is allowed to reach.
- Only service accounts assigned to the agent's workspace can be bound. An account with no role in the workspace cannot act there.
- You cannot bind a service account that holds permissions you do not hold in the workspace yourself.
- Service accounts belong to the organization. If none is assigned to your workspace, ask an organization owner to create one and assign it before you create the agent.
- If the bound service account is later removed from the workspace or deleted from the organization, Seqera Platform pauses the agent. It shows as Inactive and drops out of Trigger agent. Adding the service account back does not resume the agent. Select Resume on the Agents page. When the person removing the service account is not a participant in the agent's workspace, the agent stays active, and Seqera Platform refuses its next launch instead.
- If the bound service account is disabled, the agent's runs fail rather than fall back to the permissions of whoever started them.
Scope the service account to what the agent's instructions need. Every run of the agent carries those permissions, started by anyone in the workspace with Agent_Execute.
If you do not see an Agent permissions section on the agent form, agents are not enabled for your organization. See Enable agents.
Access to private Git repositories
An agent reaches a private repository only through a GitHub App credential. No other Git credential type works for an agent. A personal access token does not, even though it works elsewhere in Seqera Platform.
Bind the credential to the agent under Agent permissions, alongside the service account. The credential is optional. An agent without one still runs, but cannot clone, commit, or push. With one bound, the agent can do all three, as that credential.
Two things have to be in place before you can bind it:
- A GitHub organization admin installs the GitHub App in the GitHub organization and grants it access to the repositories the agent needs.
- The credential exists in the workspace the agent runs in. Credentials are workspace-scoped. An agent cannot use one from another workspace or from someone's personal credentials.
If a bound credential is later removed from the workspace or marked invalid, the agent form warns you and blocks saving until you select a different credential or clear it with None.
Create an agent
- In your workspace, select AI > Agents.
- Select Add. If the workspace has no agents yet, select Add agent instead.
- Choose a starting point:
- Fix failed runs, Summarize successful runs, or Summarize failed runs — a template that prefills the name, description, and instructions.
- New agent — write your own instructions.
- Complete the details:
- Name (required). Letters, numbers, dashes, and underscores only.
- Description (optional).
- Agent instructions (required). What the agent should do when it runs.
- Under Agent permissions:
- Service account (required). The identity the agent runs as. Only accounts assigned to this workspace are listed. See Agent identity and permissions.
- GitHub App credential (optional). Needed only if the agent works with private Git repositories. See Access to private Git repositories.
- Save the agent.
Templates prefill text only. They do not set a trigger, a schedule, or anything about where the agent runs. Review and edit the instructions before saving.
Manage agents
The Agents page lists every agent in the workspace that you can read, with its status. From there you can:
- Search for an agent by name.
- Edit an agent's name, description, instructions, service account, and GitHub App credential. The template picker is not shown when editing.
- Pause an agent to keep its definition but stop it being selectable, and Resume it later. A paused agent shows as Inactive.
- Remove an agent. Seqera Platform asks you to confirm.
Paused and removed agents do not appear when selecting an agent to run. Removing an agent does not delete the sessions it already produced.
Run an agent
You start an agent from a run, so it works with that run's context. Running one needs Agent_Read and Agent_Execute, and access to Co-Scientist chat. Chat access requires the panel to be enabled for your organization and the chat:execute permission. Without chat, Trigger agent does not appear.
- Open the run, or find it in a project's Runs tab.
- Select Trigger agent.
- Choose an agent from the list. Search by name if the workspace has many.
The agent's session opens in the Co-Scientist panel, where you can follow what it does. Agent sessions are read-only. To continue the conversation, select Fork conversation, which copies the session into a chat of your own and opens it.
Only active agents appear in the list. If the workspace has none, the list offers Add agent to users with Agent_Write.
What an agent does not define
An agent holds a name, a description, its instructions, and the service account it acts as. It does not carry a trigger, a schedule, a compute environment, or a sandbox configuration. Those are properties of how the agent is run, not of the agent itself.
Learn more
- Co-Scientist in Seqera Platform: The Co-Scientist panel in Seqera Platform
- Coding agents: Connect Claude Code, Codex, and other agents to Seqera
- Create and manage service accounts: The identities agents run as
- Git integration: Connect Seqera to public and private Git repositories
- Usage and cost: Co-Scientist usage and cost