AutoSci: Memory-Centric Research Automation

• AutoSci is a memory-centric research automation system designed for full-lifecycle support from literature review to rebuttal.
• It features four modules—SciMem, SciFlow, SciDAG, and SciEvolve—that ensure persistent memory, structured execution, multi-agent coordination, and continual self-improvement.
• Case studies in GPU optimization and biomedical drug discovery demonstrate its capability to integrate iterative workflows with reproducible, stateful research processes.

AutoSci is a memory-centric agentic system for automating the full scientific research lifecycle. It is presented as a persistent research environment rather than a single-purpose research assistant or a one-shot paper generator, with the explicit aim of supporting full-lifecycle support, an execution harness, structured and persistent memory, and self-evolution across research projects. The system is organized around four modules—SciMem, SciFlow, SciDAG, and SciEvolve—which together are intended to let it execute, remember, and evolve across long project horizons (Qian et al., 29 May 2026).

1. System definition and research scope

AutoSci is designed around a systems-level view of scientific work. In this view, research spans literature collection and synthesis, hypothesis or idea generation, novelty and feasibility screening, experiment planning and execution, result analysis, manuscript writing, and review response or rebuttal. The paper argues that automating science therefore requires more than a stronger LLM or a larger toolset: it requires a unified environment that can preserve state, coordinate intermediate artifacts, and improve its own procedures over time (Qian et al., 29 May 2026).

The system targets four requirements. First, it aims at full-lifecycle support, covering the pipeline from literature understanding to rebuttal. Second, it provides an execution harness with persistent state, verification gates, controlled context, and resumable orchestration. Third, it uses structured and persistent memory represented as typed, linked scientific objects rather than flat logs or undifferentiated text. Fourth, it incorporates self-evolution, meaning updates to system skills, workflow protocols, and operator templates rather than only accumulation of experience in memory (Qian et al., 29 May 2026).

This positioning also clarifies what AutoSci is not. It is not framed as a narrow literature assistant, not as a project-local paper-production pipeline, and not as a workflow that begins and ends within a single run. A plausible implication is that AutoSci’s central novelty lies in treating scientific automation as a persistent infrastructure problem rather than as a sequence of isolated prompts.

2. Core architecture

AutoSci is organized around four modules: SciMem, SciFlow, SciDAG, and SciEvolve. In version 1.0.0 (May 2026), the implemented scope includes 4 modules, 2 persistent memory regions, 10 typed entities, 20+ typed relations, a /research workflow spanning literature → ideation → experiment → writing → rebuttal, 30+ skills, 9 reusable multi-agent operators, and 3 evolution skills (Qian et al., 29 May 2026).

Module	Primary role	Key mechanisms
SciMem	Schema-governed scientific memory	Long-Term Knowledge Memory and Active Research Memory
SciFlow	Lifecycle execution harness	State, context, verification, feedback, orchestration
SciDAG	DAG-based multi-agent augmentation	Reusable operator graphs and stage-aware templates
SciEvolve	Full-system evolution	/dream, /forge, /morph

The interaction pattern is explicit. SciMem stores long-term knowledge and project-specific active artifacts. SciFlow runs a project through five lifecycle stages using read/write access to SciMem. SciDAG can be invoked by SciFlow when a stage requires stronger multi-agent generation, critique, testing, or refinement. SciEvolve analyzes feedback and execution traces and then updates memory organization in SciMem, skill definitions and protocols in SciFlow, and operator templates in SciDAG (Qian et al., 29 May 2026).

The architecture is therefore closed-loop rather than pipeline-linear. This suggests that AutoSci’s design centers on persistence and reusability: outputs from one project are not merely archived, but are intended to become inputs to later projects after schema-governed consolidation.

3. SciMem and the memory-centric design

SciMem is the conceptual center of AutoSci. The paper describes AutoSci as memory-centric because scientific automation is treated as dependent on a durable substrate richer than logs, chat transcripts, or a vector database of notes. SciMem is split into two regions with different responsibilities: Long-Term Knowledge Memory (LTKM) and Active Research Memory (ARM) (Qian et al., 29 May 2026).

