Today at the Nextflow Summit, we announced Co-Scientist Agents: reusable instructions that Seqera Co-Scientist runs on your behalf. Agents turn the tasks your team repeats, like debugging failed runs or reading QC reports, into work that runs automatically or at the click of a button, always within the permissions you set. In this blog post, we cover what Co-Scientist Agents are, what they mean for your team, and three example use cases.
From One-off Prompts to Repeatable Work
Bioinformatics is moving toward a factory model where samples, events, and signals trigger context-aware agents that act automatically on your behalf. Seqera Platform is the contextual engine behind that factory. It holds the context and the rules, and three kinds of actors work within them: scientists working hands-on, agents, and deterministic pipeline execution. The science still needs experts, but much of the work around it is repetitive: checking why a run failed, reading through a report, summarizing what came out the other end.
Most AI tools start every conversation from scratch. Seqera Co-Scientist has answered more than half a million questions, and the clearest lesson from all of them is that context is king. Seqera Co-Scientist starts with full context: pipelines, runs, code, compute and data. Working alongside you in Seqera Platform, Co-Scientist responds to your prompts and reasons through problems with you, from generating and debugging pipelines to interpreting results. You get contextual agent help the moment you need it. But in a conversation, you still have to prompt for the task each time. For the tasks your team repeats every week, like investigating failed runs or interpreting reports, that means writing the same instructions again and again. That's where Co-Scientist Agents come in.
Introducing Co-Scientist Agents
Co-Scientist Agents are available now in the latest Seqera Platform release.
An agent is a reusable, named set of instructions that Co-Scientist runs on your behalf in your Seqera Platform workspace. Where a conversation is something you drive interactively, an agent captures a task you repeat, so anyone in the workspace can run it without rewriting the prompt. Agents come with a few key properties:
| Key Capability | Description |
|---|---|
| Shared across the workspace | Every agent is visible to everyone with permission to read agents, not only the person who created it. One well-written agent becomes a tool for the whole team. |
| Their own identity | An agent acts as the Service Account bound to it, rather than as the person who starts it. That means you decide exactly what an agent can access, independently of who runs it, and every action is attributable to the agent. |
| Access to private code | Agents reach private repositories through a GitHub App credential in their workspace. |
| Run manually or automatically | Start an agent with the Trigger agent button, point an Action at it, or call it through the agents API. Actions can wake an agent when a pipeline run finishes, on a schedule, when a file lands in cloud storage, and more. |
What this means for your team
- →Write it once, use it everywhere. The best way to investigate a failed run or read a QC report usually lives in one person's head. Capture it as an agent and the whole workspace gets the same approach, every time, without anyone rewriting the prompt.
- →Less time on routine checks. Teams spend hours manually reviewing failures and outputs. Agents take on that repetitive work so scientists and pipeline developers can focus on the science and on building new capabilities.
- →Respond to the events your stack already emits. Agents can wake up when a run fails or succeeds, on a cron schedule, or when new data arrives in object storage. Picture a nightly agent that reviews every failed run from the past day, alongside Actions that launch a pipeline the moment a new sample lands.
- →Automation you can govern. Because an agent acts as its own Service Account, admins control exactly what it can reach. It doesn't inherit the permissions of whoever happens to start it, and what it does is attributable to the agent itself, giving you a clear audit trail for sensitive operations. Every agent stays contained and scoped to its job, so you can run automated actions thousands of times without the risk of agents running out of control.
- →Control over rollout. Administrators decide which organizations get agents. Agents are organization-scoped and never available in personal workspaces, so they stay where your governance lives.
Co-Scientist Agents in Action
Example 1: Investigating failed runs automatically
When a run fails, someone usually has to dig through logs to work out why, then fix the code and relaunch. An agent can take that on. The moment a run fails, a Pipeline Action triggers the agent to investigate. It reaches the private pipeline code it needs through the workspace's GitHub App credential, then opens a pull request with a fix, ready for review. By the time anyone opens the failed run, the diagnosis is done and a fix is waiting. Your team stays in control: nothing merges until someone reviews and approves the pull request.
Example 2: Interpreting results automatically
Reading a report and pulling out what matters is another task teams repeat after every run. An agent can handle this too. When a run completes, a Pipeline Action wakes the agent, which interprets the results and posts a summary, all within Seqera Platform. In the demo below, an nf-core/atacseq run finishes and the agent reports on key metrics such as how many reads were mapped, then summarizes the run in a short report. It works through the results the same way every time, so the whole team gets a consistent read on every run without anyone having to remember to ask.
Example 3: Create an agent with custom permissions
Start by writing the instructions once and giving the agent a name the team will recognize. Then bind it to a Service Account with exactly the access the task needs, and nothing more. When a colleague runs the agent, it acts with the service account's permissions, not theirs, so a shared agent behaves the same way no matter who starts it. Setting one up in Seqera Platform takes a few steps:
- Open the Agents tab and create a new agent.
- Create a Service Account for the agent to act as.
- Create a permission scheme for that Service Account, granting only what the agent's task needs.
- Assign the scheme to the new Service Account.
- Select the Service Account on the agent. It's now ready to run.
Context and Guardrails
Context is what makes an agent useful. Guardrails are what make it safe to hand work to. This is where Co-Scientist Agents differ from most agent tools. You don't rely on telling an agent "please don't do this" in its prompt. You define what it can and can't do through a permission scheme, enforced by its Service Account. Seqera Co-Scientist provides both, operating within the permissions you define: least-privilege credentials, scoped Personal Access Tokens, and role-based access. It cannot act outside those boundaries. Your proprietary data, code and AI stay secure in your environment, and your data never leaves your infrastructure. The result: scientists get automation and intelligent assistance that speeds up their work, while security teams keep full governance and traceability over every action an agent takes.
Building the Bioinformatics Factory
Our vision is simple: samples go in, results come out, and agents keep the line running in between. Sample arrivals, LIMS events and sequencer events feed the context, Seqera Platform enforces the rules, and researchers, agents and deterministic pipelines work side by side without interruption.