Skip to content
The AI-First Web

Researchers say AI agents improved on benchmarks by turning papers into code

A UCSB and Microsoft preprint moves the upgrade from the model to the software around it

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Researchers say AI agents improved on benchmarks by turning papers into code
In brief
  • UCSB and Microsoft researchers report that ScholarEvolve raised agent benchmark scores by rewriting the agent's software using research papers, while the language model stayed unchanged.
  • If the approach holds up, agent quality could depend on code that changes continuously, which makes change control a management question as well as a technical one.
  • Ask who reviews harness changes, what sources feed them, and how they are tested on your own tasks.

The upgrade that does not touch the model

Many buyers may think of an AI agent's quality as something they purchase. Pick a stronger model, pay more, get better results. In a preprint posted on 30 September 2026, researchers from the University of California, Santa Barbara and Microsoft describe a different route. They improved agents by changing the software around the model and left the model itself alone.

The idea is that an agent's performance depends on more than the language model inside it. The software that surrounds the model matters too. The authors call it the harness. It governs tool use, memory management and how tasks are carried out.

What ScholarEvolve does

The framework is called ScholarEvolve. Earlier methods let a coding agent rewrite the harness after watching the agent fail. The authors argue that this has two limits. The coding agent can only draw on what it already knows, and it can only learn from failures that have already happened.

ScholarEvolve adds the research literature. VentureBeat's account of the paper describes the steps. The system studies failures on a training set, searches papers for techniques that address them, builds those techniques into the harness, and tests how they work together.

The authors group possible improvements by function. Within each group, they use topic modeling, software that clusters documents by theme, to pick out separate approaches worth trying. The paper also says the framework is designed to take in new publications over time.

According to VentureBeat, the harness is divided into five parts: the tool interface, context management, skills, memories and agentic workflows. Each part has strict input and output rules. They are designed to keep a change in one part from breaking another.

What the numbers show, and what they do not

The authors report gains on two benchmarks. On AppWorld Challenge, Qwen3.5-27B task goal completion rose from 49.6% to 63.6%. On Tau2-Bench Telecom, GPT-5.4-mini pass@1 rose from 72.7% to 81.9%. Pass@1 means the share of tasks solved on the first attempt.

VentureBeat adds a third result. On the AppWorld Normal test set, Qwen3.5-27B went from 69.0% to 81.4%. On that measure, VentureBeat says, the open-weight model made up about 74% of its distance from GPT-5.4, with no change to its weights.

These are the researchers' own tests on public benchmarks. The paper is a preprint. The coverage we reviewed does not show how the system performs on an enterprise's private tools and data.

Why an agent's own instincts fall short

One example in the study shows the problem with the older approach. A coding agent saw repeated errors in search and Python tool calls. It added a reviewer module to verify every action. The check did stop bad calls. But it grew too cautious and also refused legitimate API calls that the task required.

The researchers also describe the cost of learning only from failures. They write that a weakness "may consequently affect users before sufficient evidence accumulates to motivate a useful update." In plain terms, the customer finds the flaw before the system does.

The idea: the agent is now a system that changes

Here is the lesson. If agent quality can be raised by editing the harness, the harness is a living part of the product. It could change on a schedule set by the research literature, not only by a model vendor's release calendar.

Medicine offers a rough parallel. A hospital that updates its protocols only after its own adverse events learns slowly and at patients' expense. One that reads the journals can improve before it is hurt. But it needs a way to check which findings apply to its patients.

That is the management question here. A paper becomes code, and code becomes behavior in front of customers. The system tests combinations of techniques on benchmarks. The coverage we reviewed does not describe human sign-off or production controls. A buyer should ask about both.

Questions to put to your team

Which parts of our agents can change without a new model, and who approves each change? Where does an upgrade come from, and what checks it before it reaches production? How do we test that a new safeguard does not block legitimate work, as the study's reviewer module did?

Do we measure results on our own tasks, not only on public benchmarks like AppWorld and Tau2-Bench? Can we roll a change back quickly?

The next agent upgrade may arrive as a code change rather than a new model. It deserves the same review as any other code change.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: University of California, Santa Barbara and Microsoft researchers (arXiv preprint).

Share this insight