Meet Indy: an AI agent designed by medicinal chemists to do medicinal chemistry

Today we’re launching Indy, Inductive’s medicinal chemistry agent. We started building it a year ago to help our scientists support a growing number of drug discovery programs for our partners. It now handles much of the routine work on those programs, from QC-ing assay data and monitoring the synthesis queue, to launching FEP, projecting human dose, and making meeting-ready SAR and synthesis slides. Our scientists have doubled their productivity with it, and some beta customers are approaching 20 hours per week of usage.

Indy was designed by medicinal chemists to do medicinal chemistry. It lives inside Compass, our small molecule design and discovery platform, and outperforms frontier agents like Claude and GPT on a wide range of drug discovery tasks. In this post we compare all three agents on two of those tasks, dose-response data QC and routine medchem design moves, then show what a design session with Indy looks like. To skip to the Indy preview, jump to Designing compounds with Indy.

‍

Key Takeaways

1. Indy is twice as accurate as the latest Claude and GPT agents at identifying data QC issues. On a curated hold-out set of 84 dose-response curves from real programs, Indy QC’d 89% correctly against 39 to 48% for GPT-5.6 Sol and Claude Opus 5. 
2. Indy also beat the latest Claude and GPT agents at executing routine medchem moves like nitrogen walks. Asked to replace a bicyclic core with 71 alternates, Indy returned 57 of 59 valid products. GPT returned 36. Claude returned 686, only 52 (7.6%) of them valid.
3. Judgment, not raw intelligence, is the bottleneck for AI agents on small molecule programs. Claude and GPT will tell you N,O-hemiaminals are unstable in water, then propose them without comment in a substituent walk. Indy will flag them and recommend excluding them.
4. We taught Indy medicinal chemistry by using it to do medicinal chemistry. Interviews with our drug hunters and partner teams got us started, but Indy’s judgment came from supporting dozens of live programs. When Indy makes a mistake, we find out immediately and fix it because our own work depends on it.

We built Indy to do our own science

Our medicinal and computational chemists led small molecule programs in industry for decades before joining Inductive. For the past several years they’ve embedded with our partners’ discovery teams through our Embedded Experts collaborations, providing the medchem, compchem, and DMPK support that gets DCs delivered on tight timelines. From the beginning we used LLMs, and eventually agents, to accelerate that work, and trial and error across dozens of live programs taught us which agentic capabilities deliver real value today, and which don’t. We shared those lessons in a talk picked up in a recent Drug Hunter article. The tools we built for ourselves along the way became Indy. Today it is the primary way we do drug discovery. We use it to: 

{{indy-ul}}

Each of these started as something one of our chemists needed on a live program. Parsing CRO reports, digging through historical SAR, setting up FEP calculations, and making slides now take minutes instead of hours, so our chemists ask more questions, run more experiments, and propose more and better molecules.

Under the hood, Indy uses frontier LLMs (we’re provider-agnostic) in a chemistry-native harness we built ourselves. The harness connects Indy to Compass, our small molecule design platform, and lets it work the way chemists do: reading and drawing structures in chat, rendering molecules in tables, figures, and plots, parsing and exporting ChemDraw files, and querying SciFinder and ChemAIRS. A deep library of skills orchestrates Indy’s capabilities, encoding where, when, and how to apply each one. Our veteran medicinal and computational chemists write those skills and refine them continually. We can’t cover all of them in one post, so below we go deep on two workflows: QC-ing dose-response data and common analog design strategies.

Scrutinizing data like a medicinal chemist

Why data QC is expensive but necessary

Catching data quality issues early prevents unforced errors. A dubious result that gets acted on doesn’t cost one experiment. It costs the design cycle built on it, roughly 4 to 8 weeks of synthesis and assay turnaround. If the result anchors a new series, several cycles can pass before the SAR stops making sense and someone goes back to the raw data.

Proper QC is expensive, though, even when narrowly scoped to dose-response data, because (to borrow from Tolstoy) all clean curves are alike; each ugly curve is ugly in its own way. A reported IC50 can be wrong in more ways than any single check can catch, and none of them show up unless you inspect the raw data. The trickiest cases are curves that look fine in isolation but suspicious in the context of the compound’s historical runs or its data in other assays (e.g. low solubility or aggregation artifacts). Catching those means extra legwork when nothing in front of you looks wrong. 

Imagine you are a cell biologist responsible for processing ~100 curves this week. You’re clicking through them one by one in the assay reporting software, moving fast because next week’s experiment still needs setting up and the chemists have been asking how potent their compounds are. You see a beautiful, complete curve that the software auto-fit cleanly. You have two choices: (1) call it good and move on, or (2) dig up the historical data for this compound and verify the repeat is within the assay’s expected noise.

