Most scientists who use AI agents, this post observes, work in a conversational loop, supervising each step. It describes an alternative: write down a clear objective and success criterion, then let an agent work for hours or days with only occasional human checks. The post was published on 23 March 2026 as one of the two launch pieces of Anthropic's Science Blog (Introducing our Science Blog). Its author, Siddharth Mishra-Sharma, is a researcher on Anthropic's Discovery team. It is a practical tutorial built around one worked example, not a controlled study.
What the post describes
Which tasks suit long-running agents
The post names three kinds of scientific task that fit (section "The premise"): reimplementing a numerical solver, converting legacy scientific software written in an old Fortran dialect to a modern language, and debugging a large codebase against a reference implementation. What they share is a well-scoped job, clear success criteria, and the possibility of occasional rather than continuous oversight. It cites Anthropic's C compiler project, in which Claude worked across roughly 2,000 sessions to build a C compiler able to compile the Linux kernel, as an earlier version of the pattern.
The worked example: a differentiable Boltzmann solver
The example uses Claude Opus 4.6 to write a differentiable version of a cosmological Boltzmann solver, numerical code that predicts the statistical properties of the cosmic microwave background by evolving coupled equations for photons, baryons, neutrinos and dark matter through the early universe. Established solvers such as CLASS and CAMB are standard tools for constraining cosmological models with survey data. A differentiable solver can pass gradients through the whole computation, which allows gradient-based inference and faster parameter estimation; the post chose JAX for automatic differentiation and GPU support.
The author states that the task is outside his own domain: he has a high-level familiarity with it but not the expertise to finish it himself in reasonable time. Groups with that expertise have built differentiable solvers in JAX covering a subset of CLASS's features, which the post says typically took months to years of researcher time. The test was whether an agent could go further with minimal steering from a non-specialist.
The post contrasts this task with the C compiler. A compiler can be split among many parallel agents, but a Boltzmann solver is a tightly coupled pipeline in which a small error early on, for example in modeling recombination, shifts everything downstream. Debugging means tracing causes through the whole chain, which the post suggests suits a single agent working sequentially, spawning subagents as needed, and bisecting discrepancies against the reference code.
The setup
The post's setup has five parts:
- A plan in an instruction file. Most of the human's time goes into writing, with Claude, a file of instructions that states the deliverables and context. The file is CLAUDE.md in the project root, which Claude keeps in context; Claude may also edit it as it learns (section "Draft a plan and iterate locally").
- A progress file as memory. A file called CHANGELOG.md serves as the agent's long-term memory across sessions, recording status, completed tasks, accuracy tables, known limitations and failed approaches. The post stresses the failed approaches: without them, later sessions retry the same dead ends (section "Memory across sessions").
- A test oracle. Long autonomous work depends on the agent knowing whether it is making progress, through a reference implementation, a quantifiable objective or a test suite. Here Claude was told to build and continually run unit tests against the CLASS C source (section "The test oracle").
- Git for coordination. The agent commits and pushes after each meaningful unit of work, giving a recoverable history and a way to monitor progress remotely (section "Git as coordination").
- An execution loop. Claude Code runs inside a terminal multiplexer (tmux) on a node of a computing cluster managed by the SLURM scheduler; the human attaches to check in or steer and detaches again. The example job script requests one GPU for 48 hours (section "The execution loop").
The Ralph loop and "agentic laziness"
The post describes a failure it calls agentic laziness: asked to complete a long, multi-part task, current models sometimes find a reason to stop early. Its remedy is the Ralph loop, an outside loop that, whenever the agent claims to be finished, puts it back to work and asks whether it is really done. The example invocation allows up to 20 iterations and asks Claude to keep working until a success criterion of 0.1% accuracy across the parameter range is met. The post frames this kind of scaffolding as a capability uplift that may become less necessary as models improve.
The written instructions
The post treats a written instruction file as the main way the human directs the work. It describes the effort of the project as going into "crafting a set of instructions that clearly articulates the project’s deliverables and relevant context" (section "Draft a plan and iterate locally"), and links an early version of the actual CLAUDE.md for the solver project. The author set the high-level goals, full feature parity with CLASS while remaining differentiable and an accuracy target of 0.1% against CLASS on the main outputs, and iterated with Claude on the rest. The 0.1% target was chosen because it is the typical level of agreement between CLASS and CAMB.
The post gives examples of rules such a file might contain, for instance: "Commit and push after every meaningful unit of work. Run pytest tests/ -x -q before every commit. Never commit code that breaks existing passing tests." (section "Git as coordination"). It also shows a sample progress-file entry recording a failed approach, a switch between two numerical integrators because the system was too stiff. The post does not compare alternative wordings of these instructions or measure their effect; it reports that the arrangement worked for this project.
What it reports
Claude worked on the project from scratch over a few days and reached sub-percent agreement with CLASS across its outputs (section "The result"). The author asked Claude to reconstruct the accuracy history of the main outputs, the CMB angular power spectra, with milestones labeled, and shows the resulting plot.
The post is frank about the trajectory. It calls it "somewhat clunky": for a while Claude tested the code at only one parameter point, which greatly reduced the tests' ability to catch bugs; it made elementary mistakes such as confusing gauge conventions; and it spent hours on bugs that a cosmologist would spot immediately. It nonetheless kept making progress toward the goal. The final solver is described as not production-grade: it does not match CLASS to acceptable accuracy in every regime. The author's conclusion is that agent-driven development "can compress months or even years of researcher work into days."
Two further observations close the post. The author says he learned a good deal about Boltzmann solvers by following the commit history, which read "like lab notes from a fast, hyper-literal postdoc." And he argues that with compute and well-defined projects available, nights without agents running now carry an opportunity cost.
Limitations and open questions
- One example, one author. The claims rest on a single project, described by the person who ran it; there is no comparison with a human-written or conversationally supervised version.
- Accuracy is reported at a high level. "Sub-percent agreement" is stated without per-output figures in the text; the plot and the linked repository hold the details.
- Human time is not measured. The post describes occasional check-ins but does not report how many hours of oversight the project took.
- Fit to the task. The method depends on a reference implementation as an oracle. The post itself limits it to well-scoped work with clear success criteria and says more open-ended discovery is still ahead.
Research questions
- How much does the progress file's record of failed approaches save? The post says later sessions otherwise repeat dead ends. Running matched projects with and without a failed-approaches section, and counting repeated attempts, would measure the effect.
- How do instruction-file wording and detail affect long runs? The post gives example rules but no comparison. Varying the specificity of CLAUDE.md on the same task, and measuring progress and rule violations, would show what kind of instruction matters.
- Does the Ralph loop raise quality or only run time? Comparing final accuracy and cost with and without the loop, at the same iteration budget, would separate genuine completion from extra iterations.
- How much does test coverage determine outcomes? The period of single-point testing is one example. Seeding a solver with known bugs and measuring how many are caught under different test designs would quantify the dependence.
- How does non-expert supervision compare with expert supervision? The author was outside his field. Having a domain expert and a non-expert supervise the same task would show what expertise adds; the Vibe physics post reports the expert side for a different task.
How it connects
- Introducing our Science Blog names this post as one of the blog's two launch pieces, a tutorial on long-running tasks for scientific computation.
References
- Mishra-Sharma, S. (2026, March 23). Long-running Claude for scientific computing. Anthropic. https://www.anthropic.com/research/long-running-Claude
- Project repository linked from the post, including the early CLAUDE.md and the CHANGELOG.md: https://github.com/smsharma/clax. Not reviewed for this note beyond the post's description.