LTKM is a cross-project repository of consolidated scientific knowledge. It is populated by literature ingestion skills from sources such as arXiv, Semantic Scholar, GitHub, and user-provided documents. The long-term entity schema includes Topic, Paper, Foundation, Concept, Method, and People. These entities are stored as .md pages and connected by schema-constrained bidirectional cross-references. The paper emphasizes two defining properties of LTKM: semantic addressability, meaning downstream skills can retrieve typed scientific objects and relations directly, and incremental extensibility, meaning new literature and validated findings can be appended over many pipelines (Qian et al., 29 May 2026).

ARM is the workspace for the current project. It stores active artifacts such as Idea, Experiment, Manuscript, and Review. Each active entity carries an explicit lifecycle state. For example, Idea moves from proposed → testing → tested → validated or failed; Experiment moves from planned → running → completed or abandoned; Manuscript moves from drafting → revised → submitted → final version; and Review moves from received feedback → rebuttal drafting → revision → final decision (Qian et al., 29 May 2026).

Memory flow is also structured. Long-term aggregation consolidates newly ingested papers into Topic pages, Concepts, Methods, and Foundations. Cross-region flow goes in both directions: Long-Term → Active during project activation, and Active → Long-Term during consolidation of validated ideas, completed findings, failed attempts, and unresolved limitations. Reviewer concerns and rebuttal outcomes are additionally retained as cross-cycle notes. The paper’s Trust Guard mediates writes by checking form validity through deterministic linting and content validity through an independent reviewer agent, assigning Pass, Warn, or Block before material enters the usable graph (Qian et al., 29 May 2026).

A common misconception is to treat this memory layer as ordinary retrieval-augmented generation. AutoSci’s memory model is narrower and stronger: it is typed, linked, lifecycle-aware, and protected by write validation. That makes it closer to a research-specific knowledge graph and project state machine than to a generic document store.

4. SciFlow and SciDAG as execution layers

SciFlow is AutoSci’s execution framework. It decomposes research into five stages: Literature, Ideation, Experiment, Writing, and Rebuttal. The workflow is exposed as /research and is supported by more than 30 research skills. Stage outputs are written into SciMem rather than left in transient model context, which makes projects resumable from a specified stage and gives each skill a tailored SciMem view rather than the full graph (Qian et al., 29 May 2026).

The harness provides five guarantees: State, Context, Verification, Feedback, and Orchestration. State records stage outputs, lifecycle states, links, and pipeline-level progress outside transient context. Context compiles stage-local views of relevant evidence, prior failures, and lessons. Verification uses Trust Guard on memory writes and high-stakes handoffs. Feedback routes failures and critiques into refinement or evolution. Orchestration invokes stage skills, records progress, handles stopping points, and supports long-running experiments through non-blocking execution and monitoring (Qian et al., 29 May 2026).

SciDAG augments difficult skills with DAG-based multi-agent workflows. The paper formalizes this as an operator graph

$G=(V,E),$

where each node $v_i \in V$ instantiates an operator $o_i \in \mathcal{O}$ with a specialized sub-agent and produces an intermediate output from upstream outputs. Conditional edges can route on current execution state to continue, retry, branch, prune, or stop. The reusable operator library includes generate, variation, debate, ensemble, test, refine, review, polish, and early-stop (Qian et al., 29 May 2026).

SciDAG is optional and stage-aware. Ideation templates emphasize diverse generation and debate; experimentation templates emphasize reliability checks; writing templates emphasize evidence fidelity and refinement. A plausible implication is that SciDAG functions as AutoSci’s mechanism for selectively increasing deliberation depth without changing downstream artifact contracts.

5. SciEvolve and continual self-improvement

SciEvolve is AutoSci’s mechanism for full-system evolution. The paper explicitly distinguishes between storing reusable textual experience in SciMem and changing the system itself. SciEvolve implements the latter through three evolution paths: /dream for SciMem evolution, /forge for SciFlow evolution, and /morph for SciDAG evolution (Qian et al., 29 May 2026).

The evolution module consumes signals from three environments. The User environment contributes instructions, corrections, and research preferences. The Task environment contributes stage outcomes, experimental evidence, and failure reasons. The Open environment contributes new papers, codebases, and venue expectations. These signals are stored in a signal repository, recurring patterns are detected, and auditable versioned updates are triggered for memory organization, skills, or templates (Qian et al., 29 May 2026).

