Autonomous R&D That Builds on Itself
Today, we are introducing PRAXIST, an autonomous R&D system for technical problems where solutions can be built, run, and tested.

Coding agents have made it possible to give a system a goal and let it work toward a solution. PRAXIST takes the next step: instead of treating each attempt as another iteration on the same solution, it turns experiments into a growing body of research—preserving what worked, what failed, how reliable each finding is, and what should be investigated next.
Across 75 machine-learning tasks, PRAXIST using DeepSeek-v4-pro reached the gold tier on 54 of 75 tasks. A Claude Code baseline we tested using Claude Opus 4.8 reached gold on 34 of 75 under the same evaluation protocol.

We also tested PRAXIST beyond standardized benchmarks, across open-ended studies in SLAM, reusable-rocket landing, quantitative trading, tokamak control, and factory-job scheduling. The artifacts and evaluators are very different, but the research problem is the same: there is a measurable objective, many possible paths toward it, and progress depends on learning across a sequence of experiments.
In SLAM, PRAXIST reduced an internally measured proxy for core compute in the laser- and camera-based position tracking (LIO plus VIO) by approximately 22.1% while improving localization accuracy, making a compute-heavy state-of-the-art system more practical for consumer hardware. In reusable-rocket landing, PRAXIST turned a failing proof-of-concept controller into one that landed safely throughout formal evaluation and remained reliable across a broader coverage sweep. PRAXIST does more than produce a working controller: it helps turn an early concept into a usable technical foundation that engineering teams can build on: demonstrated in simulation, supported by auditable control logic, a mapped history of failure modes, and evidence showing why each mechanism matters.
Why R&D Needs a Research Graph
Complex engineering and scientific problems are rarely solved in a single attempt. Progress is cumulative: one experiment reveals a mechanism, another exposes a constraint, and discoveries from different paths may only become useful when combined later.
As a research campaign grows longer, preserving only candidate solutions or their scores becomes limiting. An artifact can contain many different design choices, mechanisms, parameters, and implementation decisions, and the value of one element may only become clear later or in combination with findings from another branch.
PRAXIST therefore organizes research as a research graph. Each experiment produces a reproducible artifact and findings that capture what changed, what happened, how strongly the result is supported, and how it should influence future work. The graph preserves the relationships between artifacts, findings, and research decisions through connections such as derived from, supports, and challenges.
A promising result may need validation, a failure may eliminate a direction, and findings from separate branches may become valuable in combination, so PRAXIST carries useful evidence forward rather than remembering only the best solution.
Multiple research paths can explore different mechanisms, validation questions, and failure modes in parallel, with their findings returning to the same graph. Supported mechanisms can be reused, fragile results can be tested further, useful failures can become constraints, and evidence from separate branches can later be recombined into stronger solutions.
This also keeps performance separate from evidence maturity. A high-scoring artifact can identify a promising direction without automatically being treated as proof, allowing later research to continue, validate, challenge, or move away from it based on the evidence.
The result is not only an evaluated solution, but its solution lineage: a traceable account of the discoveries, failures, validations, and decisions that shaped how it was built.

Breadth Across 75 Machine-Learning Tasks

We first tested whether this research process could transfer across a broad range of standardized problems. The 75 tasks were drawn from MLE-bench, a benchmark built from real Kaggle competitions, and span tabular data, computer vision, language, forecasting, and signal processing. Each task requires a system to build and run a machine-learning solution, with submissions graded against human-leaderboard bronze, silver, and gold thresholds.Across the complete benchmark, PRAXIST using DeepSeek-v4-pro reached the gold tier on 49 of 75 tasks, while the Claude Code baseline we tested using Claude Opus 4.8 reached gold on 34 of 75. Both results come from the same evaluation of each system under the official grading harness.
Beyond the medal count, these results show that a single research process can work across diverse datasets, modalities, and modeling problems without being redesigned for each task.
Designing SLAM for Cost-Sensitive Robots

