Google Cloud sets out three-layer AI agent plan for biotech

Google Cloud has outlined a three-layer architecture for AI agents in biotech drug discovery. The design separates workflow orchestration, GPU-based scientific computing and governance controls.

The approach targets research tasks that run for minutes or hours, rather than the short, stateless actions typical of many AI agents. Drug discovery workloads such as protein folding, ligand screening and structure-activity relationship analysis can overwhelm standard large language model endpoints because of their long runtimes, large data volumes and restrictions on proprietary chemical information.

Under the proposed model, heavy scientific computation sits in a dedicated execution layer, while a separate cognitive layer handles task sequencing and reasoning. A third governance layer is designed to keep data, identities and approvals within an organisation's control framework.

In the execution layer, protein folding with ESMFold and generative molecular design with GenMol run as NVIDIA Inference Microservices on Google Kubernetes Engine. Those services are hosted on G4 virtual machines using NVIDIA RTX PRO 6000 Blackwell GPUs.

One of the main technical challenges in containerised GPU workloads is start-up delay, when large model weights must be pulled from a registry and loaded into GPU memory. To reduce this, Google Cloud recommends keeping at least one active node in the Kubernetes pool, loading model weights into memory when pods start, and allowing Kubernetes to restart failed instances without removing the underlying virtual machine.

Google Cloud also proposed a deployment split based on workload sensitivity. Strategic or proprietary pipelines should run on dedicated GPU infrastructure within a company's own security perimeter, while more routine or standardised tasks can be sent to managed cloud endpoints.

That distinction is especially important in biotech, where molecular structures and screening data can represent valuable intellectual property. Early-stage exploration can use hosted endpoints, but proprietary lead candidates can be handled with the same container image deployed inside a private virtual network so structural data does not leave the enterprise perimeter.

Cognitive layer

For orchestration, the design uses Agent Runtime in the Gemini platform and adopts a hierarchical multi-agent model. In the example described, a lead orchestrator delegates work to two specialist sub-agents covering lead optimisation and safety screening.

A user request, such as analysing a candidate compound against a target and producing a structure-activity relationship report, would be broken into a sequence of tasks. The lead orchestrator passes work to specialist agents through the platform's software development kit rather than over network-based HTTP calls, aiming to reduce internal delay.

The architecture also avoids moving large scientific files through model prompts. Instead, raw structural data such as PDB files, docking poses and trajectory logs are written to cloud storage, while agents exchange lightweight references and summaries. Google Cloud said this keeps context windows smaller and reduces the risk of prompt truncation and other failures linked to large payloads.

Another feature of the design is a split between general planning and domain-specific scientific reasoning. Gemini handles workflow planning and synthesis, while chemistry and pharmacology reasoning are assigned to specialised Nemotron models running on dedicated GPU nodes.

Google Cloud also argued against rigid screening thresholds in drug discovery. Candidate evaluation should reflect therapeutic context, since acceptable safety and efficacy trade-offs can differ sharply between areas such as preventive cardiovascular care and oncology.

Governance controls

The third layer focuses on governance and human oversight. According to Google Cloud, the Gemini platform provides agent identity, gateway controls, an agent registry and model inspection features to support audit trails, regional data handling rules, and protection against prompt injection or unauthorised data extraction.

In practice, this would allow every autonomous agent to operate with a verifiable identity, with actions such as advancing or rejecting a candidate molecule tied to that agent in the audit record. A central gateway would control traffic into and out of the system, while a registry would restrict production use to approved agents, tools and model context protocol servers.

Google Cloud also promoted what it called asymmetric autonomy for drug discovery workflows. Under that model, agents could perform reversible tasks such as resolving chemical naming synonyms, retrieving structural data and running preliminary Lipinski screens without interruption. More consequential steps, including starting a multi-GPU docking run, advancing a lead compound to wet-lab synthesis or archiving a therapeutic programme, would require human approval.

The broader argument is that AI agents for biotech must be built differently from the short-turnaround assistants used in customer service or knowledge work. Google Cloud said the most effective systems keep orchestration focused on decomposition and synthesis, move intensive numerical simulation to specialised services, pass heavy scientific data by reference rather than through prompts, and place the entire workflow inside auditable governance controls.

This separation of planning, computation and oversight is intended to support larger structural biology models and more complex simulation workloads while keeping proprietary research data secure and traceable.