NVIDIA-labs OO Agents: Native Python Object-Oriented Agents

Paul Furgale Severin Klingler James Nolan Matt Staats par Gaia Di Lorenzo Elisa Martinez Abad Christian Schüller Razvan Dinu par Alessio Devoto Pascal Berard Gal Kaplun Elad Sarafian par Riccardo Roveri Leon Derczynski Ricardo Silveira Cabral par GitHub nvidia-nemo/labs-OO-Agents

Abstract

Traditional agent development is split across prompt templates, tool schemas, callback code, and workflow graphs. We present NVIDIA Object-Oriented Agents ($\textsc{NOOA}$ or NVIDIA double-O Agents), a model-agnostic Python framework for building reliable AI agents. $\textsc{NOOA}$ takes a simpler approach: an agent is a Python object. Its methods are the actions the model can take, fields are its state, docstrings are its prompts, and its type annotations are contracts. A method with code body consisting of in linecode... is completed at runtime by an LLM-driven agent loop, while methods with normal bodies remain standard deterministic Python. This gives developers and agents the same interface, so agent behavior can be tested, traced, refactored, and improved just like other software. This paper makes three contributions. (1) We present the agent-as-a-Python-object programming model and the design principles behind it. Where Python has existing abstractions, we adopt them directly: agents are classes, capabilities are methods, type annotations are contracts, asynchronous work is in linecodeasyncio, and tools and orchestration are normal Python code. Agent-specific capabilities -- context, events, state rendering, long-term memory, and validated LLM loops -- are exposed through simple Pythonic APIs, so both developers and agents share one familiar programming model. (2) We identify six model-facing ideas that $\textsc{NOOA}$ is, to our knowledge, the first to combine on a single surface: typed input/output, pass-by-reference over live objects, code as action, programmable loop engineering, explicit object state, and model-callable harness APIs for context and events. Surveying fourteen agent frameworks and harnesses, we find the community already converging on several of these ideas -- often as experimental or partial features -- and we present the comparison to encourage further adoption. (3) We demonstrate that current models use this interface effectively, both in targeted capability tests and on SWE-bench Verified and Terminal-Bench 2.0; on the ARC-AGI-3 interactive-reasoning benchmark, the interface compresses a multi-agent world-model system into a single agent with a one-page skill while advancing the benchmark's score--cost Pareto frontier.

Executive Summary: NVIDIA Object-Oriented Agents (NOOA) addresses a growing problem in AI agent development. Current toolkits split agent logic across prompt templates, tool schemas, callback code, and workflow graphs, forcing developers to learn new abstractions that models also struggle to use reliably. This fragmentation raises costs, limits testing and reuse, and slows progress on practical agent systems.

The paper introduces NOOA as a model-agnostic Python framework that treats an agent as a single Python object. Methods define actions the model can invoke, docstrings serve as prompts, type annotations act as contracts, and ordinary Python code handles deterministic work. Ellipsis-bodied methods trigger LLM-driven loops at runtime while preserving standard Python interfaces for everything else. The framework was evaluated through capability tests on ten models, end-to-end runs on SWE-bench Verified, Terminal-Bench 2.0, CyberGym L1, and ARC-AGI-3, and a structured comparison against fourteen other agent systems.

Key results show current models already understand and use the interface effectively, passing 97.9 percent of targeted capability tests. On SWE-bench Verified, NOOA reached 82.2 percent with GPT-5.5 and 79.8 percent with Claude Opus 4.6, outperforming comparable open harnesses while using fewer tokens. On Terminal-Bench 2.0 it led or matched the field in most configurations. On ARC-AGI-3, a single NOOA agent with a 50-line skill and the framework’s memory system advanced the score-cost frontier, achieving 85.1 percent at low per-game cost and outperforming a multi-agent baseline. No other evaluated system combines all six core capabilities NOOA exposes: typed input/output, pass-by-reference over live objects, code as action, programmable loop engineering, explicit object state, and model-callable harness APIs.

These outcomes matter because they return agent development to familiar software-engineering practices. Developers and models share one interface, enabling standard testing, tracing, refactoring, and optimization. Reduced context usage and validated termination improve reliability and lower token costs, while the design narrows the performance gap between open frameworks and specialized closed systems.

For next steps, organizations should evaluate NOOA on internal workflows that involve code modification, terminal interaction, or long-running reasoning tasks. Further work should target automated agent rewriting, richer long-term memory, and reinforcement learning over complete trajectories to strengthen disciplined multi-step behavior. Sandboxing around the agent process remains essential for security. Results rest on specific benchmark tasks and current-generation models; broader deployment will require additional validation on proprietary data and production constraints.

1. Introduction