Figure 1 is what option (2) turned up on a real partner program in early hit-to-lead: a prior run of the same compound in the same assay was 3.6x less potent. Both curves look legitimate on their own, and the newer one breaks the 1 μM barrier. Take option (1) and the new value goes into the database without comment. A chemist reads the summary report, requests early ADME profiling, and spends the next week designing and planning routes for new analogs. No one catches the plating error that “increased” the potency of every compound in the bottom few rows of the plate.

Even a compound’s first time through an assay deserves a look beyond the curve. Does its shift from biochemical to cell potency match the rest of the series? If not, permeability or FBS binding data is the first diagnostic for whether it reached the target at all. Checks like these go beyond basic QC, but without them you can’t understand the data you’re looking at. The time they cost is paid by the people generating, fitting, and using the data, and under timeline pressure things fall through the cracks. We’ve all been burned by specious data before, so we invested in these capabilities early, and today data QC is a core Indy workflow.

A repeat that disagrees with history is one of the easiest checks to run, and as we show below, general purpose agents run it nearly as well as Indy does. The checks they struggle with are the ones that require judgment and scrutiny of the curve itself.

How Indy flags ambiguous data

Concentration-response data is usually fit with a 4PL curve under constraints encoding the team's expectations about things like the maximum possible effect or the stoichiometry of the compound-target interaction. The fit produces an xC50 (x = I for inhibition assays): the concentration at which the compound reaches 50% activity, either absolute or relative to its own maximum effect. The xC50 is the main thing chemists look at when interpreting results. Sometimes it’s the only thing. But whether you can trust a reported xC50 depends heavily on data quality (Figure 2).

When data is messy, the “correct” value to report is often a judgment call: a single best-guess value (e.g. 150 nM), a qualified value (e.g. > 300 µM), or no value at all. Values can also carry annotations for the chemists who will act on them: “incomplete curve”, “max inhibition > 100%”, “high concentration data excluded from fit”. These calls are the most expensive part of QC. At Inductive, Indy takes the first pass on every program we support (Figure 3). We still look at raw data with our own eyes, but Indy’s reports focus that time on the most ambiguous, highest-impact cases.

Comparison to general purpose frontier agents

To compare Indy’s QC performance against general purpose agents, we ran the same task through Claude Code (Claude Opus 5) and Codex (GPT-5.6 Sol). Two notes on experimental design, given what was available at the time: (1) we tried to evaluate Anthropic’s Fable-class agents, but they refuse any task involving chemical structures, and (2) Claude Science was available but Rosalind Workbench was not, so for consistency we tested the general purpose harness for both.

The test set was 84 recent anonymized dose-response inhibition datasets (datapoints plus fitted IC50s) from Inductive-supported programs, curated to cover common data quality issues. Of these, 72 carried at least one real problem across eight categories (low solubility artifact, hook effect, nonzero baseline, max inhibition well past 100%, IC50 extrapolated past the tested range, disagreement with historical runs, noisy technical replicates, Hill slope far from 1), and 12 were clean. Many carried more than one problem. Ground truth was the set of annotations and quality flags recorded by the external teams supporting those programs. Indy had no prior exposure to the hold-out data and ran with its default QC sensitivity settings.

We scored each agent on three metrics:

• Accuracy: the % of all 84 curves the agent got right. A problem curve counts as right if the agent flagged at least one of its real problems, which is enough to get it looked at. A clean curve counts as right if the agent called it clean.
• False negative rate: the % of the 72 problem curves on which the agent flagged none of the real problems. This is the failure we care most about: the bad curve goes into the database unremarked and gets acted on.
• False positive rate: the % of the 12 clean curves the agent flagged as problematic.

Each agent got the same two files (the 84 “new” curves and historical curves from the same programs) and the same prompt:

Indy scored 89% accuracy. GPT-5.6 Sol scored 39 to 40% and Claude Opus 5 scored 46 to 48%, depending on thinking effort (Table 1).

The gap is almost entirely false negatives. Indy missed 6% of problem curves; the frontier agents missed 58 to 71%. Indy’s false positive rate was higher, 42% against 0 to 25%. A skeptical reader might ask whether Indy is more accurate or just more trigger-happy. Per-flag precision (the % of flags that identify a real problem) answers that: Indy’s was 62%, in the same range as the frontier agents’ 56 to 67%, which is not what a trigger-happy agent would score. 

