Infrastructure for RSI research: running and evaluating self-improving agents

A research agent changes a search tool in its own code. It solves a task it previously failed. Can it now solve other tasks? Can the improved version find a useful change again? Investigating that means repeatedly editing programs, running experiments, and comparing the results. Beeuni provides a computer where agents can carry out that work with your code, tools, and evaluation scripts.

Recursive self-improvement, or RSI, asks whether a system can improve itself, including how it produces further improvements. In agent experiments, this can mean changing the agent’s code, instructions, or tools, testing the change, and using a successful version for the next attempt. A search-tool experiment gives us a concrete way to explain how Beeuni can help throughout that process.

Give Beeuni the code and a specific question

Connect the repository containing your agent and its tests. Tell Beeuni how to install it, which command runs the evaluation, and which part it may change. A useful first question is narrow: can the search tool return the relevant function without sending the whole file to the model?

The research question determines what the agent may edit. You might study whether different instructions improve planning, whether a new search implementation reduces unnecessary reading, or whether changed memory handling helps later tasks. Keep these experiments distinguishable. Changing model weights is another research setup, with its own training method and compute requirements.

Inspect the file-search tool in this repository.
Run the existing coding-task tests before changing it.
Try returning matching functions with their file paths and line numbers.
Keep the model and test settings unchanged.
Run the same tests again. Save the patch, raw logs, and a comparison report.
Do not change the tests or merge the code.

Beeuni can read the implementation, run the installation commands, and execute your tests in the terminal. If a dependency is missing or a test crashes, it can inspect the error and investigate. You can follow the work in the session and open the files it creates.

Run the original tool before trying the replacement

Start by asking Beeuni to run the unchanged agent. Save which tasks passed, which failed, and the errors. If your test runner records model usage, tool calls, or elapsed time, include those fields too. You now have something concrete to compare with the edited version.

Next, let the agent change the search tool and run the same command again. Keep the model, task list, and limits unchanged for this comparison. Ask it to explain each changed result with the relevant log. A lower token count is worth investigating, but so is a newly failed task where the shorter search result omitted important code.

These are files you ask the agent to produce using your scripts. Beeuni does not supply the research benchmark or decide what counts as an improvement. You bring the tasks and scoring code; the agent helps run them and investigate the results.

Use the failures to choose the next change

Suppose the replacement handles small files well but fails when a function calls a helper in another file. Ask Beeuni to inspect that failed task, find the missing context, and propose a more targeted change. You might add related function names to the search result rather than return every file in full again.

Review the patch and report before accepting the change. Then test it on other tasks. Passing the example that prompted the edit tells you less than succeeding on tasks the agent has not been adjusting its code around. Keep final scoring tests outside the files the agent may edit.

The same approach works for a browser agent. Give Beeuni a test application and a task such as finding an order and updating its delivery note. It can operate the browser, inspect the outcome, and save evidence of a failure. Reset the application’s test data before comparing another version so both start with the same order.

Arrange repeated experiments through your own program

For repeated experiments, a controller is the program that arranges the rounds. It selects an agent version, requests a change, starts tests, and decides what to try next. A candidate is the changed agent version being tested in that round. Your controller can use the API or TypeScript SDK to start and inspect Beeuni sessions while keeping the selection rules in your research code.

Each session has its own execution environment. You can test two tool implementations without having them overwrite the same working files or dependencies. The program tested inside the computer should start from the intended code revision. When a script loads code only at startup, restart that script after an edit so the test actually uses the new implementation.

Start with a small experiment queue. Set limits for attempts, concurrent sessions, runtime, and model use in the controller. When it reaches a limit, have it stop the relevant work and check that the processes ended. These rules determine how much searching the experiment is allowed to do before choosing a version.

Give each version a fair test

An agent that can see the answer key or change the tests could obtain a higher score without becoming better at the task. Run final scoring separately, keep hidden answers out of the files the agent can access, and prevent it from changing the scoring code. Beeuni can execute development tests and collect outputs; your evaluation program can score those outputs separately. In browser experiments, reset shared application data between versions, since a fresh computer still sees records left in the same external application.

Compare task success, errors, elapsed time, tool calls, and model usage where your runner records them. Keep the task set, model settings, and execution limits comparable. Repeat uncertain results. A change may read fewer tokens but miss a helper function, or pass more tasks by making many more model calls. The report should make that tradeoff visible.

Count the cost of finding the change too. Record the attempts used to propose and test versions separately from the cost of running the version you selected. A final agent may be cheaper per task while requiring an expensive search to discover it. Both measurements matter when judging the experiment.

Keep enough detail to explain a failed round

A failed task and an unavailable model API need different follow-up. Ask Beeuni to retain raw errors and logs before summarizing them. Your results can distinguish incorrect answers, missing dependencies, model-request failures, and exhausted time limits. Decide explicitly which failures receive another attempt rather than silently rerunning every failure until it passes.

Save the original and changed code revisions, instructions, launch commands, dependencies, test-set version, scoring code version, and per-task results. Record which earlier version each change came from. Beeuni can help write this experiment record alongside the patch and logs, so you can inspect why a version was selected or rejected.

Keep the useful patches and reports in your chosen repository or storage before removing the experiment computer. You can then trace a result back to the code and command that produced it, including attempts you rejected.

Test whether the next improvement attempt gets better

After choosing a version, evaluate it on tasks that did not guide the edits. Then use it for further improvement attempts and compare those attempts with the original agent’s. Does it find useful changes more often, need fewer attempts, or produce fewer regressions under the same budget? Solving more tasks is one result. Improving the process that produces later improvements is the additional question RSI research needs to investigate.

For a research example, the Darwin Gödel Machine paper explores agents that modify their own code and test the changes. Self-Refine studies revising an answer using feedback without additional training. That distinction helps define your experiment: are you improving one answer, the agent’s way of working, or its ability to find the next improvement? Beeuni can help carry out the code edits, command execution, and result inspection. You design the research method. If your experiment needs model training, see running fine-tuning work with Beeuni.

To try the search-tool experiment, begin with one repository and one working test command. The Computer guide explains how to inspect the environment and process output while Beeuni works.