• Class
  Defines the agent itself, including the state it holds and the actions it can perform.
• Field
  Stores state or a connected object. In the example, order_db is a field.
• Method
  Defines an action the agent can perform, such as is_refund_eligible(), classify(), or triage().
• Docstring
  Describes what a method should do. NOOA exposes this description to the model as task guidance.
• Type annotation
  Defines the expected input and output types. The runtime validates returned values against that contract.

Methods with ordinary Python code run as normal deterministic software. A refund rule, for example, does not need to be left to an LLM. If a method body contains only '...', NOOA instead completes it through an LLM-driven loop. Different methods can use different strategies: in the paper’s example, classify() returns a result from a single model call, while triage() uses CodeAct to repeatedly write and execute Python.

The key idea is that deterministic logic and model judgment can live in the same class. Rules, calculations, parsing, and state transitions stay in Python; tasks that require semantic judgment, such as classification or synthesis, can be handled by the LLM.

Types also do more than shape outputs. If a software-fixing agent must return a root cause, supporting evidence, and a verification command, the task does not finish until those required fields are present and valid. In that sense, types become part of the completion contract. They define what the agent must submit before the runtime accepts the task as done. They do not, however, guarantee that the content itself is correct. 🙊

With CodeAct, the model works inside a Python execution environment rather than only exchanging messages.

Method arguments become Python variables. The model can inspect them, transform them, access state through self, call other methods, and continue based on execution results or errors.

This also changes how tool use works. Instead of generating one tool call for every file, for example, the model can write a loop and let Python handle the repetition. The model decides how to approach the task; Python handles operations that are better expressed as deterministic code.

NOOA also avoids placing every large object directly into the prompt. Data and intermediate results can remain as live Python values, while the model sees bounded previews and refers to the underlying objects when needed.

The paper calls this pass-by-reference over live objects. Rather than serializing the same data into text again and again, the model can work with objects already available in the execution environment, reducing context pressure and repeated token use.

The researchers evaluated NOOA on four kinds of tasks: software engineering, terminal interaction, vulnerability discovery, and interactive reasoning.

One of the main benchmarks is SWE-bench Verified, which is built from real issues in open-source GitHub repositories. An agent must inspect an unfamiliar codebase, identify the problem, modify the repository, and produce a patch that passes the benchmark tests.

With GPT-5.5 at the highest reasoning setting, NOOA reached an 82.2% pass rate. Under the same setting, the open general-purpose harnesses OpenCode and PI scored 78.6% and 78.2%.

This does not make NOOA the overall state of the art. The paper also reports 88.7% for Codex and 80.8% for Claude Code, both specialized closed systems. The authors instead frame the result as evidence that a small, benchmark-agnostic agent can approach the performance of specialized systems.

NOOA was also more efficient in this comparison. Per task, it used about 28 model calls and 1.1 million tokens. OpenCode used a similar number of calls and about 1.3 million tokens, while PI used 66 calls and 2.2 million tokens.

The researchers attribute part of that efficiency to keeping intermediate results available as live Python values instead of repeatedly serializing them through the transcript. 

None of NOOA’s individual ingredients is entirely new. Typed I/O, object state, code execution, and pass-by-reference all appear in existing systems. What is distinctive is the way NOOA brings them together so that the software structure developers work with is also the structure the model operates through. 🧩

In many frameworks, developers configure graphs, state stores, and tool runners, while the model mainly sees messages and tool schemas. In NOOA, the model itself works with classes, methods, types, variables, and execution results. After comparing 14 agent frameworks and harnesses, the researchers say NOOA is, to their knowledge, the first to expose all six of its model-facing capabilities on a single interface.

Still, the benchmark gains should not be attributed to object-oriented design alone. NOOA combines typed validation, code execution, live-object references, context management, validated termination, and other design choices.

The paper isolates one component more directly: memory. On ARC-AGI-3, replacing NOOA’s memory subsystem with plain Markdown files lowered the score by 11.8 points. The contribution of components such as typed validation or pass-by-reference was not isolated in the same way.

There are practical limitations as well. Running model-generated code safely requires strong isolation, and the benchmarks are all interactive, multi-step agent tasks. Whether the same advantages carry over to workflows such as document production or customer support, where code execution may play a smaller role, remains an open question. 🧐

NOOA ultimately asks us to think of an agent as more than a specialized chatbot. It treats the agent as a software system with state, contracts, and an execution environment.

That matters because agent performance is not determined by model intelligence alone. Where state lives, what working environment the model sees, and how task completion is validated can all affect the performance and cost of the same model.

The question NOOA raises is simple: choosing a stronger model matters, but so does choosing the structure in which that model works.

As agent systems mature, the next competitive edge may come not only from better models, but from better ways of designing the state, tools, execution environment, and validation around them.