Most AI tools are stateless. You open a window, ask something, get an answer, close it. Nothing persists. Nothing happens on its own. The AI waits for you to show up, which means it only helps when you remember to use it. ChatGPT, Claude, Gemini: all brilliant in a conversation. All useless the moment you close the tab.

We wanted something different. An AI that shows up every morning, reads the inbox, checks the calendar, tracks open deals, monitors engineering PRs, and follows up on things you’d otherwise drop. Not a chatbot. An executive assistant.

Here’s how we built it.

The model layer: LLMs as reasoning engines

The core of the system is a large language model. We use ChatGPT as the primary LLM. Specifically the API, not the chat interface. ChatGPT handles reading, summarizing, drafting, and deciding what needs attention. For some tasks we’ve experimented with other models as a fallback or for comparison, but ChatGPT seems to be easier to train to have the right personality.

But we’re not using LLMs as chatbots. We’re using them as reasoning engines that get called by code, receive structured context, and return structured actions. The difference between “AI tool” and “AI agent” is mostly this: who initiates the interaction.

Start with identity

The first decision, and the one most people skip, is giving the assistant a real identity.

Ours has a name, a persona, and its own email address. When it sends an email, it comes from a real mailbox with a proper signature, threaded replies, and HTML formatting. Recipients don’t get a wall of monospace text from `noreply@`. They get a professional email that looks like it came from someone on the team.

This matters more than it sounds. When the assistant has an identity, it changes how you think about it. You’re not prompting a tool. You’re delegating to someone. And it changes how recipients interact with it too.

Practically, this means:

• A dedicated account. A real email address in Google Workspace.

• OAuth credentials. So it can read and send email on that account.

• An HTML signature. stored as a file the assistant loads at send time.

• Proper reply threading. Setting `In-Reply-To` and `References` headers, passing the `threadId` back to the Gmail API so replies land in the right conversation.

Write an operating manual, not a prompt

The assistant’s behavior is defined in a file called `AGENTS.md`. Think of it less as a system prompt and more as an employee handbook.

It covers the assistant’s role, tone, how to prioritize competing demands, when to act autonomously and when to check first, and how to handle specific situations: a cold email from an investor, a bug report from a customer, a PR that’s been open for a week.

A key insight here: a good prompt tells an AI what to do today. A good operating manual tells it how to think, so it can handle situations you didn’t anticipate. This is what separates a useful AI agent from a glorified macro.

The manual evolves. Every time the assistant handles something poorly, or you find yourself explaining the same preference twice, that’s a signal to update it. I treat it like onboarding documentation I’d write for a new hire.

Organize work into lanes

An executive assistant can’t just have a to-do list. The work is too varied.

We split responsibilities into five lanes: current customers, marketing and go-to-market, fundraising, engineering, and operations. Each lane has its own directory in the repository with a tracking file. The assistant maintains state per lane: open tasks, recent decisions, things to follow up on.

This prevents everything from collapsing into one undifferentiated pile where everything feels equally urgent. It also makes routing easy. An email from a potential customer goes to the customers lane. A GitHub notification goes to engineering. The assistant knows where things belong.

This lane structure is also what makes the system composable. You can add a new lane (legal, HR, investor relations) without touching anything else.

Routines and reactive tasks

The assistant does two kinds of work: scheduled and reactive.

Scheduled routines run via cron. The most important one is the morning briefing. Every day, the assistant reads the inbox, checks the calendar, scans each lane’s tracking file, and sends a priorities email. It surfaces what’s time-sensitive, what’s been waiting too long, and what on the calendar needs preparation. Other routines run weekly: a review of open tasks per lane, a check for stale GitHub issues, a follow-up sweep for emails that didn’t get a response.

Reactive tasks happen in response to events. A new email arrives, a PR is opened, a message comes in on Telegram. The assistant processes these and either handles them directly or flags them for attention.

Routines give structure. Reactive tasks give responsiveness. Together they cover most of what an executive assistant actually does. No n8n, no Zapier, no low-code automation platform. Just Python, cron, and an LLM API.

Email: the full stack

Email is the hardest integration to get right. Reading is easy. Everything else takes work.

We built a Gmail integration that handles the full lifecycle:

• Reading. Checking the inbox, filtering by sender, fetching full message bodies.

• Sending. Plain text for simple cases, HTML with signature for external emails.

• Replying. Proper threading with the original quoted below: reply, then signature, then original, exactly like a human would format it.

• Archiving. Removing the INBOX label once something is handled.

For real-time responsiveness, we replaced polling with Gmail’s push notification system. Gmail publishes a notification to a Google Cloud Pub/Sub topic whenever the inbox changes. The assistant pulls from that subscription, gets the `historyId`, calls the Gmail History API to find out what actually changed, then fetches the new messages. The result is that it reads to email in minutes instead of having to run a continuous poling cycle (which will get it blocked), or wait for hours to read the email.

The infrastructure for this is straightforward. A Pub/Sub topic and subscription in GCP, IAM grants so Gmail can publish and the assistant’s account can pull, and a state file that persists the last known `historyId` across restarts.

GitHub instead of spreadsheets

Most engineering teams already live in GitHub. Work is tracked in issues. Code changes go through pull requests. Discussions happen in comments.

Rather than maintaining a separate tracker, we connected the assistant directly to GitHub. It monitors open PRs, flags ones waiting for review, checks issue status, and can open or comment on issues as needed.

The practical benefit: zero duplication. There’s no spreadsheet to keep in sync with reality. The assistant reads the ground truth directly. For a founder or CTO, this means the morning briefing can include “three PRs are waiting for your review” and “this issue has been open for two weeks,” without anyone having to compile that information manually.

Calendar and time awareness

The assistant connects to Google Calendar and reads the day’s schedule as part of its morning routine. This sounds simple but it changes what the briefing can do.

With calendar access, the assistant can flag back-to-back meetings that leave no time for focus work, notice that a meeting has no agenda, and cross-reference email with calendar. If someone emailed about a topic and there’s a call with them today, it surfaces that connection.

It also gives the assistant temporal grounding. It knows what day it is, what’s coming up this week, and when deadlines are approaching.

Other channels

Telegram gives a lightweight async channel for quick back-and-forth. Rather than opening a full coding environment to interact with the assistant, you can message it from your phone and get a response.

Text-to-speech lets the assistant deliver voice briefings. Instead of reading the morning priorities email, you can listen to it. Useful when moving between meetings.

The principle behind both: meet the human where they are. The assistant should be reachable in the way that’s most natural for the moment. Just like a real world assistant can sometimes make a call or leave a voice note.

Running on real infrastructure

An executive assistant that only runs on your laptop isn’t very useful. We run ours on a dedicated machine that’s always on.

A few things this required:

Credential management across machines. OAuth tokens are tied to a Google account, not a machine. We store tokens and have a script that copies them to the remote machine via `scp`. A single setup script creates the virtual environment and installs all dependencies. One command to get a new machine running.

Cron for routines. Scheduled tasks run via system cron. Simple, transparent, easy to debug.

State persistence. The assistant tracks its position in the email stream (via `historyId`), open tasks per lane, and other state in files in the repository. These persist across restarts and are visible to anyone who looks.

The approach is deliberately simple. No Kubernetes, no managed services, no LangChain, no agent framework. A Python virtual environment, the LLM SDK, a few API credentials, and a cron job. The complexity is in the operating manual, not the infrastructure. We initially ran this using a homemade framework but we have now moved to openclaw. If you use openclaw too, remember to spend enough time locking it down. It has a big security surface area.

Lessons learned

The integrations aren’t the hard part. OAuth flows, API clients, Pub/Sub subscriptions: these take a day or two to get right but they’re well-documented and mostly mechanical. The hard part is defining what the assistant should actually do with the information it has access to.

Autonomy is a dial, not a switch. Some things the assistant should do without asking: send the morning briefing, archive a handled email, update a tracking file. Other things need a human in the loop. Getting this calibration right takes iteration.

The operating manual is never done. Every week there’s a situation it didn’t handle well. That’s not a failure. It’s input. The manual gets better over time, and so does the assistant.

Treating it like a new hire changes everything. When you ask “what would I tell a new person joining the team?” you write better instructions than when you ask “what prompt should I give the AI?” The former produces judgment. The latter produces rules.

Beyond the executive assistant

We built this for an executive assistant, but the underlying pattern applies anywhere someone manages high information volume across multiple tracks of work.

A venture capital investor faces the same structural problem: hundreds of portfolio companies, thousands of inbound pitches, LP communications, market research, and a calendar that fills up faster than it empties. Lane-based tracking maps directly to sectors or stages. The morning briefing surfaces which portfolio companies need attention and which inbound pitches are worth reading.

A law firm partner juggles client matters, court deadlines, associate work product, and business development. Email threading and reply quality matter enormously in a profession where written communication is everything. Routine sweeps for approaching deadlines are table stakes.

An executive assistant is an important hire. An AI agent powered by Claude, GPT, or whichever frontier model fits the task does most of the same work at a fraction of the cost, around the clock, without needing to be managed.

