An algorithm engineer’s day is “modify code – submit for training – wait – read logs – decide the next step”, and the process is often interrupted. Our team started from Karpathy’s AutoResearch and after three architectural reconstructions, built a self-evolving system for algorithm research that can be used on enterprise cloud training platforms: the system was upgraded from single-threaded LOOP exploration to a CyclicGraph Engine graph exploration architecture, using a state machine to ensure the stability of long-term operation, and through “business knowledge base + real large closed loop + automatic precipitation of experience” to achieve self-evolution of the system, making it more useful the more it is used.
In two business modeling projects with different structures, goals, and scenarios, the time taken to complete a single task was reduced by approximately 85% and 83% respectively compared with the manual baseline. One of the algorithm models has pushed all the solutions independently derived by the system online and achieved online benefits; in the other multi-objective project, the solution produced by the system exceeded the manual baseline on all 12 estimated goals at the same time. The only thing the two projects have in common is the same system architecture, indicating that the gains come from the architecture itself. This article shares the design concept, architecture evolution and reliability design of this system, hoping to be helpful or inspiring to everyone.
The typical workflow of an algorithm engineer is: modify the code, push the code, submit for training, wait, check the log extraction indicators, compare with the previous round, and decide the next step. During the waiting period, engineers will switch to other tasks, but switching is costly and time is not fully utilized; if the training is completed in the early morning, it will have to wait until the next day to continue. At the end of the day, about 2 to 3 substantial iterations are completed. The links that really require judgment are squeezed out by switching and waiting.
At the end of 2025, Andrej Karpathy open sourced AutoResearch: an experimental prototype for training 50 million parameter teaching-level GPT on a single H100. There are only three files in the warehouse: program.md describes the research rules in natural language, train.py is the only training code that the Agent can modify independently, and prepare.py is responsible for evaluation. It’s this minimalist combination that allows LLM-driven research to run automatically at night and on weekends. In about two days, the system ran about 700 experiments and produced about 20 forward submissions for val_bpb. There is a deliberate trust design behind this cycle: the prepare.py responsible for evaluation is frozen as an unmodifiable file. The Agent can only change the training code but not the evaluation function, which mechanically eliminates the possibility of “tampering with the referee”; and the Git ratchet mechanism of keep/reset makes every improvement auditable and rollable.
This allows us to see the possibility of “letting the Agent iterate autonomously”. But after moving it into an enterprise scenario, three problems were quickly exposed:
- credibility issues: The rules are all declared in natural language Prompt, and model illusion will lead to incomplete execution;
- Differences in operating environment: There is a huge difference between the local stand-alone machine and the enterprise cloud training platform. The Agent needs to be executed asynchronously, and the evaluation indicators must reflect the business differences;
- Fundamental limitations of the LOOP architecture：keep/reset is essentially a single-threaded serial LOOP that can be rolled back. Commit when the effect improves and reset when it degrades. Only one timeline can be maintained at the same time. Most AutoResearch practitioners (including the original us) have followed this single-threaded approach.
What this article is going to talk about is how we went through three architecture reconstructions in three months, and finally jumped out of the LOOP architecture, from “running” to “capable of automation and self-evolution”: V1 answered “can it run”, V2 answered “can it run stably”, and V3 answered “can it run fast and accurately”.
Before unfolding the architectural details, let us first clarify our five design concepts, from which all subsequent choices are derived:
- Efficient and cost-effective. Agent’s computing power at night and on weekends is “idle capacity”. The system must be able to liberate people’s attention from execution and only retain high-value judgments.
- Decoupled from the underlying Agent base. Agent base capabilities are advancing rapidly, with more cost-effective models becoming available every few months. The system should not be tied to any one company’s base, but “free ride” through good harness design – the base upgrades, and the system benefits for free.
- The system evolves by itself, and the more you use it, the better it becomes.. Experience, tools, and skills should not be started from scratch every time, but should be automatically summarized during use, and then precipitated back into the system after manual verification.
- Obtain high-quality data with real large closed loops. Offline indicator improvement is just an intermediate station. The real feedback after the solution is launched back to the knowledge base is the scarcest data in the vertical scenario. The system continuously accumulates business knowledge during use, forming a self-evolving flywheel.
- Trusted first. In an unattended long-term cycle, one mistake will become the input of the next round of decision-making, amplifying round by round. Any constraints that can be expressed in code are not placed in prompts.
The three versions are not a roadmap planned in advance, but an evolution driven by real problems.
Scheduled tasks + Shell scripts are triggered periodically, and a single Agent serially completes the entire link of inspection, extraction, analysis, and code modification, and the report is archived to a cloud collaboration document. V1 implements AutoResearch on the enterprise cloud, but problems such as context explosion and untimely status synchronization cause inefficiency.
A new session is created every time it is triggered, and the status is persisted in the JSON status file, which solves the context explosion problem caused by long sessions. The architecture is split into two roles: Monitor and Iterator. Relying on the phase field of the status file for mutually exclusive routing, only one role is working at the same time. The state file only retains the minimum information required for decision-making, and the goal is to compress the exploration results into reusable decision-making basis; this is a customized design for ML iteration scenarios, and is different from the “full state” idea of the general graph orchestration framework. Another key decision is “stateless trigger + stateful file”: the Agent does not wait for training synchronously (training can often take several hours, and long session waiting is a waste of context and unreliable). Instead, a new session triggered by a timer restores the scene from the state file the next time it is evoked. This lays the foundation for V3’s asynchronous parallelism.
V3 breaks the single-threaded LOOP limitation used by V1 and V2. The core mechanism is Spawn-Converge:
- Spawn: The main agent of the decision-making layer breaks a big problem into 3 to 4 mutually exclusive differentiated hypotheses (such as “insufficient features” and “insufficient structure”) and dispatches them to the execution layer;
- implement: Sub-Agents modify codes and submit training in parallel through context isolation without knowing each other, so they will not be biased by each other’s intermediate conclusions;
- Converge: After the training is completed, the main agent summarizes and compares several independent results, refines insights, and decides on the next round of direction combinations.
It should be emphasized that this is essentially different from “running several experiments at the same time”. Parallelism is just a means, and it is matched with a three-step closed loop: the main agent first dismantles the mutually exclusive assumption, the sub-agents independently verify it, and the main agent finally converges and compares to make a decision. If we only run in parallel and don’t converge, it will degenerate into multiple experiments.
At the scheduling level, the system has gradually evolved from V2 toState machine driver: Asynchronous triggering + state recovery, the Agent does not wait for training synchronously, but relies on the state machine to query the results the next time it is triggered. This is a reasonable architectural response to the physical constraint that “training takes several hours”, and also significantly improves system stability and process flexibility.
The efficiency gains of graph architectures can be directly quantified. On the same modeling project: 10 iterations under the LOOP architecture took 3 days (0.14 times/hour) and no breakthrough was achieved; after switching to the graph architecture, 12 iterations only took 4.7 hours (2.55 times/hour) and achieved the goal. The iteration speed differed by 18 times (see Section 8 for the complete effect).
The difference does not come from the faster single training, but from four points: Orthogonal parallelism increases the amount of information obtained in each round by about 3 times; the “aggregation-distribution” organizational form increases the number of effective decisions per unit time; the boundary probe quickly determines the upper and lower bounds of parameters; single-variable control avoids ineffective iterations caused by confusion of dependent variables.
A general agent does not understand your business. The key to making the system truly usable is to vertically couple it to specific business scenarios, and this relies onBusiness knowledge base + real closed loop。
When initializing a new project, the system will ask for a basic business knowledge base (modeling goals, sample size, historical conclusions, constraint boundaries), and combine it with automated initial research to build a direction pool to ensure that the starting point of the knowledge base is clean.
The systematic research method is divided into three levels:
- Initial survey: Establish a direction pool when the project starts and screen the research sources;
- progressive research: Supplement as needed during the research process, rather than cramming the context all at once;
- Mandatory research: When the marginal improvement of the indicator is slow and the same plan is rotated for multiple consecutive rounds, the escape mechanism is triggered, forcing the dimension to be switched and re-investigated – to prevent the system from idling and burning resources in the local optimum.
Offline metric improvement is just an intermediate stop. Real feedback after the solution is launched (online experimental conclusions, changes in business caliber indicators) will flow back into the knowledge base and become the most scarce high-quality data for the system in vertical scenarios. The rise and fall of offline indicators are clear and machine-interpretable; the online closed-loop data calibrates the deviation between “good offline” and “good online”. In the process of using the system, through the continuous accumulation and recirculation of knowledge, experience and tools, the self-evolution of the system in vertical scenarios is realized.
In a long-term automatic cycle, the agent’s unreliable behavior is divided into two categories, with completely different causes and governance methods:
- cognitive illusion: The output is linguistically self-consistent and factually wrong, such as attributing training fluctuations to a non-existent factor, or filling in parameters with non-existent values. It will not report an error, but will quietly lead subsequent decisions in the wrong direction.
- Execution layer deviation: The tool call fails, and the returned results are inconsistent with expectations. For example, the platform interface times out, the task ID expires, and the log field is missing, resulting in empty indicator parsing.
The governance principle is one sentence:Any constraints that can be expressed in code will not be placed in Prompt.. It is not enough to write “Do not repeat the falsified direction” in the Prompt. The Agent may still think that “this time the situation is different”; but once the falsified direction is written into the hard constraint list of the state file, the next round will be directly skipped at the code logic level. In response to deviations at the execution layer, the system is fortified in three links: critical status uses the status file as the only source of truth, and easily expired fields (such as task IDs) are forced to be re-read in each round, prohibiting the reuse of old context values; all platform calls are encapsulated into idempotent tools, and the return values are subject to structured verification. If fields are missing or have abnormal formats, the judgment fails, instead of continuing execution with null values; code faults and infrastructure faults are distinguished. The former is included in the falsification record and triggers plan adjustment, while the latter is automatically retried and does not occupy the round budget.
The system retains the original index improvement and original code diff of each round of exploration. The Agent’s analysis may be hallucinatory, but the indicator data and code modifications themselves are definitely real. The conclusion of any round can be traced back to the chain of evidence rather than to a certain narrative. This comes from our observation of the compound effect of hallucination: once the wrong conclusion in the loop is fed into the next round of context, wrong reasoning will be superimposed on the wrong premise, making it wrong step by step but “looking reasonable” every step; the only countermeasure is to make physical facts such as training results an unavoidable verification anchor point – the model can hallucinate that “the learning rate is too small”, but the indicator curve after the training run will not match its hallucination.
When sub-agents explore, the contexts are isolated from each other, or different models are used to verify the same hypothesis from two paths and detect differences. When summarizing, the main agent compares several independent results before making a decision, naturally with a layer of cross-validation. Cross-validation is not done in every round (the cost is too high), but is triggered when the main Agent’s confidence is low, multiple consecutive rounds of indicators deteriorate in the same direction, or when attribution involves directional decisions; divergent conclusions are retained at the same time and transferred to manual review, rather than a simple majority vote.
During the execution process, the system will automatically summarize tool usage experience and troubleshooting methods, and precipitate reusable Skill drafts. After two-level verification of “system preliminary screening + manual review”, they will be officially written into the system toolset. A real example: The experience in handling abnormal connection of the training platform parameter server in the early batches was automatically compiled into a Skill draft by the system, which was fed back to the tool set after manual review. Since then, the system has independently responded to hundreds of similar infrastructure failures without manual intervention. Skills that have been included in the database will also continue to be self-improved through the review mechanism in subsequent use. Behind this is an anti-illusion promotion chain: experience first exists as a low-level record with evidence, and is promoted to a formal skill after meeting the reuse rules and passing manual review. Conclusions that have not been externally verified will never enter the knowledge base and are only temporarily stored in the temporary area.
The attribution of Agent (“why this direction works”) remains an open puzzle. Our answer is not a single technology, but the accumulation of three aspects: the accumulation of knowledge base gives attribution a business basis, the accumulation of research gives attribution a paper basis, and the accumulation of real experimental data gives attribution an evidence basis. Attribution capability is a slow variable – if Harness is built well, it will continue to get better over time; this is part of the design of a self-evolving system.
We call the set of operating rules (status file, tool return verification, failure recovery, experience library, hard constraints, and prompt words) that are applied to the general Agent and allow it to operate stably in the production process Harness. There is also external evidence in the same direction: LangChain’s coding agent uses the same model throughout the entire process, and only adjusts the three Harness dimensions of System Prompt, Tools, and Middleware, and its score on the 89 cross-domain tasks of Terminal Bench 2.0 increased from 52.8% to 66.5%. For the same model, but with a different working mechanism, the difference reaches 14 percentage points. Our three reconstructions are essentially to polish this domain-specific Harness on the premise of decoupling it from the underlying general-purpose Agent, which determines whether the system accelerates the discovery of truth or accelerates the propagation of errors. The capability dividends of the base model are available to everyone, and Harness is where differentiated competitiveness lies.
The system is completely decoupled from the underlying Agent base, and the core design is “stateless trigger + stateful file”: all states are stored in JSON files, and each trigger is a new session. This design brings triple benefits: can be triggered at any time – not limited by the session life cycle, can be triggered at any time, manually or event-driven; zero idle – the Agent is not synchronized and waits for training that can take several hours at any time. It works when triggered and exits when completed. Computing resources can also be fully utilized in long-term tasks; base freedom – does not rely on the session memory or proprietary capabilities of any base. After the Agent base is upgraded, the system can be switched seamlessly.
In the front-end interaction layer, we have tried various forms such as IM robots, internal Agent platforms, self-built sandboxes, etc. The framework design is completely decoupled from the interaction form – if you change the entrance, the system will run as usual.
For users, starting a new project is very easy:
user: I want to start a new project, what do I need to provide you?
system: It is necessary to provide a basic business knowledge base (if there is anything missing, we will ask for supplements), business indicators that need to be optimized, cloud document directories for report archiving, iteration upper limits and threshold indicators (mainly used to prevent unlimited consumption of resources), and a demand template that can be filled in directly.
user: Fill in the template document and send the link to the system.
system: Start automatic iteration. Users can ask about the progress or interrupt at any time during the process; if not interrupted, the system will stop itself when the goal is achieved or the upper limit is reached.
A typical experience after project launch is: It was launched on Friday. When I came back on Monday, I found that the system had independently completed more than ten rounds of iterations, and the core indicators had significantly improved, with zero manual intervention during the period. This directly corrects our initial setting of human-machine division of labor (“AI execution, human supervision of each round of direction”); the boundary of the division of labor that has been converged after practice is: human value is concentrated on a few high-leverage nodes, rather than dispersed in each round of execution supervision.
On two modeling projects with different model structures, optimization goals, and scenarios, the system gave highly consistent answers: the time taken to complete a single task was reduced by approximately 85% and 83% respectively compared with the manual baseline. The only thing the two projects have in common is the same system architecture, which shows that the gains come from the architecture rather than the specificity of a certain project. In one of the projects, the optimization plan independently derived by the system (not in any reference paper) has been fully verified and put online, achieving online benefits; in another multi-objective project, all 12 estimated goals exceeded the artificial baseline.
The most critical point: AutoML, which is mainstream in the engineering world, defaults to “the correct answer is within the predefined search space”. In our actual case, the correct answer is precisely not in the initial space – the system needs to first falsify and exit an incorrect problem frame, and then deduce new candidates from the mathematical structure of the paper. This is a difference in the level of ability (from “carrying out a given direction” to “autonomous generation of hypotheses”), not a difference in search efficiency.
Verification covers three things: offline indicators, online experiments, and interpretability testing. The first two determine whether to go online and push it all – after the offline indicators meet the standards, use the confidence interval of the online A/B experiment results to judge whether it can be pushed to the whole database; the third one determines whether it can be entered into the hard constraint database – if the Agent cannot give a reasonable derivation, it will not be included in the database even if the indicators are good, to avoid erroneous experiences contaminating the knowledge base. If it cannot judge whether it can be included in the database, it will be transferred to manual review.
This architecture is suitable for scenarios that meet three conditions at the same time: there are clear quantifiable indicators; the cost of a single experiment is acceptable; and the experimental results are reversible. It is not suitable for scenarios where the evaluation is highly subjective, the search space is completely open, or the cost of a single experiment is extremely high and irreversible.
- infrastructure dependency: Training resources are the biggest external bottleneck. The system can only reduce resource consumption but cannot eliminate resource tension from the root cause;
- The Risk of Illusion in Transferring Experience: The experience database involving vertical business fields is reused across projects, which may generalize local experience errors. Currently, it relies on manual review to intercept stuck points;
- Limited attribution interpretability: The system can derive effective solutions, but the attribution explanation of “why it works” is still not rigorous enough, and manual cross-validation is required before it can be entered into the hard constraint library.
The next step is to: First, improve the stability of self-evolution – the direction of the self-evolution technology architecture has been determined, and the state machine and process stability will continue to be polished in the future; second, the illusion problem in knowledge migration – how to stably reuse cross-business experience and ensure that the experience library is clean and stable; third, explore more friendly interaction and use experience.
Karpathy’s AutoResearch is an experimental prototype running educational GPT on a single H100. What we have done is to move this concept into real business scenarios in the enterprise cloud: during the engineering process, we discovered the fundamental limitations of single-threaded LOOP and used the graph exploration architecture of CyclicGraph Engine to break it; used state machines to ensure the stability of long-term operations; used business knowledge bases and real large closed loops to make the system more usable in vertical scenarios.
We believe that the real value of Agent’s independent research lies not in “searching the existing space faster than humans”, but in “being able to falsify false premises and actively expand the search space.” When the system can deduce a solution not given by humans from the mathematical structure of the paper and verify it to be effective in real business, it has moved from an “execution tool” to a “research partner.” The road has just begun.
Finally, back to the methodology itself. The biggest inspiration from three refactorings in three months is that the core engineering volume of the independent research system is not on the model side, but on the Harness side – “unsexy” infrastructure such as state machines, hard constraints, evidence chains, and promotion thresholds are the watershed that determines the credibility of the system. The correct way to evaluate this system is not to see how fast it runs, but to see whether it can be corrected by evidence, stopped by constraints, and remembered by the experience database after making mistakes. Reproducible, auditable, and rollable are the bases for independent research systems that are more important than efficiency.
- [1] Andrej Karpathy. AutoResearch. GitHub, 2025
- [2] Ryan Lopopolo. Harness engineering: leveraging Codex in an agent-first world. OpenAI, 2026
- [3] LangChain. The Anatomy of an Agent Harness. LangChain Blog
- [4] Description of statistical caliber: This article uniformly uses “one training task” as the counting unit of one iteration (parallel directions are counted separately), including exploratory failures that are falsified due to indicator crashes; artificial baselines are converted according to the working days actually invested in iterations; only normal execution batches are counted on the system side, and batches caused by infrastructure failures are not included in the denominator. 18 times is the improvement of the graph architecture compared to the system’s own LOOP architecture; 85% and 83% are the reduction in single task time compared to the manual baseline, and the denominators of the two are different.