Section Summary: Many existing AI agent toolkits scatter code across prompts, configuration files, and custom orchestration logic, forcing developers to learn new programming models even for tasks that standard Python already handles well. NVIDIA Object-Oriented Agents (NOOA) instead follows the PyTorch approach of offering a simple, familiar Python interface, where a complete agent lives in a single class whose ordinary methods supply state and tools while special “agentic” methods marked by an ellipsis are executed as LLM-driven loops. This design makes agents both easier for humans to build and test and more immediately usable by coding models, with the rest of the paper detailing its principles, implementation, and evaluation.

With the increasing interest in AI agents, there has been a proliferation of agent development kits, each with its own developer-facing and model-facing abstractions [1, 2, 3, 4, 5]. These systems expose useful primitives – tools, memory, workflows, handoffs, traces, and code execution – but they often split agent source code across prompt templates, schemas, callbacks, configuration files, and orchestration code. Consequently, learning a new agent framework often means learning a new programming model for capabilities that already have mature equivalents in ordinary programming languages: typed interfaces, variable scoping, control flow, asynchronous execution, and object state. These abstractions are not only familiar to developers, but also broadly represented in model training data.

NVIDIA Object-Oriented Agents ($\textsc{NOOA}$) is inspired by PyTorch [6], which showed that a powerful runtime can still present users with a simple Python programming model. $\textsc{NOOA}$ applies the same concept to agents: where Python already has the right abstraction, $\textsc{NOOA}$ uses it. Agent actions, helper logic, and harness extension points are ordinary Python programs, familiar to developers, close to the distribution of code that LLMs were trained on, and thus directly understandable by coding agents. Where agent-specific concepts do not already have a standard Python form – for example context construction, event history, and model-visible state – $\textsc{NOOA}$ exposes them as simple Pythonic APIs. This design provides a dual benefit: it eliminates the learning curve for humans and ensures immediate agent readiness.

A complete agent is a single Python class, as shown in the support-agent example below. The class combines object state, deterministic code and two agentic methods: a single-shot in linecodePredict method and an iterative in linecodeCodeAct method.

The class is simultaneously source code, prompt surface, type contract, tool interface, and state boundary. A method with code executes as ordinary Python; a method whose body contains an ellipsis ( in linecode...) becomes an agentic method, so the harness runs it as an LLM-driven loop.

The method declaration specifies the loop: the signature gives the model structured inputs and an output-validation contract, the docstring becomes the prompt, and methods on in linecodeself and imported libraries become callable tools. Note that inputs are not limited to text, as in linecodetriage receives an image and a live in linecodeOrder object, passed by reference rather than serialized into the prompt. This brings prompt engineering back into software engineering, so behavior can be tested, traced, refactored, versioned, and optimized.

The rest of the paper develops this design. Section 2 presents the design principles. Section 3 shows how they are realized in the programming model and harness. Section 4 tests whether current models can use this interface, with capability tests and results on SWE-bench Verified, Terminal-Bench 2.0, and ARC-AGI-3. Section 5 compares fourteen other frameworks and harnesses against the six interface capabilities. Section 6 situates the capabilities in the broader literature and Section 7 discusses limitations and future work.

2. Design Principles

Section Summary: The design of NOOA rests on five core principles that shape how agents are built and run. It reuses familiar Python constructs such as classes, methods, type hints, and asyncio so that developers and models work with ordinary code rather than new languages or tool formats. Agent loops are presented as regular typed method calls, deterministic logic stays in standard Python functions, models act directly by writing code they already understand, and internal harness features like context management are made available through explicit, easy-to-use APIs.

Five principles guided the design. Each principle materializes as one or more interface capabilities implemented by $\textsc{NOOA}$. In the following, we mark each design principle with a square (), and use a callout to name the corresponding

. The principles state the design commitments behind $\textsc{NOOA}$, the capabilities name the concrete model-facing features reused throughout the implementation.

P1. Reuse Python abstractions

If a mature Python abstraction already exists, adopt it rather than introducing a domain-specific language (DSL). In $\textsc{NOOA}$, classes define agents, methods define capabilities, fields hold explicit, model-visible durable state, type annotations define contracts, asyncio expresses concurrency, exceptions signal failures, and control flow is ordinary Python available to developers and agents alike.

$\textsc{Loop engineering.}$ Control flow for single and multi-agent orchestration is ordinary Python.

$\textsc{Object state.}$ Durable state is stored on the agent object, rather than only in conversation history.

P2. Reframe agentic loops as method calls

The application sees an agentic loop as a normal Python method call with typed input/output, not an unstructured text exchange. Arguments are passed by reference as live Python objects, while the harness renders bounded previews and context to the agent, injects arguments and object state into the loop, and validates return values before returning to the caller.

$\textsc{Typed I/O.}$ Agentic methods have typed inputs and typed return values.

