Zidong Taichu Ushers AI Research into the Project Era

On August 24, Zhongke Zidong Taichu upgraded its research-native AI agent, ScienceClaw, and launched AutoProject, an autonomous project-level research engine. The unit of work in AI research is beginning to shift from a single literature review or modeling experiment toward complete research projects capable of continuous planning, execution, verification, and remediation.
AI Research Shouldn't Just “Take Orders”
On August 24, ScienceClaw, a research-native agent developed by Zidong Taichu, completed an upgrade and launched AutoProject, an autonomous research engine for project-level work. What it seeks to address is not whether AI can read papers, write code, or run a single experiment, but a harder question that is also closer to the realities of scientific research: Can AI keep a research project moving forward over time?
This also represents an important shift now emerging in AI for Science (AI4S). In the past, research agents were generally evaluated on individual tasks: Can they conduct a literature review? Can they analyze a dataset? Can they invoke a specialized model? Can they generate executable code? Now, the industry is taking the evaluation criteria one step further: Given a vague research objective, can AI independently break down the research roadmap, schedule tasks, invoke tools, handle exceptions, and revise its original conclusions when new evidence emerges?
In other words, the unit of work in AI research is shifting from the Task to the Project.

What Is the Difference Between “Doing Tasks” and “Running Projects”?
On the surface, a Project merely links multiple Tasks together. But a research project is not a simple task list; it is more like a constantly evolving network of exploration.
A research idea often begins with an incomplete question. Researchers must first determine whether the question is worth investigating, then search the relevant literature, identify existing methods and data resources, design an experimental roadmap, and arrange simulation or modeling tasks. When an experiment fails, the original hypothesis may need to be revised; when anomalous data appears, the priorities of subsequent experiments may change; and progress along one research path may generate new subquestions.
The relationships among these tasks are not fixed or linear. Some work can proceed in parallel, while other work must wait for prerequisite results. Some data and models can be reused across multiple stages, while some intermediate conclusions require retrospective verification. Nor should the final deliverables consist merely of a few paragraphs of text. They should include data, code, models, experimental records, charts, and an evidence chain capable of supporting the conclusions.
Traditional AI based on one-off calls is more like a highly capable outsourced assistant: You give it a clearly defined question, and it returns a result. It can help researchers accelerate a particular stage, but it struggles to independently undertake a long-cycle research process characterized by strong dependencies, permissible failures, and repeated iteration.
AutoProject aims to complete this chain:
- Project planning: Understand the research objectives, existing foundations, and resource constraints;
- Task decomposition: Translate a high-level idea into subtasks with defined inputs, outputs, and dependencies;
- Long-horizon execution: Continuously invoke literature, data, code, simulation, and modeling tools;
- Evidence validation: Determine whether intermediate results and final conclusions are sufficiently supported;
- Dynamic recovery: Reorganize the research path when failures or anomalies occur, or when hypotheses are disproven;
- Outcome consolidation: Organize data, code, models, and conclusions into reusable research assets.
The key is not to “make AI do more work in one go,” but to give it awareness of the project's state. AI needs to know how far the project has progressed, which tasks have been completed, which results remain unreliable, what viable paths are available next, and whether a failed experiment means that parameters need to be adjusted or that the entire research hypothesis needs to be restructured.
AutoProject's Three-Layer Architecture
According to publicly available information, AutoProject consists primarily of three capability layers—Project2Task, TaskExecutor, and EviGraph—corresponding respectively to planning, execution, and validation.
Project2Task: First Answering “How Should This Be Done?”
Project2Task is responsible for transforming an initial research idea into a research network. It must identify the project's objectives, map out key variables and prerequisites, generate task dependencies, and determine which tasks can run in parallel and which must be executed sequentially.
The value of this step is that it reduces the burden on researchers to manually orchestrate prompts and workflows. In the past, researchers who wanted AI to participate in a complex project often had to first break the research process into dozens of prompts and then manually arrange the invocation sequence for every step. If the output format of any one step was unstable, or if an exception occurred midway through the process, all downstream tasks could fail.
AutoProject supports horizontal decomposition, vertical decomposition, horizontal-to-vertical structures, vertical-to-horizontal structures, and other project topologies. Put more plainly, it can divide tasks by research stage, expand separate roadmaps for different research directions, or combine the two structures according to the characteristics of the project.
This planning capability is especially important for interdisciplinary projects. Protein design, materials screening, drug discovery, and complex engineering simulation typically involve literature comprehension, data processing, model prediction, and experimental validation at the same time. No matter how capable an individual model may be, it cannot directly replace the full organization of research work. The real challenge lies in enabling different tools to collaborate around the same research objective.
TaskExecutor: Continuously Moving the Project Forward
Once planning is complete, TaskExecutor handles execution. Rather than simply invoking tools in sequence, it continuously monitors the project's state and determines the next action based on feedback.
Take YOLO modeling as an example. The project can be divided into three modules: data processing, model training, and iterative optimization. The system must first process the dataset, then initiate training, read metrics such as accuracy and recall, generate charts, and analyze the results. If training fails, it may need to inspect the data format, label quality, or parameter settings. If the metrics fall short of expectations, it must adjust the model design and rerun the experiment.
The most important change here is that task failure no longer means the end of the process. In an ordinary workflow, when a call returns an error, a person generally needs to identify the cause, modify the parameters, and resubmit the request. A long-horizon agent, by contrast, must distinguish among different types of failure: Did the tool call fail? Is the data incomplete? Are the model parameters inappropriate? Or was the original research hypothesis itself invalid?
This turns the research agent from an “executor” into a system with a feedback loop. It continuously reads experimental results, evaluates whether the current path is still worth pursuing, and, when necessary, reruns experiments, adjusts the plan, or returns to an earlier stage for further review.
EviGraph: Conclusions Must Be Traceable
Research imposes an inherent requirement on AI: Conclusions cannot merely “sound plausible”; they must also be verifiable.
EviGraph provides evidence-driven validation. It must link research conclusions to the literature, experimental data, model outputs, and intermediate processes, creating traceable evidence relationships. This enables researchers who encounter a conclusion to understand not only what the AI concluded, but also which data supported it, which methods were used, which experiments were conducted, and whether any unresolved contradictions remain.
This is an important dividing line between research agents and ordinary office Agents. In office settings, a smoothly written report may already be useful enough. In research settings, however, language quality is only a surface-level capability. What truly determines whether a system can enter rigorous research workflows is whether its results are reproducible, its processes are auditable, and its evidence can be traced back to its sources.
Without this layer, so-called “autonomous research” can easily become nothing more than longer automatically generated text. It may be able to write a complete research report, but it cannot answer the most critical question: Was this conclusion obtained through experiments, or did the model infer it from related text?
This Is Not About Replacing Scientists With AI
The significance of AutoProject lies neither primarily in enabling AI to publish papers independently nor in allowing researchers to withdraw from the process.
Many critical judgments in research still depend on domain expertise, experimental conditions, and value-based choices. Is a result sufficient to support a theoretical breakthrough? Is an anomalous data point noise or a new phenomenon? Does a research direction have long-term value? These are not merely questions of workflow orchestration. AI can expand the search space, reduce repetitive labor, and accelerate validation, but it must still operate within a controllable and reviewable research system.
A more realistic role is for AI to become project-level research infrastructure.
Researchers provide the objectives, constraints, and evaluation criteria, while AI manages large numbers of parallel tasks, continuously processes experimental feedback, and organizes scattered results into complete research assets. Researchers no longer need to spend their energy on every tool call and every round of parameter retries. Instead, they can devote more time to selecting problems, evaluating hypotheses, and designing critical experiments.
What distinguishes this division of labor from traditional software tools is that AI does not merely accelerate one step; it begins to participate in managing the rhythm of the entire project.
Industry Competition Is Shifting From Model Capabilities to System Capabilities
From the perspective of industry evolution, AI4S is witnessing the convergence of three approaches.
The first consists of scenario-specific models, such as models trained around protein structures, material properties, or specific physical processes. These models are often more stable and efficient at individual tasks, but their scope is limited.
The second combines general-purpose large models with research tools. These systems have stronger language comprehension and reasoning capabilities and can cover more stages of research by invoking literature databases, coding environments, simulation software, and specialized models.
The third consists of domain language models and scientific foundation models, which attempt to place different types of scientific objects—such as papers, formulas, experimental data, and molecular structures—within a unified representation space to support interdisciplinary reasoning.
AutoProject is closer to a combination of the second and third approaches: At the foundational layer, models must understand scientific content; at the intermediate layer, toolchains must perform actual computations; and at the upper layer, project management and evidence-validation mechanisms are also required.
This indicates that competition in AI research is shifting away from “whose model gives smarter answers” and toward “who can organize models, tools, data, and processes into a reliable system.” Benchmark scores for individual models remain important, but what may determine whether a product can enter real research production workflows is its ability to recover from failure, retain context, manage task dependencies, allocate resources, and audit results.
Previously, research platforms such as ScienceOne had already explored literature comprehension, scientific computing, and tool orchestration. In July 2026, related industry discussions also characterized AI4S as evolving from an assistive tool into research infrastructure. Zidong Taichu's latest move to advance the focus to the Project level reflects a clear trend: Research agents are beginning to shift from “being able to complete a particular stage” to “being able to manage a continuously evolving research process.”
Three Practical Challenges Remain
However, project-level agents still face several formidable barriers before they can truly take on research projects.
The first is reliability. Research projects allow trial and error, but they cannot tolerate errors being silently incorporated into subsequent conclusions. Systems must clearly distinguish facts, hypotheses, conjectures, and unverified results, while preserving mechanisms for human confirmation at critical checkpoints.
The second is the standardization of tools and data. Data formats, permission settings, coding environments, and instrument interfaces vary greatly among laboratories. Without stable tool protocols and asset-management mechanisms, agents can easily remain confined to demonstration environments and fail to achieve reuse across projects.
The third is the evaluation framework. Individual tasks can be measured by accuracy, execution success rate, or completion time, but project-level research requires more complex metrics: Is the research roadmap sound? Is recovery after failure effective? Is the evidence chain complete? Can the generated assets be reproduced? And did the project ultimately produce new, verifiable discoveries?
This also means that AutoProject's value cannot be judged solely by whether a single demonstration runs smoothly. What is truly worth observing is whether it can remain stable in real-world projects that are long-running, highly branched, and prone to frequent failures—and whether researchers are willing to entrust it with the management of critical stages.
Conclusion: The Next Stop for AI Research Is “Continuous Progress”
Over the past few years, the most common way for AI to enter scientific research has been to help researchers complete one local task after another: finding papers, writing code, processing data, and running models. Now, as reasoning capabilities, tool invocation, and specialized models continue to mature, the industry is beginning to ask a bigger question: Can AI understand a project's objectives and keep advancing it amid uncertainty?
Zidong Taichu's latest upgrade to ScienceClaw offers AutoProject as its answer. It places project planning, long-horizon execution, and evidence validation within a single research-agent framework, seeking to move AI away from one-off delivery of results and toward continuous, objective-driven iteration.
This path is far more technically challenging than ordinary Agent workflows, but it is also much closer to the true value of AI4S. Research has never been a single Prompt. It is a path of exploration marked by failures, branching paths, and corrections. Whoever can enable AI to work reliably along that path may be the first to truly move research agents out of the Demo and into real projects.
Reference materials indicate that AI Agents are moving beyond the Demo stage, where the focus was on showcasing capabilities, and into an application stage that places greater emphasis on tangible output and end-to-end process ownership. For AI4S, the defining feature of this stage may no longer be how many scientific questions a model can answer, but whether it can continuously develop a vague question into a body of research outcomes that are verifiable, reusable, and capable of evolving.