The three evolution paths target different parts of the system. /dream can down-weight or archive stale entries, compress redundant material, consolidate related entities, and propose new associations across Concept, Method, Paper, Idea, and Experiment entities. /forge treats SciFlow skills as versioned research protocols and can propose stronger claim-evidence checks in writing, revised handoff requirements, and promotion of successful repair strategies into reusable skill steps. /morph uses SciDAG traces to revise operator prompts, roles, or tool configurations, prune weak branches, add verification nodes, or specialize templates for stage and problem type (Qian et al., 29 May 2026).

The paper provides no global optimization objective or reward function for SciEvolve. The update logic is procedural rather than formulaic. This suggests that AutoSci’s self-improvement is governed by accumulated operational evidence and versioned patches, not by a single end-to-end training loop.

6. Case studies, evaluation, and relation to adjacent systems

AutoSci is evaluated through two end-to-end case studies rather than standardized benchmarks. The first domain is GPU kernel optimization and the second is biomedical drug discovery. In both cases, the same AutoSci system with SciMem, SciFlow, SciDAG, and SciEvolve was instantiated with Claude Code powered by Opus 4.7, and a user supplied an initial research direction and seed papers (Qian et al., 29 May 2026).

In the GPU case, AutoSci generated five candidate directions A–E, eliminated A during novelty checking as a duplicate of timing-only feedback approaches, eliminated B and C during pilot feasibility due to cost, deferred D because upstream mining would consume the budget, and selected E: profiling-guided Claude Code agent optimization. The selected idea was expanded into four experiment blocks: sensitivity analysis, main experiment, ablation experiments, and intermediate data analysis. The main experiment covered 157 operators over 5 iterations; by iteration 5, 157/157 were executable and correct; and the geometric-mean speedup was 1.52× over matched baselines and 1.18× excluding degenerate baselines. The ablation reported 1.58× gain on the high-headroom cohort and 1.22× gain on the broader cohort, while 628 iteration transitions were audited in intermediate-data analysis (Qian et al., 29 May 2026).

In the biomedical case, AutoSci generated five candidate ideas, eliminated A and B, deferred C and D, and selected E: PTM-aware degrader target nomination. The executed validation blocks included baseline reproduction, noise-floor calibration, and core operator tests, while some follow-up benchmarks remained frozen and pre-registered. The reproduced base scorer achieved DockQ top-1 0.397 versus the authors’ 0.429, with Acceptable-Rate 1.0; calibration yielded per-POI $\sigma$ values of 0.037–0.18; and the core operator gave phospho / alanine / Kme3 clearance rates of 14.5% / 15.9% / 15.7% versus 13.4% chance, with 0/69 surviving FDR/Bonferroni. The paper interprets this as a negative result in which the load-bearing premise was refuted under current PTM-blind scorers (Qian et al., 29 May 2026).

For each case study, AutoSci produced a manuscript-oriented artifact and submitted it to PaperReview.ai under an ICLR target-venue setting as a review proxy. Runtime was 27.3 hours for the GPU case and 22.6 hours for the biomedical case. The resulting scores were 6.3 / 10 and 5.8 / 10, respectively. The rebuttal stage was not evaluated in the case studies because no real external peer review occurred (Qian et al., 29 May 2026).

The paper is explicit about limitations. The current implementation is built as a skill package on top of general-purpose coding and reasoning agents rather than a science-specialized agent foundation. Evaluation is underdeveloped because there is no adequate benchmark for the full scientific lifecycle. Rebuttal is architecturally included but not empirically validated. The automated reviews also surfaced limited external validity, missing comparator runs, measurement noise concerns, and presentation gaps (Qian et al., 29 May 2026).

Within adjacent work, AutoSci is best distinguished from systems that automate narrower stages. AutoSciLab is a self-driving laboratory for interpretable scientific discovery in high-dimensional spaces built around a variational autoencoder, active learning, a directional autoencoder, and a neural network equation learner (Desai et al., 2024). SciNav is a general agent framework for scientific coding tasks centered on Top-K Comparative Tree Search and pairwise relative judgments (Zhang et al., 11 Mar 2026). SciMED is a scientist-in-the-loop symbolic-regression framework combining grouped feature selection, AutoML-based synthetic data enrichment, and symbolic regression (Keren et al., 2022). This suggests that AutoSci occupies the full-lifecycle research-environment layer, while these systems address more specific experimental, coding, or equation-discovery subproblems.