$\textsc{Pass by reference.}$ The model operates on live Python objects by reference.

P3. Move deterministic work out of the agentic loop

LLMs are useful for semantic judgment, synthesis, and open-ended tasks. Exact rules, arithmetic, parsing, and state transitions belong in deterministic methods. The boundary is local and visible in the code: a real method body for deterministic work, an ellipsis ( in linecode...) body for agentic loops.

P4. Unlock the model's existing Python knowledge

LLMs already know how to write Python and use popular Python libraries. By letting models write normal Python code instead of tool calls, $\textsc{NOOA}$ draws on that knowledge. CodeAct code can use ordinary loops and conditionals, in linecodeasyncio for concurrency, database clients for queries, plotting libraries for visualization, and ordinary imports for extension – without bespoke prompting, reading documentation, or learning a new DSL. This makes $\textsc{NOOA}$ exceptionally easy to use while maximizing agent readiness, ensuring that the library is as intuitive for autonomous coding agents to build with as it is for human developers.

$\textsc{Code as action.}$ The model acts by writing Python code, control flow and method calls directly.

P5. Expose the harness as explicit APIs

Agent-specific concepts – structured context, context rendering, and event history – are exposed as Python APIs to developers and the model. Where possible, the interfaces mirror built-in types or existing libraries so they are familiar and obvious. The Agent has access to its own context and is able to manage it via Pythonic primitives.

$\textsc{Harness APIs.}$ Harness and Context are exposed through explicit APIs both to the user and to the agent.

3. Agent Loop

Section Summary: A NOOA agent is a Python object mixing ordinary methods with special "agentic" ones whose ellipsis bodies trigger LLM loops instead of normal execution. The harness implements these loops through strategies that render static and dynamic context plus an event history, call the model, execute any resulting Python actions in a REPL, record outcomes, and validate returned values against the method's type signature before handing control back. This keeps overall program flow as standard Python while letting the model iteratively work with the agent's own state and methods until a valid result is produced.

A $\textsc{NOOA}$ agent is a Python object that exposes model-callable behavior through typed methods, fields, and docstrings. Developers write and use this object as ordinary Python code. At runtime, the harness executes regular methods directly and implements ellipsis-body methods as LLM loops. This section unrolls that loop: context rendering, pass by reference, Python execution, event and state recording, and return validation.

3.1 Agents and Strategies

An agent may contain both ordinary Python methods and agentic methods – methods whose body contains the ellipsis literal, in linecode.... Control flow remains ordinary Python until execution reaches an agentic method; at that point, the harness implements the method as an agent loop. The docstring and method arguments become the prompt for the current task, the type signature defines the input and output contract, and the model may use the methods and state on in linecodeself before returning the result. The support-agent example in Section 1 shows both kinds of method in one class.

Strategies

$\textsc{NOOA}$ implements agentic methods through strategies. A strategy is declared as a decorator: it preserves the method's ordinary Python signature and typed boundary, but controls its agentic execution – what context is rendered, how turns are executed, and how candidate outputs are validated. Strategies are per-method, and they are an extension point: new strategies can be added as the field progresses. The decorator also takes per-method overrides – model, truncation, and scoped context – so, for example, a small fast model can serve a classification method while the agent's default model serves open-ended ones. Within a single agent, externally initiated calls to agentic methods are serialized, so independent invocations do not interleave their turns. Nested same-agent calls follow stack discipline: the caller is suspended until the callee returns, and both executions append to the same event history. Other methods, and other agents, run in parallel under Python's standard async/await concurrency model. $\textsc{NOOA}$ provides two built-in strategies:

1. in linecode**PredictStrategy** is a single-shot strategy for classification or extraction: it renders the context, asks the model for a value, then validates the output against the Python return type, running a local retry loop if the output fails validation.
2. in linecode**CodeActStrategy** generalizes the same contract into an iterative Python Read-Eval-Print Loop (REPL). The model may call in linecodeexecute_python(...) to compute, inspect internal agent state, call helpers, or invoke other generation methods; the harness records the observation, re-renders the updated state, and repeats until the model calls in linecodereturn_result(...) with a value that is type validated.

The same agent can mix both strategies, choosing per method whichever execution mode fits the task: in the support-agent example, in linecodeclassify_ticket uses Predict and in linecodetriage uses the default CodeAct.

Figure 2 shows the agent loop for the CodeAct strategy. The rest of this section follows the loop: the harness first renders context from the method call (Section 3.2); it then calls the LLM (Section 3.3); if the model chooses a code action, the harness executes Python in the method's REPL session (Section 3.4); finally, it updates events and state with the code output, errors, return values, and locals before the next turn is rendered (Section 3.5). When the model submits a result, the harness validates it against the return type (Section 3.6); failures return an error message to the model, and success returns control to the caller.

