Outerloop

Autoresearch agents that improve your benchmark.

Outerloop runs AI agents on your own research code. An agent proposes a
change, runs the experiment on your cluster, and opens a pull request only
when your benchmark actually improves. Every attempt ends in a short
written report, including the attempts that failed.

You run it yourself, with your own keys, your own compute and your own
repositories, and nothing reports back to us. It is built and used every
day by the Agentic Learning AI Lab at NYU,
where it co-develops our research codebases.

Get started

Three commands and one file. You need a repo with a benchmark command, an
API key for the model that will write the code, and a Slurm cluster or one
machine with a GPU.

pip install outerloop-science
outerloop init     # where the loop runs, which repo, which model and its key, your GitHub identity

The wizard asks for a GitHub identity for the agents to open pull requests
as. Pick app and it walks you through creating a GitHub App under your
account and installing it on the repo. Pick pat if you already have a
token, and it writes the config and the key files either way. Then add one
file, .outerloop.yaml, to the repo you want improved:

benchmarks:
  - name: my-benchmark
    command: uv run python -m mypkg.eval --json   # prints {"success_rate": 0.42}
    metric: success_rate
    direction: max
budgets:
  gpu_hours_per_run: 8
  runs_per_week: 10
scope:
  allowed: [src/mypkg/solver/]   # the only paths an agent may change
roadmap: docs/roadmap.md # what the agents read for direction; never written

outerloop start    # on a Slurm login node this submits the loop; without Slurm it runs in the foreground

The install guide walks through
every step, including the other model backends. The
contract guide explains the
decisions the contract asks you to make.

The loop

1. Propose. An agent picks a hypothesis and writes the code change.
2. Experiment. It runs the training on your cluster and reads the results.
3. Measure. Outerloop scores the change against the base tree at the same
   seed. Noise does not count as an improvement.
4. Review. Judges read the change and the claim. If both hold up, a pull
   request opens.
5. Record. Every attempt gets a short report: hypothesis, change,
   outcome, next step. Negative results included.

An agent's whole workspace is mounted writable, so scope is not a per-path
sandbox: the kernel rejects a candidate whose changes fall outside the paths
the contract allows, or touch the contract, your roadmap or .github/. Keep
the benchmark's own eval code outside those allowed paths, so a doctored
ruler cannot survive into a measured candidate. Your branch protection and required checks
apply to them as to any contributor. By default a pull request waits for a
human, and a repo can also let clean ones merge themselves. The full
picture is in
how it works, and the
operate guide covers running
and steering runs.

Pull request reviews only

The reviewer works on its own, with one workflow file and an API key, about
five minutes of setup, and no bot account or cluster. It comments on pull
requests with concrete findings and never approves, blocks, or fails your
build. See the reviewer guide.

Safety by design

• Opt-in and contract-bound. A repo takes part by granting the bot
  access and committing a contract. The kernel rejects a change that touches
  the contract, your roadmap, or .github/.
• Nothing on trust. In the default gate mode, Outerloop measures every
  claim itself, on committed trees, and re-verifies before a pull request
  exists. A repo can instead opt into labelled self-reported numbers.
• Untrusted input. Pull request text, diffs, issues, web pages, and job
  output are rendered to the agent as fenced data, not instructions, which
  lowers the risk of injected text being followed without guaranteeing it.
  A contained session gets no GitHub credential in its environment and
  cannot read the operator's key files; an uncontained local session runs
  as your user and can read any file you can, key files included.
• Budgets in code. Launches, GPU-hours, and runs per week are enforced
  by the kernel, not left to the agent.
• No model lock-in. Claude Code, Codex, and hermes-agent are wired
  today, including self-hosted endpoints.

Further reading: the architecture page for the full design, the roadmap for what is planned, and the community page for where to ask questions.

Developing

uv sync
uv run pre-commit install
uv run pytest

License

Apache License 2.0 — see LICENSE and NOTICE.