The common thread: any role that involves managing information across multiple domains, maintaining relationships over time, and keeping many things from falling through the cracks is a candidate for this kind of system.

The technology is available. The LLM APIs are mature. The integrations are straightforward. The real investment is in the operating manual. Think carefully about how good judgment in your domain actually works, and write it down.

There’s just one problem: a docking score is not a result. It’s a hypothesis.

Let’s talk about what’s actually happening under the hood.

Picture this: you take a protein structure, usually a crystal structure pulled from the PDB, frozen in a single conformation, with missing flexible loops and resolution gaps that leave genuine ambiguity about where atoms sit. You take a small molecule. You run AutoDock Vina, GNINA, GOLD or GLIDE. A number comes out.

That number tells you how well the algorithm thinks the molecule fits the binding pocket given a rigid receptor, implicit solvent, and a scoring function trained on datasets that may or may not look anything like your target class [1,2].

What it doesn’t tell you: whether the molecule will actually bind in a cell. Whether it survives metabolism long enough to get there. Whether your protein even resembles that crystal structure once it’s inside a living system.

Here’s the thing, the field knows this. It just doesn’t say it out loud.

A critical analysis of over 400 published virtual screening studies found that hit rates vary wildly, and that computational filters, binding assays, and secondary validation are routinely skipped before compounds get advanced [3]. In practice, even a well-designed screen might yield around 3 confirmed hits per 100 compounds experimentally tested [4].This isn’t a software problem. It’s a physics problem. Conventional scoring functions struggle to capture long-range electrostatics, desolvation upon binding, and entropic contributions to the precise physical forces that govern whether a molecule actually binds under biological conditions [5]. And most docking algorithms still treat the receptor as a rigid body, even though proteins move constantly between conformational states and ligand binding almost always reshapes the pocket to some degree [6].

The problem isn’t docking. Docking is a powerful, legitimate tool when it’s used as one.

The problem is what happens when a score becomes the story.

So what does rigorous docking actually look like?

It looks like one step in a workflow, not the whole workflow. It starts with a carefully prepared protein structure: protonation states assigned, missing residues modeled, binding pocket validated before a single compound is screened [5]. It uses multiple scoring functions with consensus scoring to reduce false positives. It accounts for receptor flexibility through ensemble docking or induced-fit protocols where it matters most.

And critically: every top-ranked compound is treated as a hypothesis to interrogate, not a discovery to announce.

The molecules worth pursuing emerge from integrating docking results with ADMET predictions, molecular dynamics stability checks which overcome the rigid sampling limitations inherent in static docking and, wherever possible, experimental data from analogous systems [7].

That pipeline is slower. It produces fewer headlines. But it produces fewer expensive failures two years and fifty million dollars down the road.

Why does this matter right now?

Because as AI-powered docking tools multiply, the temptation to compress this workflow grows louder. Models are faster. Interfaces are cleaner. It has never been easier to generate a ranked list of compounds and call it a drug discovery campaign.

The teams that actually move molecules into the clinic will be the ones who never forgot what a docking score really is and what it isn’t.

At Pauling.AI, that distinction is built into everything we do. Not because rigor is fashionable, but because it’s the only thing that holds up when the biology talks back.

References

1. Gu, J. et al. (2021). Molecular docking-based computational platform for high-throughput virtual screening. SpringerPlus / PMC. https://pmc.ncbi.nlm.nih.gov/articles/PMC8754542/

2. Pinzi, L. & Rastelli, G. (2019). Molecular Docking: Shifting Paradigms in Drug Discovery. International Journal of Molecular Sciences, 20(18), 4331. https://pmc.ncbi.nlm.nih.gov/articles/PMC3151162/

3. Hevener, K.E. et al. (2012). Hit Identification and Optimization in Virtual Screening: Practical Recommendations Based upon a Critical Literature Analysis. Journal of Medicinal Chemistry, 56(3), 927–944. https://pmc.ncbi.nlm.nih.gov/articles/PMC3772997/

4. Cambridge MedChem Consulting. Virtual Screening Hit Rate Analysis. https://www.cambridgemedchemconsulting.com/resources/hit_identification/virtual_screening_selection.html

5. Ramírez, D. & Caballero, J. (2020). Practical Considerations in Virtual Screening and Molecular Docking. Frontiers in Chemistry / PMC. https://pmc.ncbi.nlm.nih.gov/articles/PMC7173576/

6. Totrov, M. & Abagyan, R. (2008). Flexible ligand docking to multiple receptor conformations: a practical alternative. Current Opinion in Structural Biology, 18, 178–184. Cited in: Challenges in Docking: Mini Review. JSciMedCentral. https://www.jscimedcentral.com/jounal-article-info/JSM-Chemistry/Challenges-in-Docking:-Mini-Review-8879

7. Tao, X. et al. (2022). Integration of Molecular Docking Analysis and Molecular Dynamics Simulations for Studying Food Proteins and Bioactive Peptides. Journal of Agricultural and Food Chemistry. https://pubs.acs.org/doi/10.1021/acs.jafc.1c06110

The question is not whether LLMs can read papers. They can. Thousands per second. They find connections no human would catch; a kinase studied in oncology that turns out relevant in neurodegeneration, a mechanism buried in a 2003 paper that explains a clinical failure twenty years later.

LLMs synthesize, hypothesize, they reason about mechanisms.

But they cannot do experiments. And experiments are where drugs come from.

This is the part the pitch decks skip. In software, the loop can be closed naturally. An LLM can write code, run it, see the output and iterate. The experiment is computational. The whole cycle lives inside the computer.

In drug discovery, the loop is not that easy.

A hypothesis about binding affinity cannot be resolved by generating more text. A prediction about off-target toxicity is not validated by writing a better paragraph. You need new data. Data that does not exist yet. Data that comes from physics-based simulations or wet lab assays. Not from autocomplete.

Without that, an LLM is just a very confident librarian that occasionally makes things up. In a chatbot, hallucination is embarrassing. In your pipeline, hallucination is half a year of work and ten million dollars lost chasing a fabricated result that looked exactly like a real one.

So the real challenge is not AI that reads. It is AI that experiments.

Some teams are solving this with robotic lab automation. Real metal, real plates, real assays. That matters.

We are solving a different part of the puzzle. At PAULING.AI we connect LLM reasoning to computational chemistry (molecular docking, molecular dynamics, ADMET prediction, etc.) so the AI does not just hypothesize. It tests. It generates data that did not exist before the query.

And here is what nobody talks about: the hard part is not building a cool demo. It is the reliability. A drug discovery workflow chains dozens of sequential steps. If each step runs at 90 percent reliability, your end-to-end success rate is under 10 percent. That is a hackathon project, it is not a product.

The real engineering challenge is driving step reliability to 99 percent and above. Handling edge cases, bad inputs, ambiguous outputs, fully autonomously. No human babysitting every transition. Because that’s what makes the end to end workflow reliable and useful to real drug discovery scientists.

That is the difference between AI that impresses a board room and AI that actually moves a drug discovery program forward.

Your next cancer drug will not come from a prompt. It will come from a system that reasons, experiments, and iterates. Autonomously. Reliably. Every time.

You needed chemistry. Structural biology. Computational chemistry. Linux admin. GPU infrastructure. File format black magic. You had to know which scoring functions lie less, how to prep a protein properly, how not to poison your own screen with bad protonation states.

Docking is supposed to be the first step in drug discovery.

Instead, it feels like a mini research project.

And it is not the end. It is triage. It is hypothesis generation. It is how you narrow ten million molecules to a few hundred worth looking into. It feeds medicinal chemistry. It feeds MD. It feeds assays. It is the beginning of the funnel, not the drug candidate.

But if the beginning is painful, everything downstream slows down.

So in Pauling, we built a vibe docking tool.

You prompt the target.

We handle structure cleanup. Pocket definition. Library design. Conformers. Docking. Rescoring. Filtering. Ranking. Constraints. Iteration. You steer in natural language. The system runs the workflow.

It feels less like babysitting a cluster and more like directing Jarvis in the Iron Man movies.

“Use this pocket.” “Avoid these types of compounds.” “Run a longer simulation for the top 10 hits.” “Now show me the ADMET estimates.”

In software, vibe coding means you do not need a 250,000 $/year engineer to scaffold an app. You describe the outcome. The system builds the scaffolding.

In drug discovery, vibe docking means you do not need a PhD medicinal chemist just to generate credible hits.

Expertise does not disappear. It moves up a level. Toward mechanism. Strategy. Clinical positioning. Real insight.

Docking becomes a primitive. It’s not the bottleneck.

A new way to do drug discovery is coming. It is not magic. It is tooling finally catching up. Stay tuned.

Setting up a molecular dynamics campaign has traditionally meant weeks of manual work before a single production run begins: force field selection, solvation box configuration, equilibration tuning, custom analysis scripting multiplied across every complex in the library. For most computational teams, that overhead isn’t the exception. It’s the baseline.