3.2 Context

The first step in a CodeAct turn is to render the live Python execution state into model context. $\textsc{NOOA}$ separates context into three regions (see Figure 3): static context blocks, which are computed once and reused across turns; event history, which records the execution trace accumulated so far; and dynamic context blocks, which are re-evaluated before each model call.

Static and Dynamic Blocks

These are developer-controlled, named, structured pieces of text rendered into the model's context window. Static blocks hold information that stays stable across the call, such as the system prompt. Dynamic blocks hold information whose value changes as the program runs, such as a TODO list or selected relevant fields on in linecodeself.

Event History

This is an append-only sequence of typed events produced by the harness as execution proceeds: model tool calls, Python outputs, and return values. Each event is a typed Python object with a unique tag, so agent code can query prior events rather than scanning a flat transcript. Long histories can be collapsed into summary events, akin to MemGPT's context management [7]; strategies can restrict which events are visible to a nested call, and the full event history remains searchable after summarization. Together, blocks and events form the model context of an agentic method.

Context management is therefore not an external prompt-building script; it is part of the same object-oriented API used by the agent. Both the developer and the agent can interact with the context through Pythonic APIs, as shown in Figure 4.

$\textsc{NOOA}$ starts with defaults that make simple agents work well, while still allowing developers to dynamically override every context block at any time. The default static prefix contains a small $\textsc{NOOA}$ system prompt (about 1k characters), the active strategy instructions (about 2.5k characters for CodeAct), an execution-context block showing imported types and libraries, and a concise in linecodedoc(self) rendering of the agent API. The dynamic suffix contains compact views of live agent state ( in linecodepprint(self)). The helper in linecodedoc() provides documentation for types, while in linecodepprint() formats values and instances. Unless scoped by a strategy or method, the event-history block renders the visible execution events accumulated so far.

Rendering context

These three sources are maintained by two programmable objects, shown in Figure 3: the in linecodeContextManager, which stores static and dynamic context blocks, and the in linecodeEventManager, which stores the event history as an ordered log of typed events. The renderer maps these sources into LLM API messages (e.g., OpenAI chat messages). Static framework blocks, such as in linecode<system_prompt> and in linecode<self> (the agent's own in linecodedoc() rendering), are concatenated into a cacheable system prefix visible at every turn. The event history becomes the interleaved user, assistant, and tool messages that record execution: system-generated task messages, agent in linecodetool_call s, and Python output. Dynamic blocks are re-rendered every turn into a trailing user in linecode<context> message. Each dynamic block shows its expression to the model (e.g., in linecodeexpr="self.todo.status()"), reinforcing that this is live state. This three-region layout is designed to maximize KV-cache reuse across turns: the static prefix remains unchanged, the event history grows only by appending new messages, and volatile dynamic blocks are placed at the tail. As a result, updates to live state do not invalidate the cached prefix, and each turn can reuse most of the previous computation.

By default, context blocks and events are wrapped in XML-like tags and events are rendered as typed Python in linecodereprs, as shown at the bottom of Figure 3. Media arguments -- images, audio, video, and files -- are rendered as native multimodal content blocks rather than text, which is how in linecodetriage in the intro example receives its in linecodephoto. The renderer is an extension point: developers have full control over what goes in the context and how it is rendered.

Pass by Reference

Rendering context does not mean serializing the whole program state into the prompt. A CodeAct method receives its arguments as live Python objects, and for large arguments the model never sees the full value. In the spirit of progressive disclosure [8], the model sees each argument's variable name paired with a bounded preview: the concrete type, the true length, and a short head/tail sample. The model reads that shape, understands that the name refers to a real object, and operates on it directly in generated code.

For example, a method called with a list of one hundred integers renders in the prompt as a single compact preview:

records = list(len=100, [:5]=[42, 17, 89, 33, 8], [-5:]=[56, 71, 12, 45, 28])

The preview states the concrete type ( in linecodelist), the true length ( in linecodelen=100), and a head/tail sample; the elided middle is implied. The variable in linecoderecords itself is not truncated -- it is the full hundred-element list bound as a local in the execution environment -- so the model can index, slice, or iterate over all of it ( in linecodefor r in records: ...) even though only ten elements ever appear in the context window.

This is what lets the object model scale past the context window: the amount of data an agent can process is bounded by the execution environment, not by the prompt. A method can accept a multi-million-row table or a multi-megabyte string and the agent works on the whole thing by writing code, while the prompt carries only a fixed-size preview.

Python has no standard library for truncating arbitrary values. The closest is Rich's in linecodepprint() [9], so we borrowed its name and API surface – both are in the model's training data – but changed the output format based on experimentation across open and closed models. Finding even better formats that are obvious to LLMs, and supporting more types, remains open work.

Methods using the Predict strategy render argument values in full, guarded by a size cap: a Predict call is a single LLM call, so the model has no opportunity to inspect a variable.

3.3 Calling the LLM

Once the harness has rendered the current turn, control passes from Python to the model. The LLM receives the structured context assembled in the previous step, together with the strategy-specific contract for what it may do next. Under in linecodePredictStrategy, the model must produce a value matching the return annotation. Under in linecodeCodeActStrategy, the model must choose between continuing computation with in linecodeexecute_python(...) or terminating the method with in linecodereturn_result(...).

3.4 Executing Python

When a CodeAct model chooses a Python action, $\textsc{NOOA}$ executes the cell in a restricted, Jupyter-like session. Method arguments, the live agent as in linecodeself, and the agent's environment (imports, methods, and constants defined in the agent's source file) are injected as locals; in linecodeawait can be used directly. The cell can inspect objects with in linecodedoc(obj), print bounded previews with in linecodepprint(), call deterministic helpers, await generation methods, spawn subagents, or return an in-process Python value with in linecodereturn_result(...).

