Automated De Novo Protein Design Optimization

De novo protein design has advanced rapidly through generative models: diffusion-based structure generators (Proteina-Complexa, RFdiffusion), structure predictors (AlphaFold2, RoseTTAFold3), conformational samplers (BioEmu), and inverse folding networks (ProteinMPNN, LigandMPNN). These models are powerful. But using them to produce high-quality binders for a specific target requires searching over dozens of inference-time hyperparameters: beam search width, checkpoint schedules, branching factors, scoring model choice, refinement strategies, and more. No single default configuration works across targets. The search is high-dimensional, target-dependent, and expensive.

We frame this as an inference-time optimization problem. The trained model weights are fixed. The agent's job is to find the best way to run the model for each target. LLMs can act as the brain that connects to and orchestrates protein design models, turning what was a manual trial-and-error process into a closed-loop optimization.

Proteina-Complexa pipeline: flow-matching generation with beam search and inference-time scoring. The agent optimizes the hyperparameters at each stage. Figure from NVIDIA Proteina-Complexa.

Four generations of the agent, laid out by what the LLM actually writes and whether it reasons about one protein or a whole protein set at once. v3 and v4 both evolve an inference program — the difference is scope.

The agent minimizes i_PAE (binding quality) while maintaining high pLDDT (fold confidence). Example on the CD45 target (hardest, largest improvement):

Motivation: Good Models Need Good Hyperparameters

We ran 50 experiments (5 beam search configs × 10 protein targets) with Proteina-Complexa. The results make the case clearly:

step_checkpoints = [0, 100, 200, 300, 400]

Checkpoint 0 (pure noise):
  Initialize beam_width × nsamples noise samples

  ── Denoise steps 0 → 100 (partial simulation) ──

Checkpoint 100:
  BRANCH: duplicate each beam into n_branch copies
  LOOKAHEAD: roll out each copy to step 400 (completion)
  SCORE: evaluate i_PAE on completed structures
  SELECT: keep top beam_width candidates per sample

  ── Continue denoising 100 → 200 with selected beams ──

Checkpoint 200:
  BRANCH → LOOKAHEAD → SCORE → SELECT

  ...repeat at each checkpoint until step 400 (final)

[Target PDB + Hotspots] → Flow Matching (400 steps) → Beam Search → AF2 Scoring → Candidate PDBs

Agent Loop v1: Closed-Loop Hyperparameter Search

Optimization Trajectories

Each target shows a clear improvement trajectory. The agent achieves 10–28% improvement in best i_PAE from baseline:

v1 Results and Reflection

The agent achieves 10-28% improvement on every target, but the search strategy has clear limitations:

Full interactive dashboard with per-run details and Plotly visualizations →

v2 Plan: From Configs to Programs

v1 showed that the agent loop works and that how you spend compute matters more than how much. The question for v2: what if the agent could compose programs instead of picking configs?

Experiment: Graphify for Codebase Understanding

A key bottleneck for the agent is understanding the Proteina-Complexa codebase well enough to reason about which parameters exist, how they interact, and what new configurations are possible. The codebase has thousands of lines of Hydra configs, model definitions, and pipeline scripts. Reading these files sequentially is slow and loses structural relationships.

We will test whether Graphify, a tool that converts code, documentation, and configs into a knowledge graph with clustered communities, can help. The idea:

Orthogonal Experiments Backlog

Items about program representation, deduplication, 80+ parameter surface, population-based search, and LLM-vs-BO benchmarking have moved to v3, which now owns them. What remains here is the orthogonal experiment backlog — work that is not about the agent loop itself but about the downstream pipeline, conformational robustness, scoring models, and codebase tooling.

v3: From Programs to Ideas + Programs

v2 asked: what if the agent composes programs instead of picking configs? v3 asks a tighter question: what if the agent also evolves the scientific ideas behind those programs, and the search tree knows about both? v3 is an explicit implementation of the SCORE decomposition (Aygun et al. 2025), narrowed to Proteina-Complexa inference-time binder design.

The Six Primitives

The v3 loop makes every SCORE primitive a first-class host object. Each expansion step touches all six:

Research Ideas as First-Class Objects

The most important conceptual shift from v2 is that a ResearchIdea is not code, not a program, and not a prompt fragment. It is a persisted, hashable, recombinable hypothesis object with its own lineage. Every program in the tree points back to one or more ideas, and mutations are typed by what they do to those ideas.

ResearchIdea:
  idea_id
  title
  summary
  hypothesis
  implementation_hints
  source_type  # user|llm|paper|recombination
  parent_idea_ids
  tags

Content-Addressed Program Identity

Every persisted artifact in v3 has a content hash, and program identity folds the idea choice directly into the program:

spec_hash    = sha256(canonical(ProgramSpec \ {lineage_fields}))
bundle_hash  = sha256(canonical(CodeBundle))
program_hash = sha256(spec_hash + bundle_hash)
program_id   = program_hash[:12]

# selected_idea_ids ∈ spec_hash
# ⇒ picking different ideas yields a different program_id
# ⇒ the tree dedupes on (ideas + code), not code alone

This is what makes the joint search state above tractable: nodes are still program-centric for deduplication, but the expansion policy can reason about ideas separately because the idea choice is already baked into the identity.

Implementation Status

v3 lives at Autoresearch_Denovo/autoresearch_v3/ as a standalone package with its own Plan.md, ImplementationSpec.md, and pyproject.toml. Snapshot as of 2026-04-14 (verified by reading each module):

First end-to-end dry-run (2026-04-13)

The scratch dirs capture a real run of the full loop: host registers a ScorableTask for PD-L1, seeds an IdeaBank, the mutator (via StaticJSONClient) emits a ChildProposal with a generated reranker asset, the validator passes the program, the compiler resolves the module manifest, the executor materializes it into a sandbox, and the evaluator + tree record the result. This exercises every host object in the six-primitives diagram above.

SCORE View: Live Search Tree

The SCORE view is an interactive HTML report generated from run_store/v3/tree.json. Each node is a candidate inference program; edges trace parent-child mutations. Clicking a node reveals its research ideas, generated code with syntax highlighting, parent-child diffs, pipeline stages, and execution diagnostics. Below is the current v3 tree topology (5 nodes across 3 independent seed roots, 2 evaluated).