|
1 | | -# VeRO: Versioning Rewards and Observations |
| 1 | +# VeRO: a harness for agents to optimize programs, text, and agents |
| 2 | +> **Looking for the code from the VeRO paper?** See |
| 3 | +> [Paper reproduction](#paper-reproduction) — reproduce from the `paper-v1` |
| 4 | +> tag, or read the same code in place under [`legacy/`](legacy/). |
2 | 5 |
|
3 | 6 | [](https://arxiv.org/abs/2602.22480) |
4 | 7 | [](LICENSE) |
| 8 | +[](https://www.python.org/) |
5 | 9 |
|
6 | | -VeRO is an evaluation harness for using coding agents to optimize LLM-based agents and workflows. It treats agent code as a versioned artifact — making changes, evaluating results, and hill-climbing toward better performance using git version control. |
7 | | - |
8 | | -> **Paper**: [VeRO: An Evaluation Harness for Agents to Optimize Agents](https://arxiv.org/abs/2602.22480) |
9 | | -
|
10 | | -## Repository Structure |
| 10 | +VeRO gives a coding agent something to edit, an evaluation boundary, and durable |
| 11 | +memory of every candidate it tried. The target is anything you can put under Git |
| 12 | +and score — a **program** (a single function up to a whole codebase), **text** |
| 13 | +(a prompt, spec, or config), or an **agent** (its scaffold, tools, and prompts). |
| 14 | +VeRO was introduced to optimize agents, and the same version / evaluate / select |
| 15 | +loop applies to any of these. |
11 | 16 |
|
12 | 17 | ``` |
13 | | -vero/ |
14 | | -├── vero/ # Core library (scale-vero) |
15 | | -├── vero-agents/ # Agent implementations (benchmarking targets) |
16 | | -├── vero-benchmarking/ # Benchmarking scripts and analysis |
17 | | -└── LICENSE |
| 18 | + ┌─────────────────────────┐ submit candidate ┌─────────────────────────┐ |
| 19 | + │ candidate production ├──────────────────────►│ evaluation service │ |
| 20 | + │ │ │ │ |
| 21 | + │ coding agent, command, │◄──────────────────────┤ owns cases + scoring │ |
| 22 | + │ or custom strategy; │ score + diagnostics │ │ |
| 23 | + │ edits its own Git │ │ development: may ask │ |
| 24 | + │ worktree per candidate │ │ validation: aggregate │ |
| 25 | + └───────────┬─────────────┘ │ test: withheld │ |
| 26 | + │ commit └───────────┬─────────────┘ |
| 27 | + ▼ │ report |
| 28 | + ┌─────────────────────────┐ next round ┌───────────────▼─────────────┐ |
| 29 | + │ candidate history: │◄──────────────────┤ selection: keep the best │ |
| 30 | + │ every version kept, │ │ feasible candidate │ |
| 31 | + │ each one re-selectable │ └─────────────────────────────┘ |
| 32 | + └─────────────────────────┘ |
| 33 | +
|
| 34 | + Every model call on both sides goes through the inference gateway, which holds |
| 35 | + the provider key and meters spend in tokens against a per-scope budget. |
18 | 36 | ``` |
19 | 37 |
|
20 | | -### [vero/](vero/) |
21 | | - |
22 | | -The core optimization framework. Provides: |
23 | | - |
24 | | -- **Policy** — orchestrates the optimization loop (agent + evaluator + git) |
25 | | -- **Agents** — VeroAgent (OpenAI Agents SDK) and ClaudeCodeAgent (Claude Agent SDK) |
26 | | -- **Evaluator** — runs task evaluations in isolated subprocess environments |
27 | | -- **Tools** — MCP-based tools for agents (bash, file I/O, experiment runner, dataset viewer, etc.) |
28 | | -- **Traces** — session analysis and LLM-based trace interpretation |
29 | | - |
30 | | -```bash |
31 | | -cd vero && uv sync --extra optimize |
32 | | -``` |
33 | | - |
34 | | -See [vero/README.md](vero/README.md) for full documentation. |
35 | | - |
36 | | -### [vero-agents/](vero-agents/) |
| 38 | +The target and evaluator do not need to be Python. External evaluators and |
| 39 | +candidate producers connect through command protocols; Python benchmarks can |
| 40 | +use the optional, optimizer-independent `scale-vero-tasks` package. |
37 | 41 |
|
38 | | -Agent implementations used as optimization targets: |
| 42 | +Targets may live locally or in an isolated sandbox. VeRO keeps optimization |
| 43 | +state and experiment tracking on the host while running Git worktrees, producer |
| 44 | +commands, builds, and evaluation commands in the target sandbox. The core guide |
| 45 | +includes a no-bind-mount `DockerSandbox` example. |
39 | 46 |
|
40 | | -| Agent | Description | |
41 | | -|-------|-------------| |
42 | | -| **generic-agent** | General-purpose agent for MATH, GPQA, GAIA, GSM8K, etc. | |
43 | | -| **web_search_agent** | Web search agent for SimpleQA, Facts Search | |
44 | | -| **KIRA** | Terminal task agent for Terminal Bench 2.0 | |
45 | | -| **tau-bench** | Customer service tool-use agent | |
46 | | -| **pharma_summarizer** | Document summarization agent | |
| 47 | +## Repository layout |
47 | 48 |
|
48 | | -See [vero-agents/README.md](vero-agents/README.md) for details. |
| 49 | +| Directory | Purpose | |
| 50 | +| --- | --- | |
| 51 | +| [`vero/`](vero/) | The `scale-vero` optimization kernel, runtime, CLI, and coding-agent adapters | |
| 52 | +| [`vero-tasks/`](vero-tasks/) | Narrow Python task types and schema-v1 evaluation runner | |
| 53 | +| [`harness-engineering-bench/`](harness-engineering-bench/) | Harbor-native target programs and end-to-end optimization benchmarks | |
| 54 | +| [`legacy/`](legacy/) | The pre-v0.5 tree, i.e. the original VeRO paper code — reference only, not used by the current system | |
49 | 55 |
|
50 | | -### [vero-benchmarking/](vero-benchmarking/) |
| 56 | +Start with the [generic C matrix-multiplication quickstart](vero/examples/c-matmul/), |
| 57 | +try the [26-circle packing benchmark](vero/examples/circle-packing/), or read the |
| 58 | +[core guide](vero/README.md). The C example demonstrates the language-neutral |
| 59 | +command protocol without model credentials. Circle packing is a substantive |
| 60 | +coding-agent benchmark with exact geometry checks and inspectable search |
| 61 | +artifacts. |
51 | 62 |
|
52 | | -Scripts and infrastructure for running optimization experiments: |
| 63 | +For a full agent-optimization example, the [GAIA benchmark](harness-engineering-bench/gaia/) |
| 64 | +pairs a tool-using GPT-5.4 mini target with Harbor's canonical GAIA verifier and |
| 65 | +an immutable 20% / 40% / 40% development, validation, and test split. |
53 | 66 |
|
54 | 67 | ```bash |
55 | | -cd vero-benchmarking && uv sync --all-extras |
56 | | - |
57 | | -# Run an optimization experiment |
58 | | -uv run python scripts/run_benchmark.py --scaffold claude-code-vmf --model sonnet --task math |
59 | | - |
60 | | -# Build datasets |
61 | | -./scripts/build_datasets.sh |
| 68 | +cd vero |
| 69 | +uv sync --all-extras |
| 70 | +uv run vero --help |
62 | 71 | ``` |
63 | 72 |
|
64 | | -See [vero-benchmarking/README.md](vero-benchmarking/README.md) for full documentation. |
| 73 | +## Paper reproduction |
65 | 74 |
|
66 | | -## Quick Start |
| 75 | +VeRO was introduced in [*VeRO: A Harness for Agents to Optimize |
| 76 | +Agents*](https://arxiv.org/abs/2602.22480), accepted at ICML 2026. The current |
| 77 | +library generalizes that version/evaluate/select loop from agents to programs. |
67 | 78 |
|
68 | | -### Prerequisites |
| 79 | +The paper-era code is available two ways, and they hold the same code: |
69 | 80 |
|
70 | | -- Python 3.11+ |
71 | | -- [uv](https://docs.astral.sh/uv/getting-started/installation/) |
72 | | -- Git |
73 | | -- Access to an LLM provider (via LiteLLM, OpenAI, Anthropic, etc.) |
74 | | - |
75 | | -### Install |
| 81 | +**To reproduce the paper, use the frozen ref.** It is the repository exactly as |
| 82 | +it stood at publication, with the original paths intact: |
76 | 83 |
|
77 | 84 | ```bash |
78 | | -git clone <repo-url> && cd vero |
79 | | - |
80 | | -# Install core library |
81 | | -cd vero && uv sync --extra optimize |
82 | | - |
83 | | -# Install benchmarking tools |
84 | | -cd ../vero-benchmarking && uv sync --all-extras |
| 85 | +git checkout paper-v1 # tag; the paper/v1 branch points at the same commit |
85 | 86 | ``` |
86 | 87 |
|
87 | | -### Run Your First Optimization |
88 | | - |
89 | | -```python |
90 | | -from agents import Agent as OAIAgent |
91 | | -from vero.policy import Policy |
92 | | -from vero.agents.vero import VeroAgent |
93 | | - |
94 | | -policy = Policy( |
95 | | - project_path="/path/to/my-agent", |
96 | | - dataset="/path/to/my-dataset", |
97 | | - agent=VeroAgent( |
98 | | - oai_agent=OAIAgent(name="VeroAgent", model="anthropic/claude-sonnet-4-5-20250929"), |
99 | | - ), |
100 | | - task="main", |
101 | | - train_budget=10, |
102 | | - max_turns=200, |
103 | | -) |
104 | | - |
105 | | -best = await policy.run() |
106 | | -print(f"Best commit: {best.commit}, score: {best.score}") |
107 | | -``` |
| 88 | +**To read that code alongside the current system, use [`legacy/`](legacy/).** The |
| 89 | +v0.5 redesign relocated the paper-era tree into that directory rather than |
| 90 | +deleting it, so it sits in this branch next to the code that replaced it. Both |
| 91 | +the frozen ref and `legacy/` include the paper-era `vero-agents` and |
| 92 | +`vero-benchmarking` directories; their Harbor-native replacement is |
| 93 | +[`harness-engineering-bench/`](harness-engineering-bench/). |
| 94 | + |
| 95 | +Prefer the frozen ref for reproduction, since it is the state that was actually |
| 96 | +published. Either way, note that both packages are named `scale-vero` and both |
| 97 | +import as `vero` (0.4.7 in `legacy/vero`, 0.5.0 in `vero/`), so **they cannot be |
| 98 | +installed into the same environment** — give the legacy package its own |
| 99 | +virtualenv. Development of the current system continues on `main`. |
108 | 100 |
|
109 | 101 | ## Citation |
110 | 102 |
|
111 | 103 | ```bibtex |
112 | 104 | @article{ursekar2026vero, |
113 | | - title={VeRO: An Evaluation Harness for Agents to Optimize Agents}, |
| 105 | + title={VeRO: A Harness for Agents to Optimize Agents}, |
114 | 106 | author={Ursekar, Varun and Shanker, Apaar and Chatrath, Veronica and Xue, Yuan (Emily) and Denton, Sam}, |
115 | 107 | journal={arXiv preprint arXiv:2602.22480}, |
116 | 108 | year={2026} |
117 | 109 | } |
118 | 110 | ``` |
119 | 111 |
|
120 | | -## License |
121 | | - |
122 | | -[MIT](LICENSE) |
| 112 | +VeRO is licensed under the [MIT License](LICENSE). |
0 commit comments