This is the second half of pass by reference mentioned in Section 3.2: the model writes code against real objects rather than serialized tool arguments. All tool calls are strongly typed and pass by reference in both directions, so the agent can call a method with a huge input, bind the huge typed result to a variable, and process it programmatically – slice it, aggregate it, feed it to the next call – while only the bounded previews it chooses to print enter the context window. Models already improvise this pattern in bash – spilling results to files and processing them with follow-up commands; $\textsc{NOOA}$ replaces the untyped text on disk with typed, live variables that persist from cell to cell.

Dangerous or loop-breaking APIs such as in linecodeeval, in linecodeexec, in linecodecompile, in linecodeinput, and blocking event-loop calls are rejected with specific errors. Stdout, stderr, images, returned values, locals, and exceptions are captured as structured results. Syntax errors and tracebacks are in IPython format, including source locations and caret/source-line context, so the next LLM turn can repair the code the way a human would repair a notebook cell.

Cells can contain loops, conditionals, library calls, async operations, helper calls, and subagent invocations. This gives the model the same orchestration tools as the developer: inside a cell, it can define a new in linecode@strategy-decorated function with an ellipsis body and fan it out over a batch with in linecodeasyncio.gather, creating parallel subagent calls in ordinary Python.

3.5 Updating Events and State

After every model response or Python execution, the harness appends typed events to the event manager: tool calls, Python outputs, and final return values.

State updates follow standard Python scoping rules. REPL locals are method-scoped – they persist across cells within a single CodeAct call and then disappear when the method returns – so intermediate values stay local to the task. Anything reached through in linecodeself or through library calls, by contrast, can have side effects that outlive the method, exactly as they would in an ordinary Python program.

3.6 Validating the Return

When the model returns a result, the harness validates it against the return annotation. If the result is invalid, the harness sends the model an error message describing the failure, and the loop continues. If the result is valid, the harness returns it to the caller and normal Python execution resumes.

3.7 Long-Term Memory: the Agent Curates Its Own State

The mechanisms described so far are scoped to a method call or a session, yet an agent with frozen weights can only improve through the state it retains. Our companion work on workspace optimization [10] shows that agents can learn by writing typed, evidence-gated artifacts in place of parameter updates; its principal open problem is transfer, because the workspace is discarded at every task boundary. $\textsc{NOOA}$ addresses transfer with an optional long-term memory subsystem: in linecodeMemoryManager.install(agent) attaches it to an unmodified agent, and uninstalling restores the agent exactly.

The agent authors its own memory

Following Principle 5, writing a memory is a deliberate action of the model rather than the output of a background extraction pipeline. Seven model-callable tools ( in linecoderemember, in linecoderecall, in linecodesearch, in linecodeupdate_memory, in linecodeforget, in linecodeassociate, in linecodederef) operate on the store; they accept ordered verbal descriptors ($\textsc{critical} \ldots \textsc{trivial}$) that map to numeric scores internally, and a standing context block states that the store is the agent's own to maintain.

Deliberate and spontaneous recall

Memory reaches the model through two channels: the agent queries the store with its tools, and a in linecodeBeforeTurn hook derives a query from recent events and injects associated memories into a dynamic context block. Injected memories are not reinforced, so what the harness surfaces does not distort the usage signal. Retrieval unions embedding and keyword candidates, ranks them by ACT-R activation [11] – relevance, recency, and importance, the triad of generative agents [12] – and propagates activation over a typed memory graph. Decay-based forgetting keeps the store bounded.

Asynchronous reflection

Consolidation runs outside the agent loop, after a task completes or while the agent is idle, as an ordered pass: near-duplicate memories are merged; conflicting values can be reconciled into a single current record, archiving the superseded ones; related memories are linked; importance is re-scored; episodes can be distilled into higher-level records; and memories whose activation has decayed are pruned. Pruning never removes recent memories, protected types, or open todos.

