How a Singapore cancer institute automated genomics data operations on AWS

In November 2025, Principal Investigator Jason Pitt’s Genomics and Data Analytics Core (GeDaC) team at the Cancer Science Institute of Singapore (CSI Singapre), part of the National University of Singapore, approached Amazon Web Services (AWS) with an Amazon Research Awards proposal to automate the data operations that were slowing down their cancer genomics research. A year later, that proposal has evolved into the Virtual DataOps Team (VDOT); a five-agent system running in production on Amazon Bedrock AgentCore that researchers can use to discover, download, and process genomic datasets through a conversational interface, reducing the technical overhead of working across fragmented genomic data repositories. This post walks through what GeDaC built, the build decisions behind it, and why the pattern generalizes well beyond one lab.

Public data, out of practical reach

Cancer genomics research depends on public sequencing archives—the Genomic Data Commons (GDC), the Sequence Read Archive (SRA), and the European Genome-phenome Archive (EGA)—that together hold petabytes of raw sequencing data. Accessing that data requires learning three distinct data models and access rules, then reconciling cohorts across databases that aren’t designed to talk to each other. For research teams without dedicated bioinformatics or DataOps support, this operational burden can become a barrier to using public genomic data. A researcher might know the biological question they want to answer, but retrieving the right cohort can require navigating repository-specific metadata, accession schemes, APIs, credentials, and command-line tools.

From a workflow tool to a purpose-built agent platform

VDOT began as a workflow-oriented prototype. As the project evolved, the team needed an architecture designed around specialized AI agents, secure tool access, independent scaling, and agent-to-agent delegation. This led to Amazon Bedrock AgentCore as the runtime for the production architecture.

Meet the team

Figure 1: Architecture of the five-agent VDOT team

As shown in the preceding diagram, VDOT mirrors a human DataOps team, with five roles instead of one model doing everything:

1. The Orchestrator interprets a researcher’s request, builds a plan, and coordinates the other agents.
2. Discovery agents search the GDC, SRA, and EGA, respectively, using schema-aware reasoning tailored to each repository.
3. The Transfer agent handles secure, fault-tolerant retrieval of raw sequencing files at scale.
4. The Processing agent launches and monitors containerized bioinformatics workflows.
5. The Peer Reviewer checks plans and outputs for accuracy before they reach the researcher.

This specialization is deliberate. Each repository has its own data model, terminology, APIs, and access rules. Rather than asking a single general-purpose agent to handle every repository and operational task, VDOT separates responsibilities so that each agent can use repository-specific instructions and tools.

How it’s built

VDOT’s architecture follows three design principles: specialize the agents, ground their reasoning in authoritative data, and separate agent reasoning from large-scale data operations.

A researcher signs in with an emailed one-time passcode through Amazon Cognito, which is exchanged for temporary credentials through AWS Security Token Service (AWS STS), which are then used to sign every request into Bedrock AgentCore. This verification step happens before the request reaches an agent.

Specialize agents around distinct responsibilities. The Orchestrator and each discovery agent run as independent workloads on AgentCore Runtime, reasoning using Claude on Amazon Bedrock. Rather than relying on a single agent to understand every repository and operational task, the Orchestrator delegates work to specialist agents for individual genomic repositories, data transfer, and processing. This allows each agent to use instructions and tools tailored to its role and to scale independently.

Ground discovery in repository data and documentation. Each discovery agent pairs a repository-specific server built on the Model Context Protocol (MCP)—which queries the live repository directly, so answers come from the archive , not from memory—with retrieval-augmented generation (RAG) over Amazon S3 Vectors for additional schema and documentation context.

Separate reasoning from data movement and computation. After the discovery agent identifies a dataset, a REST API on Amazon API Gateway and AWS Lambda, backed by Amazon DynamoDB, dispatches repository-specific downloader containers on AWS Batch. A Nextflow Runner, also on Batch, submits completed downloads to established nf-core pipelines.

The rest of the stack follows the same pattern: AWS Amplify hosts the web app, Amazon Simple Email Service (SES) delivers the passcode email, AWS Secrets Manager stores hold each researcher’s repository credentials, protected using AWS Key Management Service (AWS KMS) encryption keys, and AWS Identity and Access Management (IAM) enforces that a researcher can reach only their own files. AWS Cloud Development Kit (AWS CDK) deploys the environment, and Amazon CloudWatch gives the team visibility into how agents behave in production. This allows GeDaC’s engineers at CSI Singapore to focus on the agents and the science, not on operating infrastructure.

What this looks like end to end

Consider a researcher who wants RNA sequencing (RNA-seq) data from an SRA BioProject. Instead of manually identifying the files, scripting the transfer, constructing a samplesheet, and configuring a processing workflow, the researcher can ask VDOT to retrieve the dataset and subsequently run an nf-core/rnaseq pipeline. Behind the conversation, the discovery agent resolves the relevant repository metadata, the Transfer agent submits the download to AWS Batch, and the Processing agent constructs the required inputs and submits the nf-core workflow. Outputs are written back to Amazon Simple Storage Service (Amazon S3) for downstream analysis. From the researcher’s perspective, the interaction remains conversational; behind it is a distributed workflow spanning agent reasoning, repository APIs, managed compute, and established bioinformatics pipelines. What used to require scripting a download and hand-configuring a pipeline became two chat requests and a wait.

Does it hold up under expert scrutiny?

For scientific workflows, fluent answers aren’t enough; researchers need to know where information came from and whether the underlying operations were executed successfully. VDOT therefore emphasizes tool-grounded interactions. Repository questions are resolved against live source APIs through MCP tools, while transfer and processing tasks are executed through managed backend services rather than inferred by the model. GeDaC at CSI Singapore is evaluating the system across repository discovery, data transfer, and processing tasks. A broader evaluation of accuracy, efficiency, and researcher interaction will be reported separately.

Why this matters beyond one institute

Cancer genomics is the case study, but fragmented public data that’s hard to reach repeats across other disciplines; climate researchers face a similar challenge navigating archives like NOAA’s National Centers for Environmental Information, as do public health and social science researchers with their own scattered repositories. VDOT demonstrates how conversational AI can support the goals of the FAIR data principles by making complex public data repositories easier to find, access, and navigate; an approach that could help researchers across disciplines make greater use of existing research data. VDOT’s answer isn’t to simplify the archives; it’s to give researchers a team that already knows how to use them and that is reachable through conversation.