Beyond standardized benchmarks, could PRAXIST solve a real-world engineering problem? To find out, we chose a specific engineering problem, SLAM: could a state-of-the-art LiDAR–visual–inertial system—one that locates itself by fusing laser, camera, and motion sensors—retain its accuracy while requiring substantially less computation? FAST-LIVO2, the published system we started from, processed every visual update and retained newly generated visual map points. That design provided strong localization, but made the visual path and map lifecycle natural targets for deployment-oriented optimization.
Across iterations of improvement and evaluation, PRAXIST reduced an internally measured proxy for core LIO-plus-VIO workload by 22.1%. It also improved localization accuracy: APE RMSE was lower on 13 of the 14 sequences, with a median relative reduction of 49.2%; the remaining sequence was effectively unchanged.
Additionally, PRAXIST found that simply skipping visual updates was not enough. Vision can be redundant when LiDAR already constrains the state, but essential when it does not. The final design therefore activated vision when LiDAR alone was insufficient and filtered near-duplicate geometry before it entered the map.
The result creates compute and memory headroom that could make advanced SLAM more practical on cost- and power-constrained robots, or free resources for perception, planning, and control. Because the 22.1% figure reflects internally captured LIO and VIO workloads rather than end-to-end runtime, target-hardware validation is still needed to quantify CPU, power, thermal, and unit-cost gains.

Engineering a Reusable-Rocket Landing System

To see how far PRAXIST could go, we put it to work on an open-ended engineering problem with no predetermined solution: rocket recycle landing control. Within roughly twelve hours, PRAXIST advanced an early proof of concept into a deterministic controller that passed all landing scenarios. The controller continued to land reliably as wind direction and point of application changed randomly about once per second, with speeds reaching 20 m/s, which is roughly the upper end of NASA’s published SLS liftoff wind limits.
The design remained rooted in traditional composite control. It used rolling zero-effort-miss/zero-effort-velocity guidance—which continually estimates the position and speed errors still to be removed—together with terminal descent, attitude stabilization, roll control, and coordinated use of the vehicle's actuators.
The starting controller reached first leg contact in every trajectory, but only 495 contacts, or 4.03%, met the complete acceptance criteria. In 88.64% of cases, it ran out of modeled main propellant. PRAXIST traced the problem to a stabilization hold near 275 meters that consumed the fuel needed for landing. A fuel-aware descent commitment removed that bottleneck. Faster guidance and a stronger attitude loop then made lateral recovery controllable, while final-approach guards resolved the remaining edge cases.
Once the controller reached 100%, PRAXIST continued improving touchdown quality. A deterministic constrained allocator coordinated the gimbal and grid fins without changing the successful classical architecture. A control experiment showed that this allocator improved contact and actuator behavior rather than accounting for the success-rate gain itself. To put the result in practical terms, an experienced rocket engineer assessed it as a strong technical result and estimated that matching its near-perfect simulator performance through conventional development would likely require roughly eight engineers working for one month. PRAXIST reached it in about twelve hours. Although not flight-qualified, the result provides a credible, working TRL 3 foundation—NASA's marker for a concept proven in simulation. From there, engineering teams can move toward TRL 4 through real-time integration, hardware-in-the-loop testing, and bench validation, spending scarce expertise and early capital on the hardware work rather than on the search.

Additional Open-Ended Studies
We applied the same research process to two additional domains with different artifacts, constraints, and evaluators.
Quantitative Trading

In a historical walk-forward backtest—repeatedly training on past data and evaluating only the period that followed—PRAXIST developed a recurrent trading policy for a fixed universe of 100 U.S. stocks. With quarterly retraining, next-open execution, and transaction costs included, the policy from Praxist achieved a 53.07% compound annual growth rate (CAGR) from 2019 through 2025, compared with 22.80% for an equal-weight buy-and-hold strategy over the same universe. Its largest drawdown within any quarterly test window was 33.48%.
Tokamak Control

In a nonlinear MAST-U-like tokamak simulation, PRAXIST combined mechanisms for vertical stability, radial position, plasma current, and shape control. The resulting controller achieved aggregate survival of 1,264 of 1,500 simulated steps, compared with 1,222 for a replica of the deployed MAST-U plasma control system, while also modestly reducing common-horizon tracking error.
Different domains require different artifacts, experiments, and definitions of success. What remains consistent is the research process: exploring alternatives, preserving evidence, challenging promising results, and carrying useful findings into what comes next.
From Better Experiments to Better Research
PRAXIST begins in technical domains where ideas can become runnable experiments and evidence can be tested. The goal is not simply to run more experiments, but to make each experiment contribute to what comes next.
Over time, the same research graph could extend to the tools and methods used to conduct research itself. Validated improvements to models, evaluators, workflows, or research strategies could become part of the inherited state for future campaigns, while researchers focus less on directing individual attempts and more on setting objectives, constraints, and standards of evidence.
The longer-term direction is a research system that does not simply search harder, but learns how to research better.
Tech Report:https://arxiv.org/pdf/2608.25955