One inspectable file; live references

The entire store is one SQLite file that can be inspected directly; vector indexes are derived from it and interchangeable. A memory may hold typed references ( in linecodekind:key) that are resolved against live agent state at recall time – extending pass by reference into persistence, so recall does not answer from stale copies – and owner scoping governs reads and writes when several agents share one store. The subsystem's end-to-end effect is measured in Section 4.5: +11.8 RHAE points over the identical agent with file-based notes in place of memory. Figure 5 shows the architecture; Appendix C details the design and compares memory support across contemporary harnesses.

4. Evaluation

Section Summary: The evaluation of NOOA proceeds at two levels. Targeted tests first check whether current AI models can correctly interpret and use the system's interface features, such as calling methods, handling state, and returning properly typed results; across 4,400 runs on ten models, the tests passed at a 97.9% rate, with larger models performing especially well. The authors then assess complete NOOA agents end-to-end on established benchmarks covering software engineering, terminal use, cybersecurity, and interactive reasoning to measure real-world effectiveness.

We evaluate $\textsc{NOOA}$ at two levels. First, in Section 4.1, we use targeted capability tests to determine whether current models understand and correctly use the abstractions exposed by the $\textsc{NOOA}$ interface. Second, we evaluate complete $\textsc{NOOA}$ agents end-to-end on benchmarks spanning software engineering and terminal interaction (Section 4.3), cybersecurity (Section 4.4), and interactive reasoning (Section 4.5).

4.1 Capability Tests: Do Models Understand the NOOA Interface?

Experimental setup

We built a suite of focused integration tests that isolate one interface behavior at a time. The question is not only whether a model can solve a task, but whether it can call helper methods, write executable cells, interpret bounded variable previews, manage state, and return typed values through the harness. The suite contains 88 test instances across 36 families, covering typed method calls, structured returns, stateful object manipulation, routing to helper agents, context and truncation handling, REPL and code execution, batching through generated loops, error recovery, and task decomposition.

Most tests are short interactions of one to five turns. The harder cases stress bookkeeping over batches, recovery after errors, multi-step REPL exploration, and the implementation of reusable helper methods. The complete suite is included in the $\textsc{NOOA}$ repository. We run each test five times for each of ten models, yielding 4, 400 records in total.

Models understand the interface

Table 1 shows that current generation models are generally fluent in the $\textsc{NOOA}$ interface; the suite passes 4, 309 of 4, 400 records (97.9%). We group models by scale: four small/efficient models (Claude Haiku 4.5, Gemini 3.5 Flash, Nemotron 3 Nano 30B, GPT-5.4 Mini) and six large/frontier models (Claude Opus 4.8, Gemini 3.1 Pro, GLM-5.2, Kimi K2.6, Nemotron 3 Ultra, GPT-5.5). Small/efficient models pass 96.0% of records; large/frontier models pass 99.2%. Every model exceeds 91%, and six of ten models exceed 98%. GPT-5.5 is perfect on this suite, while Gemini 3.5 Flash and GLM-5.2 miss only one test each. Capability-suite pass rates discriminated by the use of reasoning show frontier models saturating regardless of mode (Opus 100.0/99.5, GPT-5.5 99.5/98.6, off/on), while the value of reasoning grows monotonically as model capability falls — Ultra 93.4 → 94.1, Super-v3 83.7 → 96.4, Nano 52.5 → 84.8 — making inference-time reasoning a capability equalizer for the smaller Nemotron models.

\begin{tabular}{lrr}
\toprule
\textbf{Model} & \textbf{Passed} & \textbf{Pass rate} \\
\midrule
Claude Haiku 4.5 & 430/440 & 97.7\% \\
Claude Opus 4.8 & 438/440 & 99.5\% \\
Gemini 3.5 Flash & 439/440 & 99.8\% \\
Gemini 3.1 Pro (preview) & 438/440 & 99.5\% \\
GLM-5.2 & 439/440 & 99.8\% \\
Kimi K2.6 & 431/440 & 98.0\% \\
Nemotron 3 Nano 30B & 403/440 & 91.6\% \\
Nemotron 3 Ultra & 434/440 & 98.6\% \\
GPT-5.4 Mini & 417/440 & 94.8\% \\
GPT-5.5 & 440/440 & 100.0\% \\
\midrule
\textbf{Overall} & \textbf{4309/4400} & \textbf{97.9\%} \\
\bottomrule
\end{tabular}

The important implication is that the interface itself is not a burden for current generation LLMs. Models know Python; they can read object documentation, call methods with typed arguments, use returned values, mutate object state, and return values that satisfy the type contract. This zero-shot fluency validates the framework's empirical agent readiness: by expressing agentic constructs as native software abstractions, we completely remove the interface friction introduced by other frameworks.