To test whether better prompting would close the gap, we re-ran every agent with a checklist prompt: the original request plus the eight issue categories to check for. Every agent improved. The frontier agents rose to 57 to 69% accuracy. Indy rose to 93%. Indy without the checklist still beat every frontier agent with it.

Figure 4 breaks this down by issue type. Without the checklist, the frontier agents caught two issues reliably: IC50s that disagreed with history and noisy technical replicates. Claude caught every curve with max inhibition above 100% and GPT caught 44% of hook effects. Both missed every nonzero baseline and Hill slope issue, and nearly every low solubility and extrapolated IC50 issue (Claude caught 8% and 12%, respectively). The checklist fixed most of that, but not extrapolated IC50s: told to look for them, the frontier agents still caught at most 19%. Indy caught 100% of them under both prompts, and matched or beat the best frontier agent on every check but one, hook effect without the checklist.

From flags to recommendations: how Indy learns a team’s QC rules

The 42% false positive rate in Table 1 reflects Indy’s out-of-the-box sensitivity, not a fixed property. Teams differ in which flags they want, how sensitive each should be, and what a flag should trigger downstream (a repeat run, progression to the next assay). Those preferences also vary by assay, with more noise tolerated in a cellular PD assay than in a biophysical binding assay. Indy knows the full catalog of potential quality issues, but it calibrates its tolerances and reporting from team feedback like:

• “3-fold noise is expected in this assay” 
• “There’s no theoretical upper limit in this cell activation assay”
• “Please refit and record both absolute and relative AC50s for this assay”
• “Please label IC50 values as on- or off-target based on activity in the control cell line”
• “Don’t flag issues like this in the future” 
• “Report all compounds with potency better than 100 nM for repeat runs”
• “Report all clean compounds we should submit to tier-1 ADME”
  

Indy proactively encodes this type of feedback in its context and skills, so it adapts to each team and evolves with the program: triaging issues from new assays as they come online and automating compound nominations for whatever experiment comes next. The right panel of Figure 5 shows what that looks like in practice: a noisy-baseline flag Indy raises by default, downgraded to low priority by the team’s rules so the compound moves on to ADME.

Designing like a medicinal chemist

Generative design gets a lot of attention, and we use it more and more on the programs we support. Day to day, though, teams still lean on a core set of design moves that have been in the medchem toolkit for decades. They have simple-sounding names (nitrogen walk, substituent scan, core hop) but are surprisingly hard for agents. By an agent’s standards, Chemists requesting them “underspecify” the desired output. “Do a nitrogen walk on the core” assumes the listener can identify the core, knows which positions are in scope, and knows which products aren’t worth progressing. Chemists don’t spell these things out for one another, but working with agents quickly reveals how much scientific collaboration runs on shared tacit knowledge.

Over a year of using Indy on partner programs, our chemists encountered many such gaps, and we closed them with new tools, skills, or interface features that encode the missing judgment. We recently evaluated Indy, Claude, and GPT on three of these workflows and found that Indy reliably exercises the judgment the frontier agents miss. Figure 6 shows characteristic examples, and the following sections give the details.

Nitrogen walks

{{indy-prompt-1}}

Every agent correctly identified the indolizine core of this relatively simple parent, though only Indy asked for confirmation of its core assignment before enumerating. As Figure 6 shows, every agent proposed the single nitrogen additions. Indy alone went on to move the existing bridgehead nitrogen. Claude also proposed several multi-nitrogen insertions, out of scope under typical N-walk convention. They are stable and synthesizable, but they aren’t what was asked for and would need manual filtering before moving forward.

Hydroxyl walks

{{indy-prompt-2}}

This prompt puts the whole molecule in scope, so no core inference is needed, but agents still have to infer where OH addition is chemically possible and which products are too unstable to make. Every agent proposed the straightforward OH additions (Figure 6), and Claude again added several synthesizable but clearly out-of-scope products (e.g. gem-difluoro addition). More consequentially, Indy flagged the positions where OH addition creates N,O-hemiaminals, which are unstable in water and widely avoided by medicinal chemists. Claude and GPT proposed them without comment at both effort levels, leaving it to the chemist to notice them in the product list. One that reaches the queue unnoticed costs a synthesis slot, plus however long it takes to realize the assay data describes a different compound.

Core hops

{{indy-prompt-3}}

