Arbor: the RUC-NLPIR autonomous research agent that keeps a hypothesis tree

What Arbor optimizes, and who has that problem

Arbor targets a narrow but common situation: you have a task with a number attached to it and a codebase you are allowed to edit. Prompt engineering for a retrieval pipeline, a training recipe, a data synthesis script. The README frames this as optimizing "any task with a target to improve and a metric to measure." The agent proposes changes, runs them, and keeps what works.

The intended user is not someone looking for a chat assistant. It is an engineer or researcher who would otherwise spend days running one experiment at a time and losing track of which variants were already tried. The README's own framing is that Arbor grows a hypothesis tree "instead of forgetting what failed." That is the real pitch: memory of failed branches, not raw model quality.

The task table in the README reports Arbor ahead of Claude Code and Codex on BrowseComp, Terminal-Bench 2.0 and a math-reasoning data task, plus 86.36% Any-Medal on MLE-Bench Lite with GPT-5.5. Those are the project's numbers from its own evaluation, not an independent reproduction.

The Coordinator, the Executor and the six-step arbor cycle

Arbor runs two cooperating agents. The Coordinator is the research director: it maintains the Idea Tree, drives the search, and dispatches experiments. The Executor is the research engineer: given one idea, it implements the code change, runs the experiment in an isolated git worktree, and reports evidence back.

The loop between them is the arbor cycle, six steps. Observe: the Coordinator re-reads the tree, the active frontier, constraints, ancestor insights, recent evidence and the current best artifact. Ideate: it picks a parent node and proposes children that refine, correct or extend what the tree already learned. Select: it chooses which pending leaves to test, balancing the best current direction against unresolved alternatives. Dispatch: selected hypotheses go to independent Executors in fresh worktrees, evaluated on the dev signal. Backpropagate: results, scores, insights and branches are recorded, and the lesson is abstracted upward so ancestors inherit it. Decide: merge, prune, continue, leave pending, or stop, with held-out validation used for the merge decision.

The isolation detail matters more than the agent framing. Each Executor works in its own git worktree, so main is not touched until a merge. The README states that only gains clearing a configurable margin are merged. That margin is the main dial between exploration and noise: set it too low and you merge variance.

Installing arbor-agent and watching the hypothesis tree

The README gives a thirty-second path that needs no API key and no config. The package name on PyPI is arbor-agent, and the demo subcommand replays a recorded run so you can see the tree grow before spending anything on model calls.

pip install arbor-agent && arbor replay --demo

What you should see is a terminal view of the Idea Tree filling in, with nodes appearing as hypotheses are proposed and marked as results come back. There is also a browser demo linked from the README if you would rather not install anything at all.

For a real run you need a config. The repository ships examples/kaggle_config.example.yaml and examples/research_config.example.yaml, and the README points at a one-line domain plugin mechanism for steering. Backends are selected through LiteLLM, so Anthropic, the OpenAI Responses API and OpenAI-compatible endpoints such as DeepSeek, Gemini, Qwen, vLLM and Ollama are all reachable. The entry points installed by the package are arbor, executor and coordinator, so you can also drive the two agents separately.

One constraint to check before you install: pyproject.toml sets requires-python = ">=3.10", but the alphaxiv-py dependency is gated with a marker for Python 3.12 and above. On 3.10 or 3.11 the literature backend is skipped and degrades with a runtime message rather than failing the install.

Literature search, novelty checks and the arbor idea-check command

Since the 2026-06-22 release, Arbor can ground an idea in prior work before spending compute on it. The backend is the public alphaXiv API, and the README says it needs no search endpoint and no key. Two entry points exist: the Coordinator can vet every new branch automatically, or you can ask directly.

arbor idea-check "<your idea>"

The value here is timing. A novelty check that runs at intake is cheaper than an Executor worktree that reproduces something already published. The limitation is equally clear: the check depends on a third-party public API and on whatever that API indexes. The README does not describe a self-hosted or offline mode for literature search, so a run on an air-gapped machine loses this capability. It also does not document what happens when the API is unreachable mid-run, beyond the graceful degradation noted for older Python versions.