Stress tests expose the remaining frontier

The residual failures are concentrated in six stress families, shown in Table 2. These are the tests that most resemble agentic work rather than single tool calls: preserving per-item bookkeeping in a large batch, recovering from errors, iterating in a REPL, refining an intermediate answer, and decomposing repeated transformations into helpers. The stress subset passes 254 of 300 records (84.7%), compared with 97.9% overall. Large/frontier models pass 169 of 180 stress records (93.9%), while small/efficient models pass 85 of 120 (70.8%) – the scale gap widens from 3.2 points overall to 23 points on the stress subset.

Running each test five times also measures consistency. Models are consistent: of the 880 (test, model) pairs, 94% pass all five runs, only three fail all five, and the rest are intermittent. The stress tests separate the two failure modes: large models have no 0/5 scores – every failure is intermittent, a reliability miss on a demonstrated capability. Small models show both, with 12.5% of stress pairs at 0/5 and 42% intermittent.

::: {caption="Table 2: Stress-test pass rates. Each row has 50 records (10 models × five runs), split into four small/efficient and six large/frontier models as defined in the text."}

:::

These are not failures to understand in linecodeself or to call a method; they are failures of disciplined multi-step harness use (Appendix B shows four complete runs of the hardest stress test). This distinction matters: basic interface fluency is already widespread, while reliable long-horizon batching, recovery, and decomposition at the code/model interface remain capability frontiers.

4.2 Experimental Results on Agentic Benchmarks

We evaluate $\textsc{NOOA}$ on four agent benchmarks covering complementary forms of end-to-end interaction. SWE-bench Verified [13] measures software-engineering performance on real repository issues, while Terminal-Bench 2.0 [14] evaluates multi-step interaction in a command-line environment. CyberGym L1 [15] tests an agent's ability to identify and repair software vulnerabilities, and ARC-AGI-3 [16] evaluates interactive reasoning in unfamiliar environments. Together, these benchmarks span code modification, terminal use, cybersecurity, and adaptive problem solving.

4.3 Software Engineering and Terminal Interaction

SWE-bench Verified [13] contains 500 software-engineering tasks derived from issues in real GitHub repositories. An agent must inspect an unfamiliar codebase, identify the cause of a reported problem, modify the repository, and produce a patch that passes the benchmark's tests. Terminal-Bench 2.0 [14] contains 89 tasks performed through a command-line environment, including software installation, configuration, debugging, and service operation.

Agent and comparison harnesses

For both benchmarks, we use the same benchmark-agnostic agent, in linecodeBenchAgent. The agent has a todo list, shell tools for command execution and file editing, and repository-navigation tools based on tree-sitter. Its dynamic context contains the task description, todo-list status, context-window statistics, and the current working state of its shell and repository tools. The agent terminates through a typed in linecodeTaskResult containing the identified root cause, supporting evidence, and a verification command. This return value is validated by the harness before execution ends. The complete agent consists of 253 lines of ordinary Python and is included in the $\textsc{NOOA}$ repository.

We compare $\textsc{NOOA}$ with two open, general-purpose coding agents. OpenCode [17] is a full-featured terminal coding agent with file, search, and shell tools, together with automatic transcript summarization. PI [18] is a deliberately minimal agent with a small prompt, standard file and shell tools. All three harnesses are evaluated with the same GPT-5.5 and Claude Opus 4.6 backends at the available reasoning-effort settings. We report task pass rate in Table 3 and Table 4, and per-task token usage in Figure 6.

Results

On SWE-bench Verified, $\textsc{NOOA}$ obtains the highest pass rate among the open harnesses in every evaluated model and reasoning configuration. Results show that NOOA improves on the original CodeAct paradigm as implemented by OpenHands v3 [19], which under Opus 4.6 is reported to have a 68.4% pass rate. $\textsc{NOOA}$ builds on this result by 11.4 points, given the same model. With GPT-5.5, it reaches 67.2%, 78.8%, and 82.2% at off, high, and xhigh reasoning effort, respectively. At xhigh effort, OpenCode reaches 78.6% and PI reaches 78.2%. With Opus 4.6, $\textsc{NOOA}$ reaches 79.8%, compared with 75.2% for OpenCode and 75.8% for PI.

The advantage is larger on Terminal-Bench 2.0. With GPT-5.5 and reasoning disabled, $\textsc{NOOA}$ reaches 46.1%, compared with 34.8% for OpenCode and 37.1% for PI. At high effort, it reaches 73.0%, ahead of OpenCode by 12.3 points and PI by 4.5 points. PI obtains the best GPT-5.5 xhigh result at 75.3%, compared with 73.0% for $\textsc{NOOA}$. With Opus 4.6 at high effort, $\textsc{NOOA}$ reaches 65.2%, while OpenCode and PI reach 43.8% and 58.4%, respectively.