Automated MD pipelines collapse that timeline. A full campaign complex triage, AMBER and CHARMM force field assignment, TIP3P solvation at 0.15M NaCl, 50,000-step minimization, NVT/NPT equilibration, and 100 ns production runs across 100 complexes in parallel, with binding free energy analysis now runs in roughly 10 compute hours with zero manual intervention.

The science hasn’t changed. The infrastructure has. And the gap between teams that have made that transition and those still running manual workflows widens every quarter.

The Manual Workflow Bottleneck

Running molecular dynamics in GROMACS requires navigating 200+ interdependent parameters across multiple file formats.

Computational chemists face three compounding bottlenecks:

• Parameter selection (force fields, water models, thermostat coupling).

• Performance tuning (PME ranks, GPU allocation, domain decomposition)

• Post-simulation analysis (custom scripting for RMSD, RMSF, binding energies like dG by MMPBSA or FEP.

Studies show manual workflows take “excessive time and effort” [1], and 60-70% of setup goes to chores, not discovery.

AI Agents Enter the Scene

Large language models combined with domain-specific automation offer the solution. A February 2025 study by Lin et al. demonstrates LLM-based systems can automate molecular dynamics workflows through natural language commands [3].

Instead of manually editing configuration files, researchers describe scientific objectives and autonomous agents handle file preparation, parameter selection, simulation execution, and analysis.

Independent research supports this direction: the MDCrow study tested multiple LLM architectures (GPT-4, Claude, Llama), demonstrating that autonomous orchestration of complex GROMACS pipelines is achievable [3].”

Practical implementations are operational. Platforms like Autochem are developing command-based systems that decompose the GROMACS pipeline: complex selection from docked libraries, system preparation with force fields (AMBER, CHARMM, OPLS) and water models (TIP3P, TIP4P, SPC/E), automated solvation, ionization, energy minimization, NVT/NPT equilibration, production runs, and comprehensive analysis.

Dozens of manual gmx commands (pdb2gmx, editconf, solvate, grompp, mdrun) now execute through workflows with intelligent parameter propagation.

The automation spectrum ranges from specialized analysis tools (2024 J. Biomol. Struct. Dyn. [1]) generating reports via single commands to end-to-end platforms (2023 Comput. Struct. Biotechnol. J. [4]) integrating with GROMACS modules. The shift: treating MD workflows as programmable sequences AI executes autonomously.

Intelligent Parameter Selection

AI tackles GROMACS’s most technical challenge: parameter optimization. Traditional “one-factor-at-a-time” tuning fails to capture complex interactions between PME ranks, GPU allocation, and domain decomposition [2]. Research by Kutzner et al. (2019) and Abraham et al. (2025) uses systematic algorithms identifying ideal parameter combinations across hardware from workstations to 65,000-core supercomputers [2][5]. These systems automatically balance PP/PME workloads, configure CPU affinity, and optimize bonded interaction offloading.

Figure: AI-driven parameter optimization outperforms default GROMACS settings by searching the full PP/PME configuration space.

Sivakumar et al. ‘s 2024 Artificial Intelligence Review shows ML models trained on MD datasets can predict optimal simulation parameters before runtime [6], shifting from reactive troubleshooting to proactive configuration maximizing accuracy and efficiency.

Automation That Understands the Science

Fully autonomous MD simulations are emerging. TorchMD (Thölke & De Fabritiis, 2022) and OpenMM 8 (Eastman et al., 2024) integrate ML potentials directly into simulation engines, enabling end-to-end differentiable workflows where force fields optimize during runtime [7][8]. Chaudhary et al.’s 2024 Current Opinion in Structural Biology review argues AI and quantum computing integration is “catalyzing a revolution in computational biology” [9].

Platforms like Pauling.AI orchestrate complete GROMACS pipelines complex selection, system preparation, energy minimization, equilibration, production, analysis via command interfaces. Manual gmx command chains now execute through parameterized workflows handling force field selection, water configuration, ion concentration, and simulation duration automatically. Multi-day workflows compress into hours.

The bottleneck shifts from technical expertise to scientific question formulation. Smaller labs without computational specialists gain access to workflows previously reserved for expert practitioners. GROMACS pipelines requiring weeks of manual iteration become accessible through automated systems designed for reliability and reproducibility at scale.

Intelligent automation is here. The question: adoption speed.

Stay Ahead of the Automation Wave

Manual MD is giving way to AI-driven workflows fast, right now. Subscribe for updates on computational-chemistry automation, intelligent simulation platforms, and the ways AI agents are reshaping molecular dynamics research.

Subscribe now

References

[1] Gupta, A., et al. (2024). “ASGARD: An Automated System for GROMACS Analysis, Reporting, and Documentation.” Journal of Biomolecular Structure and Dynamics. https://www.tandfonline.com/doi/full/10.1080/07391102.2024.2439838

[2] Kutzner, C., et al. (2019). “More bang for your buck: Improved use of GPU nodes for GROMACS 2018.” Journal of Computational Chemistry. https://onlinelibrary.wiley.com/doi/full/10.1002/jcc.26011

[3] Lin, T., et al. (2025). “MDCrow: A Large Language Model-Based Agent for Molecular Dynamics Workflow Automation.” arXiv preprint. https://arxiv.org/abs/2502.00539

[4] Bignon, E., et al. (2023). “CHAPERONg: A tool to facilitate automation of GROMACS-based molecular dynamics simulations and trajectory analyses.” Computational and Structural Biotechnology Journal. https://www.sciencedirect.com/science/article/pii/S2001037023000466

[5] Abraham, M. J., et al. (2025). “GROMODEX: GPU-optimized molecular dynamics parameter exploration.” Journal of Chemical Information and Modeling. https://pubs.acs.org/doi/10.1021/acs.jcim.4c01423

[6] Sivakumar, S., et al. (2024). “Machine Learning in Molecular Dynamics Simulations: A Comprehensive Review.” Artificial Intelligence Review. https://link.springer.com/article/10.1007/s10462-024-10989-z

[7] Thölke, P., & De Fabritiis, G. (2022). “TorchMD: A deep learning framework for molecular simulations.” Journal of Chemical Theory and Computation. https://pubs.acs.org/doi/10.1021/acs.jctc.1c01126

[8] Eastman, P., et al. (2024). “OpenMM 8: Molecular Dynamics Simulation with Machine Learning Potentials.” Journal of Physical Chemistry B. https://pubs.acs.org/doi/10.1021/acs.jpcb.4c04662

[9] Chaudhary, N., et al. (2024). “Computational biology and chemistry: A tapestry of innovation.” Current Opinion in Structural Biology. https://www.sciencedirect.com/science/article/abs/pii/S0959440X24001258

Spoiler: the GPUs were fine. The dashboard was misleading, because different tools measure different kinds of “GPU activity.”

The Setup

At Pauling.AI, we run GROMACS, the gold standard for molecular dynamics simulations in drug discovery on Google Cloud Dataflow with NVIDIA L4 GPUs. The value proposition is straightforward: elastically scale computational chemistry workloads without maintaining physical hardware. Run hundreds of simulations in parallel, pay only for what you use.

Our GROMACS pipeline architecture on Google Cloud Dataflow with NVIDIA L4 GPU workers

• Why molecular dynamics matters: MD simulations are the computational microscope of drug discovery. They let us watch how drug molecules interact with protein targets at the atomic level predicting binding affinity and stability before synthesizing a single compound. For longevity therapeutics targeting complex pathways like cellular senescence and mitochondrial dysfunction, MD simulations validate whether candidate molecules maintain stable binding over biological timescales. Each simulation solves Newton’s equations of motion for millions of atoms at femtosecond timesteps. It’s computationally brutal, which is exactly why GPU acceleration is non-negotiable.

Leave a comment

We expected high GPU utilization. GROMACS is GPU-optimized, and our workloads involve intensive force calculations and numerical integrations. When Cloud Monitoring showed 10-20% utilization, alarm bells rang. Were we misconfiguring something? Leaving performance on the table?

Cloud Monitoring dashboard showing suspiciously low GPU utilization

Down the Rabbit Hole

Our first instinct was to verify the basics. We confirmed GPU access within containers, validated NVIDIA drivers, and tested different CPU core allocations (4, 8, 12, 16 cores). We even enabled NVIDIA Multi-Process Service (MPS) thinking we had a scheduling issue.

Nothing moved the needle.

Then we ran a control experiment: the same GROMACS workload on a standard Compute Engine VM with an identical GPU. The result? 85% GPU utilization according to Cloud Monitoring. Yet both environments Dataflow and VM completed the simulation in virtually identical time.

This made no sense. Same code, same GPU, same performance, different metrics.

We Measured GPU Activity Directly

We stopped trusting the dashboard and went directly to the source. We embedded nvidia-smi polling inside our Dataflow containers to capture GPU metrics in real-time during simulation runs.

Code snippet - nvidia-smi monitoring script in collapsible section.

The real utilization? 80-90%.

The discrepancy wasn’t a bug, it reflects how different tools define and report “GPU utilization,” and what this workload is actually doing.

In our case, the GROMACS run is memory-bound rather than compute-bound. The GROMACS output showed that 75.6% of the time was spent in “Wait GPU state copy,” meaning the GPU frequently waits on CPU↔GPU memory transfers instead of executing math-heavy kernels.

This is where the dashboards diverge: Cloud Monitoring tends to reflect compute utilization averaged over time windows, which can look low (e.g., 10–20% or 20–40%) when the workload is dominated by transfer/wait phases. Meanwhile, nvidia-smi reports overall GPU activity, including memory-related operations, so it can show 80–90% even when compute cores are not the bottleneck.

Both readings can be technically “correct”, they’re just measuring different aspects of GPU behavior. The real bottleneck isn’t idle hardware; it’s transfer overhead limiting throughput.

Google Confirms It

We escalated to Google’s engineering team, who confirmed the core takeaway: the mismatch is primarily a measurement/definition issue, not a performance regression. In Dataflow, GPU metrics in Cloud Monitoring can under-represent utilization for workloads where GPU time is dominated by memory transfers and orchestration, especially when metrics are sampled and time-aggregated.

The critical insight: there was no meaningful wall-clock penalty. The runtime that matters for throughput and cost was comparable to our VM control.

What We Learned (and What You Should Do)

Don't optimize based on averaged metrics for variable workloads. If you're running scientific simulations, rendering pipelines, or any GPU workload with natural intensity fluctuations, your dashboard might be telling you a story that's statistically true but operationally misleading.

Here's our configuration that actually works:

Code snippet - Key Dataflow configuration flags in collapsible section.

Code snippet - GROMACS mdrun command with GPU flags in collapsible section.

• Use --experiments=no_use_multiple_sdk_containers for a single SDK container per worker

• Set --number_of_worker_harness_threads=1 as your baseline (tune from there)

• Enable NVIDIA MPS only if you genuinely have multiple processes per GPU

• Strip out streaming-specific settings for batch pipelines

Performance Over Percentages

Cloud platforms abstract away infrastructure complexity, but they also abstract away transparency. Monitoring systems optimize for general use cases, not specialized scientific workloads. When metrics don’t align with your understanding of the workload, trust your domain knowledge and validate directly.

We nearly spent days “optimizing” a problem that didn’t exist.

The real optimization opportunity? Understanding the measurement tools as deeply as we understand the computational methods.

If you’re running molecular simulations, quantum chemistry calculations, or any computationally intensive scientific workload in the cloud, remember:

performance is measured in seconds per simulation, not in dashboard percentages.

The GPUs don’t care about how a dashboard aggregates metrics. What matters is whether your workload is compute-bound or memory-bound and whether your monitoring tool is measuring compute, transfers, or a blend of both.

Our GPUs were busy all along, but the dashboard wasn’t telling the full story.

If you are interested in automation of drug discovery, reach out!

Subscribe now

Share Pauling AI Blog

The global anti-aging market surpassed $85 billion in 2025, reflecting a fundamental shift toward treating aging as a targetable biological process.

Small molecule drug discovery for longevity is transitioning from theory to clinical reality, driven by computational advances and deeper mechanistic understanding.

What Makes Small Molecules Ideal for Longevity Interventions?

Small molecules organic compounds under 900 daltons offer distinct advantages for longevity interventions: oral bioavailability, cellular membrane permeability, and the ability to modulate multiple aging pathways simultaneously. Unlike biologics, they’re easier to manufacture and can target intracellular processes.

A 2025 study in Aging Cell demonstrated that AI-designed polypharmacological compounds achieved 70% lifespan extension in C. elegans [1]. This remarkable finding suggests that targeting aging’s multifactorial nature through compounds acting on multiple pathways may be more effective than single target approaches.

Separately, Tokyo Metropolitan Institute identified another critical target: mitochondrial energy production. By enhancing respiratory supercomplex function, researchers extended both lifespan and healthspan in mice [2] proving that cellular powerhouses aren’t just metaphors, they’re druggable longevity targets ripe for small molecule intervention.

mTOR Inhibitors, Senolytics, and Metabolic Modulators: The Longevity Trio

mTOR Inhibitors

Rapamycin remains the most reliable lifespan extender across model organisms, according to the National Institute of Aging's Intervention Testing Program [3]. A 2025 Oxford study revealed that rapamycin protects human T cells from DNA damage and increases survival threefold, providing mechanistic evidence for geroprotective effects [4]. Next-generation compounds like rapalink-1 are showing promise in extending lifespan while revealing connections between mTOR signaling, metabolism, and microbiome composition [5].

Senolytics: Eliminating “Zombie Cells”

As we age, senescent cells often called “zombie cells” accumulate and fuel chronic inflammation. Can we selectively eliminate them? A landmark Harvard-Mayo-Cedars-Sinai study proved dasatinib plus quercetin is safe in older adults, reducing inflammatory markers and improving memory [6]. AI is accelerating discovery: machine learning models identified four potent compounds JQ1, RG7112, AMG232, and nutlin-3a that target both epigenetic age and senescence markers [7]. Second-generation agents like navitoclax and FOXO4-DRI peptides now offer even greater precision [8].

Metabolic Modulators: The Diabetes Drugs That Slow Aging

GLP-1 receptor agonists have emerged as potential longevity therapeutics beyond diabetes treatment, improving mitochondrial function and reducing inflammation [3]. A 2024 Cell study showed metformin’s geroprotective effects in monkeys, enhancing cognitive abilities [9]. Recent preclinical work combining oxytocin with an Alk5 inhibitor boosted lifespan in elderly male mice by 70%, highlighting sex-dependent aging responses [10].

From 4 Years to 18 Months: The AI Drug Discovery Advantage

Computational chemistry is transforming longevity drug development. Traditional pipelines require 4-6 years for preclinical work costing hundreds of millions; computation chemistry advanced methods such as ML are compressing timelines dramatically.

Pauling.AI’s autonomous platform integrates 120+ computational tools spanning six categories from RCSB Protein Data Bank structures, target modeling with AlphaFold, Boltz and RosettaFold to molecular dynamics engines like GROMACS with free energy analyses (dG) enabling pharma partners to identify viable candidates in weeks rather than years[11].

How does this speed happen? Modern AI platforms orchestrate multiple computational techniques simultaneously [12]. Molecular docking through tools like AutoDock Vina, GNINA, and Glide predicts which compounds bind target proteins. Molecular dynamics simulations using AMBER, CHARMM, and OpenMM map conformational changes across time scales. Quantum mechanics calculations via Gaussian, ORCA, and CP2K optimize drug properties at the atomic level. Machine learning models predict ADMET profiles (absorption, distribution, metabolism, excretion, and toxicity) before synthesis. What once required sequential wet-lab experiments now happens in silico, in parallel, at computational speed.

Comprehensive platforms like Autochem by Pauling.AI, one of our main AI agents orchestrating 120+ computational tools across target modeling, pocket druggability assessment, docking, molecular dynamics, FEP, and structural analysis enable extensive in silico screening before synthesizing compounds dramatically reducing costs and failure rates.

Quantum-classical hybrid computing is expanding accessible chemical space beyond traditional methods. A 2025 collaboration used quantum circuit Born machines with deep learning to screen 100 million molecules, identifying compounds with genuine biological activity against KRAS-G12D, a notoriously difficult cancer target [13]. AI-driven polypharmacology intentionally designing compounds targeting multiple aging pathways reflects aging’s multifactorial nature. This approach achieved a 70% hit rate in validating lifespan extension, far exceeding traditional single-target screening success rates [1].

What's Holding Us Back? And What's Next?

Despite progress, three critical barriers block widespread deployment. First, senescent cells aren’t uniform different tissues require tailored interventions [8]. Second, we lack validated aging biomarkers that actually reverse upon treatment [14]. Third, the safety paradox: senolytics must eliminate harmful senescent cells without disrupting their beneficial roles in wound healing and tumor suppression.

The solution? Think bigger. In a recent conversation between longevity pioneer Aubrey de Grey and our CEO Javier Tordable, de Grey emphasized that treating the body as a maintainable machine repairing accumulated damage through combination therapies remains central to achieving what he terms “longevity escape velocity.”

This concept suggests that advances in therapeutic technology could progress rapidly enough that people remain biologically younger as they age chronologically. They highlighted how advanced ML and CRISPR are accelerating damage repair strategies, though comprehensive funding and integrated approaches remain critical challenges.

They project significant breakthroughs by the end of the 2030s, aligning with the timeline for precision senotherapy guided by single-cell aging atlases and AI diagnostics [15].

Researchers are already proposing targeted nanoparticle delivery of therapeutics to specific tissues. The FDA’s 2025 draft guidance on AI in drug development, informed by 500+ submissions, reflects evolving regulatory frameworks [11]. As quantum computing advances exemplified by Microsoft’s Majorana-1 chip convergence of AI, quantum methods, and experimental validation will accelerate first-in-class longevity therapeutics [13].

Watch the full conversation on longevity research with Aubrey De Grey and the future of aging therapeutics on the Pauling.AI YouTube channel.

Comp Chem Isn’t Optional Anymore, It’s Central!

We’ve crossed a threshold. Small molecule longevity drug discovery is no longer theoretical it’s translational, with compounds advancing through clinical trials as you read this. The evidence is quantifiable: Drug discovery compressed from 4-6 years to 18 months for under $2.6 million [11]. AI-designed polypharmacological compounds achieved 70% lifespan extension in preclinical models [1]. Dasatinib plus quercetin demonstrated safety and cognitive benefits in human trials [6].

Computational chemistry platforms like Autochem, our main AI-agent orchestrating 120+ tools across molecular docking, dynamics simulations, FEP, and machine learning [12] are the engine driving this acceleration. These aren’t incremental improvements. Quantum-classical hybrid computing is expanding chemical space exponentially, identifying compounds against previously “undruggable” targets [13].

The FDA has processed 500+ AI-assisted drug applications since 2016 [11].

The goal isn’t just more years, it’s more healthy years. And computational chemistry is making longevity escape velocity measurable, achievable, and closer than the field has ever been.

Stay at the Forefront of Longevity Science

The intersection of AI and drug discovery is evolving rapidly. Subscribe to our news to receive insights on computational chemistry breakthroughs, small molecule therapeutics, and how AI is accelerating the development of next-generation longevity compounds.

Join researchers, biotech professionals, and innovators shaping the future of healthspan extension.

Subscribe to Pauling.AI Blog

References

[1] Fedichev, P. et al. (2025). “AI-designed polypharmacological compounds show promise in lifespan extension.” Aging Cell. https://longevity.technology/news/ai-designed-compounds-show-promise-in-lifespan-extension/

[2] Ikeda, K. et al. (2025). “Mitochondrial Respiratory Supercomplex Assembly Factor COX7RP Contributes to Lifespan Extension in Mice.” Aging Cell. DOI: 10.1111/acel.70294. https://www.sciencedaily.com/releases/2025/12/251218060557.htm

[3] Getchell, M. et al. (2025). “Top 10 Longevity & Anti-Aging Breakthroughs of 2025.” Healthspan. https://www.gethealthspan.com/research/article/top-ten-longevity-anti-aging-breakthroughs-of-2025

[4] Kell, L.B. et al. (2025). “Rapamycin exerts its geroprotective effects in the ageing human immune system by enhancing resilience against DNA damage.” bioRxiv 2025.08.15.670559. https://www.nad.com/news/new-oxford-study-powerful-longevity-drug-rapamycin-targets-cell-senescence

[5] Kumar, J., Ng, K., & Rallis, C. (2025). “Rapalink-1 reveals TOR-dependent genes and an agmatinergic axis-based metabolic feedback regulating TOR activity and lifespan in fission yeast.” Communications Biology, 8(1). DOI: 10.1038/s42003-025-08731-3. https://www.sciencedaily.com/releases/2025/12/251205054729.htm

[6] Millar, C.L. et al. (2025). “A pilot study of senolytics to improve cognition and mobility in older adults at risk for Alzheimer’s disease.” Harvard-Mayo-Cedars-Sinai Joint Study. https://www.nmn.com/news/new-harvard-study-anti-aging-senolytics-are-safe-for-seniors-with-memory-loss

[7] Springer Nature Research Communities. (2025). “Senolytics and the longevity of healthy humans.” https://communities.springernature.com/posts/senolytics-and-the-longevity-of-healthy-humans

[8] Zhang, Y. et al. (2025). “Targeting Senescence: A Review of Senolytics and Senomorphics in Anti-Aging Interventions.” Biomolecules, 15(6), 860. https://www.mdpi.com/2218-273X/15/6/860

[9] Bank of America. (2025). “Longevity Science: How Anti-aging Medicine Is Advancing.” https://business.bofa.com/en-us/content/breakthrough-technology/longevity-science-advances.html

[10] Stanford University. (2025). “Scientists boost lifespan by 70% in elderly male mice using simple drug combo.” ScienceDaily. https://www.sciencedaily.com/releases/2025/12/251202052226.htm

[11] Niazi, S.K. (2025). “Artificial Intelligence in Small-Molecule Drug Discovery: A Critical Review of Methods, Applications, and Real-World Outcomes.” Pharmaceuticals, 18(9), 1271. https://www.mdpi.com/1424-8247/18/9/1271

[12] Kattuparambil, A.A. et al. (2025). “Exploring chemical space for ‘druglike’ small molecules in the age of AI.” Frontiers in Molecular Biosciences, 12. DOI: 10.3389/fmolb.2025.1553667

[13] Model Medicines. (2025). “The Future of Drug Discovery: 2025 as the Inflection Year for Hybrid AI and Quantum Computing.” https://modelmedicines.com/newsroom/the-future-of-drug-discovery-2025-as-the-inflection-year-for-hybrid-ai-and-quantum-computing

[14] Aparicio, A. et al. (2025). “Bridging expectations and science: a roadmap for the future of longevity interventions.” PMC. https://pmc.ncbi.nlm.nih.gov/articles/PMC12213962/

[15] Chen, J.B., Wang, M.C., Gong, S., & Li, H. (2025). “Toward precision longevity: aging interventions in the single-cell atlas era.” Frontiers in Aging, 6. DOI: 10.3389/fragi.2025.1674112

For decades, computational chemistry had a “performance limitation.” Traditional physics-based docking tools like AutoDock Vina and Glide were the gold standard reliable, explainable, but painfully slow. Then came the generative AI wave, promising to solve protein-ligand interactions in seconds rather than hours [1].

Now that we are well into 2025, the hype has settled, and the hard data is in. New benchmarks like PoseX and PoseBench have pitted the latest AI models (AlphaFold 3, DiffDock, Boltz-1x) against the physics-based old guard.

The results are not a simple victory for one side [2]. Instead, they point to a singular conclusion: The future isn’t AI

Here is what the 2025 data actually says and why Pauling.AI’s infrastructure is built the way it is.

1. Performance: AI Is the “Undisputed King”

If your goal is to scan a massive library of 10 billion compounds to find a “general fit,” traditional docking is obsolete.

• The Data: In the 2025 PoseX benchmark, some of AI-driven tools (like AlphaFold3 and Uni-Mol) could demonstrate a significantly higher “success rate” (finding a pose <2Å RMSD) compared to classical force-field methods.[1]

• The Gap: Physics-based tools explore conformational space via sampling (simulated annealing or genetic algorithms), which could be computationally expensive. AI models, treating docking as a geometric deep learning problem, “infer” the pose in milliseconds.

• The Reality Check: For finding a known binding pocket of a target, AI is 1,000x faster.

2. Stereochemical Validity: The Key Weakness of Pure AI

However, speed comes at a cost. The 2025 benchmarks revealed a critical weakness in pure AI methods: stereochemical validity.

• The Data: While AI models often get the RMSD (Root Mean Square Deviation) right, they frequently produce “physically impossible” structures. The PoseBusters benchmark suite highlights that pure generative models often ignore steric clashes, creating atoms that overlap or bond angles that defy the laws of physics.

• The Consequence: An AI might tell you a drug binds perfectly, but if you ran that molecule through a molecular dynamics (MD) simulation, like by GROMACS, the structure would explode. Pure AI lacks an inherent understanding of energy landscapes; it only knows geometric probability.

3. The 2025 Winner: The Hybrid Workflow

This brings us to the most important finding of the year. The highest accuracy scores in 2025 weren’t achieved by AI alone or Physics alone. They were achieved by AI generation followed by Physics relaxation [4].

Recent studies show that when an AI-predicted pose (from a tool like DiffDock) is refined with a quick physics-based minimization step (using a force field), accuracy jumps significantly.

• Why it works: The AI acts as a “hyper-efficient guide,” bypassing the slow global search to find the right energy valley. The Physics engine then “cleans up” the mess, resolving steric clashes and optimizing hydrogen bonds.

• The Pauling.AI Approach: This is exactly why our “AI Chemist” agents don’t just use LLMs. We also integrate Uni-Dock for rapid pose generation and then validate those poses using rigorous MD simulations (GROMACS). We treat AI as the architect and Physics as the engineer.

4. AlphaFold 3 & The “Co-Folding” Era

A special mention must go to AlphaFold 3 and Boltz-1x [3]. In 2025, these “co-folding” models (folding the protein around the ligand) have revolutionized targets where the crystal structure is unknown.

• The Benchmark: While they trail specialized docking tools in known pockets, they are unrivaled for blind docking (where the binding site is unknown).

• The Insight: For targets with high flexibility (induced fit), traditional rigid-receptor docking fails. AI co-folding is the only viable path forward.

Conclusion: Don’t Choose, Integrate.

The “AI vs. Physics” debate is a false dichotomy. The 2025 benchmarks prove that:

1. AI solves the search problem (Speed).

2. Physics solves the validity problem (Accuracy).

At Pauling.AI, we are not building a tool that blindly trusts a neural network. We are building autonomous agents that use AI to hypothesize and Physics to verify compressing years of discovery into days without sacrificing scientific rigor.

References & Further Reading (2025)

• PoseX Benchmark: AI Defeats Physics-based Methods on Protein Ligand Cross-Docking (arXiv:2505.03) [1]. This paper introduced the PoseX dataset, showing AI models surpassing Glide in RMSD accuracy but requiring physics-based relaxation for validity.

• Werner, J. (2025, June 10). AlphaFold 3 extends modeling capacity to more biological targets. Forbes. This article discusses how AlphaFold 3 expands beyond classical protein structure prediction to model a broader range of biomolecular structures, including ligand and ion interactions, greatly extending its applicability in computational biology and drug discovery [2].

• Masters et al. (2025) describe how AlphaFold 3 (AF3) [3] and similar “co-folding” approaches jointly predict protein and small-molecule complexes an ability that aligns with what you describe as “co-folding” (folding the protein around the ligand). This work shows co-folding models can achieve high performance in blind docking tasks (predicting ligand binding without a known pocket) relative to conventional algorithms, highlighting their suitability for targets with unknown binding sites and induced-fit flexibility.

• Gómez Borrego & Torrent Burgas (2025) evaluated protein ligand docking methods and reported that using AlphaFold-predicted structures followed by molecular dynamics (MD) refinement leads to improved docking outcomes, demonstrating how combining data-driven AI predictions with physics-based refinement can enhance the physical realism and predicted binding quality of complexes [4].

• Nature Machine Intelligence: Benchmarking AI-powered docking methods from the perspective of virtual screening (Feb 2025).[5][6][7] Highlighted that while AI is faster, it struggles with “physical plausibility” compared to traditional tools [1].

• PoseBusters: The industry standard for checking if AI-generated molecules obey the laws of physics (no overlapping atoms).

Subscribe to the Pauling.AI blog for data-driven insights on AI-powered drug discovery.

Subscribe now

References:

1. arxiv.org

2. forbes.com

3. nature.com

4. link.spinger.com

5. openreview.net

6. zju.edu.cn

7. researchgate.net

8. zenodo.org

In the Last quarter of the year, we talked with 3 major pharmaceutical companies terminated their long-standing CRO contracts and they are replacing them with AI-Drug discovery technologies that deliver results in days and even just hours, instead of weeks and months. All of this for just 1-10th the cost.

This is not a future trend. Companies using AI for drug discovery are already automating the computational chemistry work that was outsourced just two years ago.

The global AI in drug discovery market, valued at approximately $1.8-3.6 billion in 2024, is projected to grow at a CAGR of 16.5-37.75% through 2035 [1,2,3]. Bimodal AI for drug discovery, combining physics-based methods with generative AI, has deeply changed the economics of computational chemistry.

In the past you needed a team of PhD computational chemists and 6-8 weeks per project; now it can be done autonomously in just a couple of nights.

If you’re still outsourcing early-stage modeling to computational chemistry CROs, you’re not just paying more, you’re falling behind competitors who’ve already made the shift.

Here is the reason why the traditional CRO model is dead, and what’s replacing it.

The Economics That Killed the CRO Model.

For a long time, pharmaceutical companies outsourced computational chemistry for simple reasons: Hiring PhD-level computational chemists costs $98,000-$174,000 annually in the United States ^[4,5], specialized software licenses run another $80K per seat, and building the internal expertise takes a good number of years.

The CRO value proposition was very simple: pay $25K-$100K per project, get expert analysis in 4-8 weeks, no long-term commitments. The global drug discovery services market, which includes computational chemistry CRO services, was valued at $65.84 billion in 2024 ^[6].

The trap and flaw of this model is that it didn’t scale with the pace of modern drug discovery.

A single computational chemist, even the most highly skilled ones, can only analyze 20-50 compounds per week manually. Multiply that across multiple projects simultaneously, add the communication overhead with the client, numerous quality control reviews, and take all of that and you get the industry-standard 6-8 week turnaround time ^[7].

AI drug discovery platforms have shattered this bottleneck entirely.

What usually takes a CRO team 6 weeks now it just happens in 6 hours, What costs $50k per campaign project now costs a fraction through for a platform subscription. What required sequential human decision making docking, MD validation, then ADMET prediction, now just runs as an integrated autonomous workflow with continuous cross-validation.

The math behind it is brutal for CROs: Companies using AI for drug discovery can run 100x more computational experiments per year at 1-10th the cost.

How Generative AI for Drug Discovery Changed Everything

The Goal isn’t just faster computers or better algorithms, it is the fundamental automation of expertise.

Traditional computational chemistry required a human judgement at every step of the journey:

• Which protein conformation is better for docking use?

• Are these binding poses physically possible?

• Do the MD results validate the docking prediction?

• Should we trust this ADMET prediction for a novel scaffold?

Each decision point required a PhD-level computational chemist to interpret results, apply physics principles, and make judgment statements. This is the expertise bottleneck that CROs monetized.

Bimodal AI for drug discovery eliminates this bottleneck by embedding expertise directly into the workflow.

Modern AI drug discovery platforms combine two approaches:

1. Physics-based methods: Provide the rigorous foundation molecular dynamics simulations, quantum mechanical calculations, alchemical free energy methods. These aren’t approximations; they are literally solving the actual equations that govern molecular behaviors. Advanced methods like free energy perturbation (FEP) combined with molecular dynamics can predict binding affinities with chemical accuracy when properly implemented ^[8,9]

2. Generative AI models: Learn patterns from vast datasets of successful drugs, failed candidates, and experimental results. They are able to recognize when a docking pose is an artifact, when MD simulations need longer equilibration, when ADMET predictions are extrapolating dangerously beyond training data. Machine learning models trained on molecular dynamics trajectories can improve binding affinity predictions by incorporating structural dynamics information ^[10,11].

Taken together, these approaches create systems that don’t just run calculations they make expert judgments that used to require years of training.

Why This Transition Is Inevitable

The data just speaks for itself.

Benchmark studies show AI drug discovery platforms matching or exceeding human expert performance on standard computational chemistry tasks. According to recent reports, AI-discovered molecules have shown an 80-90% success rate in phase I clinical trials, substantially higher than previous average outcomes ^[1].

Docking accuracy, binding affinity predictions, ADMET property forecasts AI systems trained on large datasets consistently outperform traditional channels ^[12,13].

But it is not just about accuracy. It’s about consistency, speed, and scale.

A human expert has good days and bad days, makes different judgement calls on similar problems, a human can only focus on one project at a time. An AI system applies the same validation criteria every time, processes thousands of compounds simultaneously.

The economic pressure is inevitable and undeniable. Companies using AI for drug discovery achieve better results faster at lower costs. Competitors clinging to CRO-dependent workflows can’t keep this kind of pace.

The question here is not if the computational CROs are going to adapt, the question here is how long they have before they just become irrelevant.

Most will simply disappear as their client base adopts in-house AI capabilities and CRO contracts expire without renewal.

The Path Forward

For pharmaceuticals and biotech companies still depending on computational chemistry outsourcing, the transition to AI-Powered in house capabilities is really simple

• Start with a pilot on routine virtual screening: Choose an upcoming project that you would normally send to a CRO. Run it through an AI drug discovery platform instead, compare results, turnaround time, and cost.

• Expand systematically to core computational workflows: As confidence in the tool grows, extend AI automation to lead optimization, ADMET profiling, structure based design, Reduce CRO spend gradually, reserving contracts only for truly specialized work.

• Build small internal teams to leverage AI tools: You will notice that entire departments of computational chemists are not necessary. Just a small number of scientists who understand biology and chemistry, empowered with AI platforms, can deliver more than a team of dozens doing manual analysis.

Companies that move quickly will benefit. Their models improve with each experiment, their scientists develop intuition for computational drug discovery, their timelines get tiny while the competitors wait on CRO deliverables.

The companies that delay face a different reality: falling behind on innovation, burning budget on obsolete outsourcing models, watching competitors iterate faster with better results.

Why We Built Pauling.AI

We built Pauling.AI to accelerate how fast scientists can find therapeutic molecules.

We saw incredibly talented scientists spending days setting up simulations, waiting weeks for results, and repeating the same cycles for months all for processes that could be accelerated dramatically.

We also saw companies paying huge fees for computational work that could be automated, and, more importantly, scientific progress being held back by technical limitations that already had solutions.

Pauling.AI is our attempt to solve this: a platform that automates computational drug discovery end-to-end, enabling scientists to go from idea to testable molecule much faster than ever before.

Not by replacing scientific insight, but by handling the computational execution autonomously so researchers can focus on the science that truly requires human creativity and judgment.

The future of drug discovery is about empowering scientists with AI tools that eliminate bottlenecks, accelerate iteration, and make computational chemistry expertise accessible to everyone working to develop better therapeutics.

References

^[1] Global Market Insights. (2024). Artificial Intelligence in Drug Discovery Market Size Report, 2034. The global AI in drug discovery market was estimated at USD 3.6 billion in 2024, expected to reach USD 49.5 billion in 2034 at a CAGR of 30.1%. https://www.gminsights.com/industry-analysis/ai-in-drug-discovery-market

^[2] Roots Analysis. (2025). AI in Drug Discovery Market Size & Share | Industry Report. The global AI in drug discovery market is projected to grow from USD 1.8 billion in 2024 to USD 13.4 billion by 2035 at a CAGR of 16.5%. https://www.rootsanalysis.com/reports/ai-based-drug-discovery-market.html

^[3] Credence Research. (2025). AI in Drug Discovery Market Size, Growth and Forecast 2032. The AI in drug discovery market is projected to grow from USD 835 million in 2024 to USD 10,824.78 million by 2032 at a CAGR of 37.75%. https://www.credenceresearch.com/report/ai-in-drug-discovery-market

^[4] Salary.com. (2024). Computational Chemist Salary. Average annual salary of $98,349 in the United States, ranging from $81,110 to $119,278. https://www.salary.com/research/salary/listing/computational-chemist-salary

^[5] Glassdoor. (2025). Salary: Computational Chemist in United States. Average salary of $173,948 per year, with top earners making up to $275,403 (90th percentile). https://www.glassdoor.com/Salaries/computational-chemist-salary-SRCH_KO0,21.htm

^[6] BioSpace. (2025). AI in Drug Discovery Market Size to Worth USD 16.52 Bn by 2034. The drug discovery market size accounted for USD 65.84 billion in 2024. https://www.biospace.com/press-releases/ai-in-drug-discovery-market-size-to-worth-usd-16-52-bn-by-2034

^[7] Pharmacelera. (2018). Are medicinal chemistry CROs complementing their technology with computational chemistry? Discusses the standard turnaround times and workflows in computational chemistry CRO services. https://pharmacelera.com/blog/publications/are-medicinal-chemistry-cros-complementing-their-technology-with-computational-chemistry/

^[8] Okamoto, Y., et al. (2020). Prediction of Protein–Ligand Binding Pose and Affinity Using the gREST+FEP Method. Journal of Chemical Information and Modeling, 60(11), 5382-5394. Demonstrates improved accuracy in binding affinity predictions using enhanced sampling methods. https://pubs.acs.org/doi/10.1021/acs.jcim.0c00338

^[9] Gleeson, M.P., et al. (2010). Improved Ligand-Protein Binding Affinity Predictions Using Multiple Binding Modes. Biophysical Journal, 98(11), 2682-2691. Shows that molecular dynamics simulations with free energy calculations can greatly increase accuracy of binding affinity predictions. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2877349/

^[10] Ye, Z., et al. (2023). Can molecular dynamics simulations improve predictions of protein-ligand binding affinity with machine learning? Briefings in Bioinformatics, 24(2), bbad008. Demonstrates that incorporating dynamic structural information from MD simulations can improve binding affinity predictions. https://academic.oup.com/bib/article/24/2/bbad008/6995375

^[11] Min, Y., et al. (2024). From Static to Dynamic Structures: Improving Binding Affinity Prediction with Graph-Based Deep Learning. arXiv preprint arXiv:2208.10230. Presents Dynaformer, a graph-based deep learning model that learns from MD trajectories to predict binding affinities with state-of-the-art accuracy. https://arxiv.org/abs/2208.10230

^[12] Aggarwal, R., et al. (2022). PLAS-5k: Dataset of Protein-Ligand Affinities from Molecular Dynamics for Machine Learning Applications. Scientific Data, 9, 548. Demonstrates the role of MD simulations in capturing conformational changes for accurate binding affinity prediction. https://www.nature.com/articles/s41597-022-01631-9

^[13] Raed, A., et al. (2020). Predicting the impacts of mutations on protein-ligand binding affinity based on molecular dynamics simulations and machine learning methods. Computational and Structural Biotechnology Journal, 18, 439-454. Shows that machine learning methods using time-series features from MD simulations outperform traditional methods. https://www.sciencedirect.com/science/article/pii/S2001037019303757

If you haven’t read it yet, check out my previous blog post:

“IF WET LAB VALIDATION IS ESSENTIAL, WHY USE COMPUTATIONAL METHODS IN DRUG DISCOVERY?” https://blog.pauling.ai/p/if-wet-lab-validation-is-essential.

Do you work in a clinic, a pharmaceutical company, or a biomedical research institution? Then you already know the challenge: moving promising therapies to the next milestone faster, with fewer resources and under tighter budgets. One proven way to accelerate progress is by combining experimental assays with computational methods.

Easier said than done, of course.
The ecosystem of computational chemistry and biology is a maze of thousands of standalone tools, each with its own file formats, parameters and quirks. At the same time, the experts who can stitch it all together (fluent in biology, chemistry, biophysics, and IT) are in short supply. Even simple projects can fragment into dozens of brittle steps where a single format mismatch can stop all pipelines.

Three familiar paths and their limits

You might be leading a department in cancer research, neuroscience, personalized medicine, genetic or infectious diseases. Whichever the case, your options probably look familiar.

1. Wet-lab or CRO screening.
Working with small libraries of a few thousand molecules is manageable because scaling to tens of thousands quickly becomes prohibitively expensive (often millions of dollars).
Reliable, but slow, very low diversity and libraries containing millions of molecules for screening are rarely affordable.

2. Computational research via internal research facilities in your organisation.
These teams are often small, juggling more projects than their computational resources allow. Hardware limits and a small pool of costly commercial software* licenses mean only a few workstations are shared across many research projects. Even with access to a local HPC cluster, license restrictions cap performance to a handful of nodes (tokens or CPUs). The size of a library for virtual screening is usually limited to a million per target in calculations, which takes months on workstations. This way stays shallow and correlates poorly with wet-lab results.
Better than nothing, but still slow and constrained.

3. Basic cloud services.
Most cloud services in drug discovery use academic software* via GUI (graphical user interface), but they don’t solve the core issues. Each academic program still needs to be learned and tuned; most services don’t scale well within a project. You are limited to a single protein–ligand docking instead of screening millions.
Good for teaching, but not for production.

What if the bottlenecks disappeared?

Pauling.AI removes these barriers.
It unifies the computational workflow into a single, production-ready environment that automates the multi-step processes of drug discovery. Format conflicts disappear, protocols stay consistent, and workloads scale seamlessly across thousands of CPUs and GPUs via the cloud-enabling virtual screening of hundreds of millions of compounds with MD simulations in days.

An intelligent agent guides the process from a PDB ID or gene name to a CRO-ready hit list, so your team can focus on wet-lab validation. With full automation and scale, computational and preclinical workflows take days, not months or years (bringing therapies to patients faster than ever or securing patents on drug candidates faster than competitors).

*Academic software is often free but runs from the command line and demands programming skills most biomedical researchers lack. Many tools were designed for single academic problems, not interoperability: formats clash, protocols break, and maintaining a stable toolchain becomes a project in itself. Commercial suites are expensive, slow to evolve, and hard to scale. In both cases, you invest months or years in training staff and maintaining infrastructure.

The integration of computational chemistry and biology with traditional experimental techniques significantly accelerates drug development and reduces preclinical research costs by at least an order of magnitude. Despite the growing popularity of computational methods, researchers working in wet labs still frequently question their utility and necessity.

Historically, applied sciences such as biology and chemistry developed separately from information technologies. Education in these fields typically involves basic training in data analysis and visualization tools, rather than extensive training in programming or high-performance computing.

In recent decades, however, science has become increasingly interdisciplinary and more complex, requiring deep specialization. Although biology and chemistry are closely interconnected, computational methods often remain a distinct domain requiring substantial additional training. Despite the emergence of new programs in computational chemistry and biology, there remains a shortage of highly qualified specialists, since training skilled computational biologists or theoretical chemists takes many years.

The situation is complicated further because computational method protocols are often proprietary or insufficiently detailed compared to widely accessible wet lab protocols. This fosters misconceptions that computational approaches can be mastered quickly, leading to frustration and skepticism among wet lab researchers.

A perceived "Holy War" between theoretical and experimental scientists often emerges, where computational methods are criticized as imprecise or inferior to experimental ones. This view, however, is mistaken. Every scientific method has inherent advantages and limitations. If experimental techniques in biology or chemistry were flawless, there wouldn't be numerous complementary approaches (e.g., NMR, X-ray crystallography, TSA, FRET, SPR, circular dichroism, mass spectrometry) for cross-validation.

Experimental methods have clear limitations:
NMR is limited by target size and sensitivity to large protein complexes;
X-ray crystallography provides static structures without capturing dynamic states and physiological conditions;
TSA (Thermal Shift Assay) detects binding but lacks detailed interaction modes or specific sites;
FRET is limited by proximity between fluorophores (~1-10 nm) and does not account for distal effects;
SPR determines binding kinetics but does not directly identify specific binding sites;
Circular Dichroism misses transient intermediate states and minor structural variations.

Computational approaches, however, face more complex challenges. There are hundreds of software packages, making even experts struggle to navigate the available options. Computational tools vary widely in accuracy (quantum chemistry, semi-empirical, empirical, and machine learning) and physical parameters considered (solvent, pressure, temperature, ionic strength, dynamics). Standard computational research involves molecule preparation, modeling, docking, molecular dynamics simulations, and results analysis. The quality of computational results heavily depends on carefully chosen software protocols and algorithms.

Nonetheless, computational methods complement experiments by interpreting interactions at the atomic level, clarifying molecular mechanisms that might remain obscure experimentally.

Modern machine learning (ML) methods in computational biology and chemistry hold tremendous potential but aren't yet standalone solutions. The primary limitation is not the ML algorithms themselves, but the quality and consistency of experimental data used for training. Experimental results vary significantly due to differences in equipment, protocols, and conditions. Protein structures are dynamic, existing in various conformations (open, semi-open, closed active sites), often inadequately represented in databases. Additionally, conformational changes upon molecular interactions are rarely included in available datasets.

Despite these limitations, intelligent integration of machine learning with computational and experimental methods already yields high-quality analytical and predictive results, significantly accelerating research and drug discovery.

Ultimately, the future of biological research and drug discovery lies in the effective integration of experimental and computational methods. Only this combined approach leverages the strengths of each method, ensuring the highest possible accuracy, deeper insights, and reliability of scientific outcomes.

In this post, I’ll share how we benchmarked different CPU architectures on Google Cloud using a real-world cheminformatics pipeline, and how switching architectures with a single-line tweak in our container build process slashed our compute costs without modifying the application logic.

If your workloads are CPU-bound and containerized, this small optimization might translate into substantial savings at scale.

Share

Context and Motivation

One of the most common steps in cheminformatics workflows is converting SMILES strings into three-dimensional molecular structures. While this step is relatively inexpensive at small scale, it becomes significantly more resource-intensive when applied to millions of compounds.

Because scientific workloads are not always optimized for a single CPU architecture, I wanted to compare four machine types available on Google Cloud (each with 4 vCPUs and similar hourly prices):

• AMD (c4d-highcpu-4)

• ARM (c4a-highcpu-4)

• Intel N1 (n1-highcpu-4)

• Intel N2 (n2-highcpu-4)

Note: All machines used had 4 vCPUs, but differed in CPU architecture, memory configuration, and performance characteristics.

For further details, see Appendix A (Machine Specs) and Appendix B (Pricing).

The goal was to determine which of these options offers the best performance per dollar, rather than focusing purely on execution speed.

Machine naming convention:

For simplicity and readability, the following shorthand will be used throughout this text to refer to the machine types:

AMD → c4d-highcpu-4

ARM → c4a-highcpu-4

INTEL_1 → n1-highcpu-4

INTEL_2 → n2-highcpu-4

Benchmark Design

We used a curated set of 1131 FDA-approved molecules from the Enamine catalog, representative of real-world pharmaceutical research scenarios. These molecules provide structural diversity and clinical relevance, making them an excellent test case for benchmarking performance.

The pipeline was run multiple times on each architecture under consistent conditions in the us-central1 region.* For each run, we measured:

• Total execution time

• Environment startup time

• Estimated job cost, based on hourly pricing for each machine type

These raw measurements were then used to compute the key performance and cost-efficiency metrics presented in the next section, including per-molecule cost and overall throughput.

*This region was selected because it is one of Google Cloud’s most commonly used and broadly available zones, with wide support across all CPU architectures.

It also provides a balanced baseline in terms of latency, resource availability, and pricing consistency.

Choosing a general-purpose region like us-central1 helps ensure that the comparison reflects typical production conditions and is reproducible by other users.

Evaluation Metrics

To evaluate performance and cost, I focused on six primary metrics:

• Average execution time per job (in minutes)

• Average startup time (in minutes)

• Average cost per job (in USD)

• Average cost per molecule (in USD)

• Net processing cost per molecule (in USD)

• Efficiency (mol/min/$)

The net processing cost per molecule excludes the initial environment startup time from the total job duration. It is calculated as:

(Elapsed time − Startup time) × Price per hour / Number of molecules

This is particularly important because in real-world drug discovery workflows, pipelines often run for hours or even days, processing millions of molecules. In those scenarios, the fixed startup time becomes negligible. By removing that overhead, this metric provides a more realistic estimate of true compute efficiency per molecule, especially for high-throughput production settings.

The efficiency is defined as:

Efficiency = Molecules processed / (Net processing time × Cost)

This metric captures both speed and cost-efficiency, rewarding architectures that process the most molecules in the shortest time for the lowest total cost.

Rather than isolating speed or pricing alone, it helps identify the best return on investment (ROI) in compute resources, which is especially relevant in large-scale molecular pipelines, where cost per molecule and throughput per dollar are critical factors for controlling infrastructure spending.

Switching Architectures: Just a Few Lines of Code

One of the most surprising takeaways from this experiment is how minimal the effort was to switch architectures and reap the cost savings.

All it took was:

• Updating the Dockerfile to target the new architecture (e.g., using --platform=linux/arm64 for ARM)

• Rebuilding the container image

• Redeploying the pipeline with the corresponding machine type (e.g., c4a-highcpu-4 for ARM)

There were no code changes required in the application logic. The underlying pipeline, including scientific libraries and dependencies, worked seamlessly across architectures thanks to multi-arch support in modern container toolchains.

If you're already using containers, this optimization could be just a one-line change in your build or deploy script, and worth thousands in compute savings at scale.

To take it a step further, we built a single multi-architecture Docker image using docker buildx, compatible with both ARM and x86 platforms.

This approach simplifies deployment, reduces architecture-specific bugs, and ensures portability across AMD, Intel, and ARM environments.

Bonus: How We Handle Multi-Architecture Builds

To make our pipeline portable across ARM and x86 machines, we configure our builds using Docker Buildx, and conditionally install architecture-specific binaries inside the container, such as the Micromamba distribution for linux-aarch64 or linux-64.

We also use ARG TARGETARCH in the Dockerfile to detect the build architecture and fetch the right version of tools like Micromamba. This allows us to install Open Babel and other dependencies reliably regardless of CPU type.

In our Google Cloud Build config, we dynamically install Buildx (if needed), create a builder, and then push a multi-platform image that works across all CPU types:

```yaml

--platform=linux/amd64,linux/arm64

```

Combined with a conditional logic block in the Dockerfile:

```dockerfile

ARG TARGETARCH

...

if [ "$TARGETARCH" = "arm64" ]; then ARCH=linux-aarch64; else ARCH=linux-64; fi

```

we ensure full compatibility without maintaining separate Dockerfiles for each architecture.

This approach keeps builds deterministic, avoids surprises, and allows any team member to deploy or test on any platform, without special configuration.

From Metrics to Results

With all evaluation criteria clearly defined, we applied them to benchmark the performance of the four selected architectures. Each job processed the same 1,131 FDA-approved molecules, and the pipeline was executed under consistent configuration and region settings.

The aggregated results per architecture are shown below, providing a comprehensive overview of how each machine type performed in terms of time, cost, and overall efficiency.

For visual comparison, see Appendix C: Metric Visualizations

Large-Scale Benchmark: One Million Molecules

While the 1,131-molecule benchmark is useful for quick comparisons, real-world drug discovery workloads often involve millions of compounds.

To test how our findings hold at production scale, we repeated the same benchmark with 1,000,000 ligands, under identical conditions and pipeline logic.

For visual comparison, see Appendix D: Metric Visualizations

Conclusion

Across all metrics evaluated, the picture now depends on scale:

Small-scale benchmark (1 131 molecules).

The AMD (c4d-highcpu-4) instance once again outperformed the alternatives, offering the best balance of execution speed, cost-efficiency, and overall molecular throughput. ARM (c4a-highcpu-4) followed closely in cost-effectiveness, making it a viable secondary option.

Large-scale benchmark (1 000 000 molecules).

When we pushed the pipeline to production scale, ARM moved into first place: it completed the job about 5 % faster than AMD, drove the job cost down by roughly 7%, and delivered ~13 % more molecules-per-minute-per-dollar. AMD remained a very strong performer, but ARM now offers the best return at this workload.

In contrast, Intel-based instances (n1 and n2 families) continued to show substantially higher execution times and costs, resulting in markedly lower efficiency per dollar in both tests.

If your workloads are similar (CPU-bound, highly parallelizable, and run at the million-ligand scale) I recommend testing ARM-based instances first. For smaller batches or situations where x86-64 compatibility is critical, AMD remains an excellent choice.

These findings demonstrate the value of benchmarking real workloads across architectures and at the right scale. Small differences in pricing and speed can scale into significant cloud-cost savings (or overruns) when a pipeline moves to production.

Appendix A: Machine Specs

Appendix B: Pricing

Appendix C: Metric Visualizations

Appendix D: Metric Visualizations

In this space you’ll get blunt dispatches from the trenches: what actually works in AI‑driven docking and MD, the ROI math on GPU vs. wet‑lab runs, hard‑won regulatory shortcuts, and the occasional teardown of industry hype. If you’re building, funding, or just cheering for faster therapeutics, bookmark us, challenge us, and let’s push the frontier of biotech together.

Subscribe now