Can Agents Design Libraries for Agents?
Gabriel Orlanski, Alex L. Zhang, Avi Trost, Vincent Sunn Chen, Frederic Sala, Aws Albarghouthi, Ludwig Schmidt
University of Wisconsin–Madison · Massachusetts Institute of Technology · Snorkel AI · Stanford University
Published September 29, 2026 · on the feed September 30, 2026 · ▲ 11 · arXiv 2609.36730
The abstract
Agents increasingly build on code written by other agents, and they reimplement rather than reuse, growing the codebases later agents must work in. To measure how well agents design libraries for other agents, we introduce LibraryDesignBench, a two-phase benchmark in which an agent implements a full-featured library from a specification that defines required capabilities and potential use cases without prescribing the design. We evaluate the library through the correctness and simplicity of programs written by three user agents from different model families. The benchmark spans 242 expert-validated programming problems across 15 library-design tasks in four languages. On eleven of the fifteen tasks, agent designers reproduce the abstractions of the human-written production library. Downstream agents adopt agent- and human-written libraries alike but underuse them, reimplementing capabilities the library already provides. Our failure analysis finds that downstream agents write extra code mainly because agent-written libraries are rigid or hard to use, not because capabilities are missing. We also experiment with giving designers more prescriptive, agent-first guidance and having them test their library with subagents; this improves downstream scores and yields simpler programs. LibraryDesignBench provides both a testbed for evaluating library-design practices for agent users and an initial design baseline that improves downstream reuse.
The Brief
2:35A short podcast summary of the paper. Written and voiced by AI.
Transcript
Can Agents Design Libraries for Agents?. By Gabriel Orlanski and six others, from the University of Wisconsin–Madison, the Massachusetts Institute of Technology, and two other institutions. Published on the twenty-ninth of September. Its code repository is worked out: about one hundred and twenty source files, with a readme and a licence.
Agents increasingly build on code that other agents wrote. And they tend to reimplement rather than reuse, which grows the codebases that later agents then have to work in. Each duplicate makes the next agent's job a little harder, and the cost compounds. That raises a question the authors set out to measure: how well do agents design libraries meant for other agents to use? Writing code that works is one skill. Writing code that someone else will actually pick up and build on is another.
LibraryDesignBench is a two-phase benchmark. In the first phase, an agent implements a full-featured library from a specification. The specification defines the required capabilities and potential use cases, but it does not prescribe the design. In the second phase, the library is judged through its users. Three user agents, from different model families, write programs with it, and those programs are scored for correctness and for simplicity. A library is good, by this measure, if other agents can write good programs on top of it.
The benchmark spans two hundred and forty-two expert-validated programming problems, across fifteen library-design tasks, in four languages. Agent-written designs can be set beside the human-written production library for the same task.
On eleven of the fifteen tasks, agent designers reproduce the abstractions of the human-written production library. Downstream agents adopt agent-written and human-written libraries alike, but they underuse both, reimplementing capabilities the library already provides. The failure analysis locates the cause. Downstream agents write extra code mainly because agent-written libraries are rigid or hard to use, not because capabilities are missing.
The authors then try two changes on the design side: giving designers more prescriptive, agent-first guidance, and having them test their library with subagents. This improves downstream scores and yields simpler programs. Both changes point the designer at the same target: the agent who will have to use the library next.
An agent can get the abstractions right and still write a library its peers route around. That gap, between having a capability and making it usable, is what the benchmark is built to expose. The authors offer LibraryDesignBench as a testbed for library-design practice aimed at agent users, together with an initial design baseline that improves downstream reuse.
Paper Quest · 7 chapters · about 41 min
Play this paper
Learn it by doing: make the calls the authors made, guess the result before you see it, and defend it in a viva graded on your own words. Chapter 1 is right here.
Chapter 1 🧩 · The problem
Agents keep rewriting what already exists. The question is whether they can build something worth reusing.
Coding agents increasingly build on code other agents wrote, and they tend to reimplement rather than reuse, so codebases keep growing.
The road ahead
- 1 · The problem ~7 min Agents now build on each other's code, and, to the authors' knowledge, no benchmark yet judges whether a library helps the agents that use it.
- 2 · What came before ~3 min
- 3 · The key idea ~9 min Judge a library only by how well other agents program with it: a designer builds it from an open specification, then user agents' programs are scored.
- 4 · Choose your own research ~3 min
- 5 · Build the method ~8 min Write an open specification, let a designer agent build the library, let user agents program with it, then score their programs.
- 6 · The experiment ~6 min You’ll guess: Downstream agents underuse libraries written by agents and write extra code. What is the main reason?
- 7 · The viva ~5 min Three questions from the examiners, answered in your own words. Win it for the paper’s trophy.
Free, with Google or an email address. Your stars and progress are kept.