Where Arbor is the wrong tool

Arbor needs a metric. If your target is qualitative, or the acceptance test is a human reading output, there is nothing for the held-out split to validate against and the merge rule has no meaning. The README does not document a scoring mode for subjective evaluation.

The second constraint is the worktree model. Executors edit code and run experiments, so the project must be runnable non-interactively from a fresh checkout. A codebase that needs manual setup, a licensed dataset, or a long interactive login will stall the loop. The README does not document a path for experiments that cannot be scripted.

Third, cost is bounded by the model budget, not by Arbor. The headline comparison is explicitly "on the same compute budget," which means the advantage is in how budget is spent, not in spending less of it. A team with no budget for repeated model calls gets the demo and little else.

Finally, the release history is short. v0.1.2, v0.1.3 and v0.1.4 landed between 2026-06-22 and 2026-07-12. The last push to main was on 2026-09-08, so work is ongoing, but a 0.1.x line with three releases in three weeks is a project still finding its interfaces. Expect config and CLI surface to move.

Arbor against a general coding agent

The obvious alternative is the general coding agent you already use, such as Claude Code or Codex. The README positions Arbor against exactly those, and the difference is structural rather than a matter of model choice.

A general coding agent works in one conversation against one working state. You ask for a change, it makes the change, and the history of what was tried lives in the transcript. Arbor's Coordinator maintains an Idea Tree across the whole run, and the backpropagate step abstracts each result upward so later hypotheses inherit the lesson. That is the mechanism the README credits for the comparison numbers.

A second difference is evaluation discipline. Arbor's Executors iterate on a dev split and validate merges on a held-out test split, each in a separate git worktree. A general coding agent has no built-in notion of a held-out split, so nothing stops it from tuning against the same signal it reports. If you already have a harness that enforces that split, the gap narrows. If you do not, Arbor supplies the discipline.

Arbor is also usable inside those agents: the README describes an Agent Skill Suite for Codex and Claude Code, plus an optional MCP server installed with pip install arbor-agent[mcp] that exposes Arbor's deterministic tools to a host coding agent.

Licence, upgrade cost and what to verify first

Arbor is Apache-2.0, with license-files = ["LICENSE"] declared in pyproject.toml. That is a permissive licence with an explicit patent grant, and it imposes no copyleft on your own code. It says nothing about the terms of the model backends you point it at, the alphaXiv API, or any dataset your experiments touch; those are separate agreements and this is not legal advice.

The upgrade cost is concentrated in the config files. examples/kaggle_config.example.yaml and examples/research_config.example.yaml are the templates the repository ships, and a 0.1.x line that shipped three releases in three weeks is likely to change keys. The safer pattern is to keep your task definition and metric in your own repository and treat Arbor's config as a thin layer you re-derive from the examples at each version bump.

Before a first real run, confirm four things: that your interpreter satisfies requires-python >=3.10 and whether you are above or below the 3.12 alphaxiv-py marker; that your task exposes a dev signal and a held-out split; that the project builds and tests non-interactively from a clean worktree; and that the merge margin is set high enough that you are not merging run-to-run variance. The README does not document a rollback procedure for a merged branch, so keep main protected until you have watched one full cycle.

Editorial conclusion

Adopt Arbor if you already have a task with a numeric metric, a dev split and a held-out test split, and you want the search history kept as a tree instead of a chat log. Skip it if your work has no measurable target, if you cannot give the Executor a working build and test command, or if you need a tool that runs entirely offline, since the literature backends call public endpoints. Before trusting a run, verify three things in the repository: that requires-python >=3.10 matches your interpreter, that alphaxiv-py is skipped on Python 3.10 and 3.11 as pyproject.toml states, and that merge decisions really use the held-out split rather than the dev signal the Executors optimize against.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. RUC-NLPIR/Arbor on GitHub