Along with the parent SMILES, this prompt supplied an SDF file of 71 fused 5,6-ring systems as candidate replacements for the indolizine core. By medchem convention, a core hop between ring systems of the same size and aromaticity must preserve the parent core’s relative attachment-site pattern, because that substituent geometry is what binds the target. Indy and GPT returned only valid core hops that preserved it: 57 and 36, respectively, out of a possible 59 (Figure 7). Indy was the only agent to ask for confirmation of this constraint before enumerating, though GPT appears to have inferred it. Claude did not. It returned 686 products: 52 valid (7.6%), 52 with swapped substituent mappings, and 582 invalid (84.8%). Every agent returned cores that were technically valid but carried downstream risk (Figure 6). Only Indy flagged those risks, e.g. benzofuran’s metabolic liability (product cLogP > 5) and bioactivation potential, and recommended dropping those cores. Unflagged, liabilities like these surface much later in ADME or safety assays, by which point they may already be built into a lead series.

The same difference, across three tasks

The gaps between agents were consistent across all three tasks, and none came down to missing facts. Ask Claude or GPT directly whether N,O-hemiaminals or benzofurans pose liabilities in small molecule discovery and you’ll get a correct answer. The difference is tacit knowledge: knowing which facts matter for which workflow in which situation. Given an underspecified prompt, Indy drew on that knowledge and asked for confirmation. The other agents made undisclosed assumptions and ran with them.

Claude and GPT erred in opposite directions: Claude consistently overshot the request, while GPT stopped short of covering it. Our chemists judged that no agent produced perfect output on any task, but Indy’s came closest to design-meeting ready, needing only yes/no calls on a few explicitly flagged products. The other agents’ output was a starting point, needing expansion (GPT) or triage (Claude) before it could be presented. On an active program these tasks come up weekly, which makes that expansion and triage a standing cost.

Designing compounds with Indy

On a live program, the three design moves above are one step in a longer cycle. Chemists review program status, analyze the existing SAR, design new compounds against it, triage the designs on predicted properties, potency, PK, human dose, or synthetic feasibility, then submit for synthesis and track progress. Indy runs every step in one session, inside Compass, with a secure feed to the program’s experimental data so it knows when new results land. Below is one pass through that cycle using published data from a SARS-CoV-2 Mac1 program run by our collaborators at UCSF.

High-level program update

SAR summary

Ligand conformational analysis

Matched pair analysis

R-group enumeration

Reaction-based enumeration

Generative design 

Potency prediction with FEP 

In vivo PK prediction

Human dose projection

Retrosynthetic analysis 

Literature precedent search

Synthesis queue monitoring

Judgment is that which is scarce

The title of this section adapts economist Tyler Cowen’s maxim that context is that which is scarce. Building Indy has convinced us that on live small molecule programs the scarce resource is judgment: not facts, but knowing which facts matter for the curve, molecule, or in vivo study in front of you. That is what frontier agents are missing today, and the QC comparison shows it directly. A checklist raised the frontier agents’ accuracy by 17 to 29 points, yet they still let 6 to 8 times as many bad IC50s into the database as Indy did with no guidance at all. The checklist told them what to check. It did not teach them how to look at a curve like a medicinal chemist.

The same is true of human scientists. Ask a fresh PhD chemist why an inhibitor is 10 nM in the biochemical assay but 2 µM in cells and you’ll get a list of possible explanations: poor permeability, efflux, competition with endogenous substrate, and, if they’re sharp, serum protein binding or low target expression in the cell line. Ask a seasoned medicinal chemist and they’ll look at the potency data across both assays, consider the scaffold and the assay conditions, and tell you the one experiment to run next. They’ve seen it before, and they remember it because their program’s success depended on figuring it out.

Getting that kind of judgment into Indy meant asking our own drug hunters to write down what they’ve seen, what they know, and the mental models and heuristics they’ve developed over time. It meant having Indy ask each project team we support about their optimization philosophies and hard-won best practices. Indy asked more questions than the other agents did throughout our evals because we built it to seek out and adopt the judgment of its collaborators.

But interviewing chemists only got us so far. To borrow from Mike Tyson: everyone has a plan until they get punched in the mouth. Medchem expertise written down in the abstract is a reasonable-sounding plan, but we’ve rarely seen them survive unscathed when reduced to practice. Ultimately, we taught Indy medicinal chemistry by using it to do medicinal chemistry.

Indy is the tool our chemists use every day to move dozens of diverse programs toward DCs. When one of its heuristics, models, or judgment calls fails on a program, we find out immediately and fix it, because our own work depends on it. Without that persistent dogfooding, Indy wouldn’t have the judgment it has today. Foundation models will keep improving at scientific tasks, and Indy improves with them, since our harness and interface sit on top of them.

We built Indy to do our own science. We didn’t take a coding agent and shoehorn it into scientific workflows. It’s now available to teams outside Inductive. Want to see what it does with your program? Come talk to us.