The higher pass rates do not come from using longer trajectories. On SWE-bench with GPT-5.5 xhigh, $\textsc{NOOA}$ reaches 82.2% using approximately 28 model calls and 1.1 million tokens per task. OpenCode uses a similar number of calls but approximately 1.3 million tokens for 78.6%, while PI uses 66 calls and 2.2 million tokens for 78.2%. As shown in Figure 6, $\textsc{NOOA}$ therefore defines most of the observed accuracy–cost frontier.

Effect of reasoning effort.

Increasing reasoning effort improves all three harnesses, but the interface matters most when the model provides less planning and verification discipline of its own. With reasoning disabled, $\textsc{NOOA}$ leads OpenCode and PI by 8.0 and 6.4 points on SWE-bench, and by 11.3 and 9.0 points on Terminal-Bench. These margins narrow at higher effort, suggesting that the explicit object state, typed actions, and programmable loop behavior exposed by $\textsc{NOOA}$ partly substitute for behaviors that stronger reasoning models increasingly perform themselves.

Validated termination.

Trace analysis identifies termination as a key difference between the harnesses. OpenCode stops whenever the model responds without a tool call; on Terminal-Bench, 77% of its failed GPT-5.5 trials terminate within ten steps. In $\textsc{NOOA}$, the model must instead return a validated in linecodeTaskResult containing evidence and a verification command. This prevents unsupported declarations of completion and is especially valuable on tasks whose intermediate state can appear correct before hidden checks are run. More broadly, it illustrates the value of treating type annotations as executable contracts: termination becomes a programmatically validated action rather than an informal convention encoded only in the prompt.

Interaction and context efficiency.

$\textsc{NOOA}$ also uses fewer tokens because tool outputs remain available as live Python values rather than being repeatedly serialized through the transcript. With GPT-5.5 xhigh on SWE-bench, it reaches 82.2% using approximately 28 calls and 1.1M tokens per task, compared with 78.2% using 66 calls and 2.2M tokens for PI. Bounded prompt previews also keep $\textsc{NOOA}$ well below the context limit, avoiding the lossy transcript compaction used by OpenCode and PI while preserving prefix-cache reuse. These results directly expose the benefits of combining code as action with pass-by-reference: the model can operate on persistent objects in the execution environment instead of repeatedly exchanging their full textual representations with the harness.

Comparison with specialized systems.

The results also narrow the gap between open general-purpose harnesses and specialized closed systems. On SWE-bench Verified, $\textsc{NOOA}$ reaches 82.2% with GPT-5.5 and 79.8% with Opus 4.6, compared with 88.7% for Codex and 80.8% for Claude Code. On Terminal-Bench 2.0, its 65.2% with Opus 4.6 is comparable to the 62.9–65.4% reported for Claude Code and Terminus-2. Thus, a small benchmark-agnostic $\textsc{NOOA}$ agent is competitive with specialized systems while consistently outperforming the open general-purpose harnesses in our comparison. This supports the broader agent-as-a-Python-object claim: ordinary classes, methods, state, and type contracts provide a simple developer-facing abstraction without making the interface less effective for models.

\begin{tabular}{l ccc cc}
\toprule
 {} & \multicolumn{3}{c}{GPT-5.5} & \multicolumn{2}{c}{Opus 4.6} \\
\cmidrule(lr){2-4}\cmidrule(lr){5-6}
Harness & off & high & xhigh & off & high \\
\midrule
NOOA & \textbf{67.2} & \textbf{78.8} & \textbf{82.2} & \textbf{76.8} & \textbf{79.8} \\
OpenCode 1.14.33 & 59.2 & 75.0 & 78.6 & 76.0 & 75.2 \\
PI v0.72.1 & 60.8 & 73.6 & 78.2 & 75.6 & 75.8 \\
\bottomrule
\end{tabular}

\begin{tabular}{l ccc cc}
\toprule
 {} & \multicolumn{3}{c}{GPT-5.5} & \multicolumn{2}{c}{Opus 4.6} \\
\cmidrule(lr){2-4}\cmidrule(lr){5-6}
Harness & off & high & xhigh & off & high \\
\midrule
NOOA & \textbf{46.1} & \textbf{73.0} & 73.0 & 64.0 & \textbf{65.2} \\
OpenCode 1.14.33 & 34.8 & 60.7 & 52.8 & 49.4 & 43.8 \\
PI v0.72.1 & 37.1 & 68.5 & \textbf{75.3} & \textbf{65.2} & 58.4 \\
\bottomrule
\end{tabular}