Autonomous R&D That Remembers What It Learned
A research loop that starts every cycle from a blank state is automation, not research. What makes R&D autonomous, why agents alone fall short, and where it applies.
An autonomous research system is only autonomous if it remembers what it learned. A loop that runs experiments but starts every cycle from the same blank state is automation, not research.
The short answer: autonomous R&D needs a persistent, explicit model of what is known — hypotheses, results, failures and the conditions behind each — that the system updates after every experiment and reasons over before the next one. Language-model agents are good at planning a step and writing the code to run it, but they keep nothing between runs and cannot show why they chose what they chose. GitMir puts the reasoning and the memory outside the model: the system observes, updates its structured model of the world, acts through agents, instruments or robots, verifies the outcome against the model and the evidence, and learns from what held and what did not. The model of the world grows with every cycle, and the reasoning stays inspectable throughout.
This article is about what makes R&D genuinely autonomous, why agents alone do not get there, and where the approach applies. Its companion piece covers governance: in autonomous R&D, the reasoning is the artifact.
Automation is not autonomy
Laboratory automation has existed for decades: robots that pipette, instruments that run queues, scripts that schedule overnight batches. What they automate is execution. A person still decides what to run next and why, reads the results and changes the plan.
Autonomous R&D moves that decision into the system. That requires four things automation never needed:
- A model of what is known — not a folder of results, but explicit claims about the system under study, each tied to the experiments that support or contradict it.
- A way to choose the next action — which experiment would teach the most, given what is known and what it costs.
- A way to judge an outcome — whether a result confirms, refutes or complicates the current model, under which conditions.
- Memory that changes behaviour — so that cycle fifty acts on what cycles one to forty-nine established, including their failures.
Why language-model agents fall short on their own
Agents built on language models can already plan, call tools and write code to drive instruments. That is useful, and they have a place in the loop. On their own they hit the same walls in every cycle:
- No durable state. What an agent concluded in the last run is not a premise in the next one unless it is written back into its context — and context is finite, while a research programme is not.
- No visible reasoning. The choice of the next experiment comes out as text. Nothing distinguishes a choice grounded in results from one that merely sounded right.
- No stable judgement. Asked twice to interpret the same result, an agent can answer differently. A loop built on unstable judgement drifts.
- No memory of failure. A route that failed three weeks ago looks as promising as ever to a model that does not remember it.
The loop, with the reasoning outside the model
GitMir's approach keeps the loop's knowledge in an explicit structure the system owns:
- Observe. New results, sensor data, reports and literature arrive and are turned into claims, each with its source and conditions.
- Model. The structured model of the world is updated: which hypotheses gained support, which lost it, what is now contradicted.
- Act. The next experiment is chosen by how much it would change the model and what it costs, then carried out by agents, instruments or robots.
- Verify. The outcome is checked against the model and the evidence — deterministically, so the same result always gets the same judgement.
- Learn. What held becomes a premise; what did not is kept as a refuted path. The structure itself changes as the system reasons.
The language model is one component in this loop — reading unstructured results, proposing candidate actions, writing the code an instrument needs — not the intelligence of the loop.
Because the reasoning is a living structure of connected meanings that reshapes itself with every cycle, the system is self-learning in a concrete sense: its next decision is made from a different, better-informed model than its last one, and anyone can see what changed.
Use cases
- Closed-loop experimentation. Self-driving lab setups in chemistry and materials, where the system proposes a synthesis, a robot runs it, an instrument measures it and the result updates the model before the next proposal. The value is not speed alone; it is that every proposal is grounded in everything run so far. The broader field is described under laboratory automation.
- Process optimisation in manufacturing. Tuning a production process across many parameters, where each trial is costly and the constraints — quality, safety, throughput — must hold throughout. The model keeps which settings failed and why.
- Robotics in the field. Machines that adapt their behaviour from outcomes while working on limited hardware, using frameworks built around objects that take their data from the structured model. We describe this on the GitMir Science page.
- Continuous evaluation. Systems that test a product, a model or a design against an evolving set of requirements, remember every failure mode found and aim new tests at what is least covered.
- Drug discovery cycles. Design, make, test, analyse — with the hypotheses and their evidence held explicitly across cycles, so that a compound series is steered by what the previous rounds established. See hypotheses you can check step by step.
Status
Autonomous R&D is a research direction GitMir Science is actively working on. The loop and the use cases describe what the approach is built for and where we are applying it; they are not a report of deployed autonomous labs. Results will be published with method, scope and limitations. If you run experiments in cycles and want the system to learn between them, write to GitMir Science.
More on this, with the numbers behind it
What business logic is, and where it lives →Features, rules, customer paths and how they connect — why nothing a team already owns holds them in one place, and what that costs.What your AI actually costs →Your engineers, your loaded cost, your monthly AI bill — counted on your own numbers, not ours.Ask a published model your own question →A real product, read in full. Ask it what a change reaches and check the answer against the source it came from.Benchmark 001, in full →One repository, fifty questions, every system, the same AI model — and how to repeat it.GitMir Intelligence →Ask what a change reaches, what a rule holds and which customer path meets it — with the part of the product each answer came from.Put a number on your own workflow
Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 10,000 credits free, no card.
Build My Business Case → Start free →Frequently asked questions
What is the difference between lab automation and autonomous R&D?
Automation executes a plan a person made. Autonomous R&D chooses the next experiment itself, judges the outcome and updates what it knows, so each cycle is planned from everything established so far.
Can't a language-model agent run an autonomous research loop?
It can plan steps and drive tools, but it keeps nothing durable between runs, its reasoning is not inspectable, it can judge the same result differently twice and it forgets failures. GitMir keeps the loop's knowledge and reasoning outside the model and uses the model as a component.
What does "self-learning" mean here?
After every cycle the structured model of the world changes: supported claims become premises, refuted paths are kept, and the next decision is made from that updated model. Anyone can see exactly what changed and why.
Does the system need a robot?
No. The action step can be an instrument queue, a simulation, a software agent or a person running a protocol. The loop is the same.



