NVIDIA-Labs OO Agents

Paul Furgale, Severin Klingler, James Nolan, Matt Staats, Gaia Di Lorenzo, Elisa Martinez Abad, Christian Schüller, Razvan Dinu, Alessio Devoto, Pascal Berard, Gal Kaplun, Elad Sarafian, Riccardo Roveri, Leon Derczynski, Ricardo Silveira Cabral

NVIDIA Object-Oriented Agents (NOOA) treats AI agents as standard Python objects, unifying developer and model interfaces.

How can we unify fragmented agent-development patterns (prompts, tools, callbacks) into a single, standard Python object interface?

Agent development is currently fragmented across disparate prompt templates, tool schemas, and custom workflow graphs. This forces developers to learn unique frameworks for capabilities that already have mature, standard equivalents in general-purpose programming. NOOA eliminates this overhead by defining an agent as a standard Python class: methods are actions, fields are state, and type annotations are contracts. The harness executes deterministic code directly and implements agentic methods as LLM-driven loops, allowing models to operate on live objects by reference rather than serialized text. On the SWE-bench Verified benchmark, this interface improves pass rates by 11.4 points over existing open-source agent harnesses while significantly reducing token usage.

Paper Primer

NOOA hinges on the "agent-as-an-object" principle: it maps agentic concepts to existing Python abstractions. Deterministic logic remains standard Python, while agentic loops are triggered by an ellipsis (...) body, allowing the model to write code that interacts with live objects in the execution environment.

NOOA achieves state-of-the-art performance among open-source agent harnesses on software engineering and terminal benchmarks.

On SWE-bench Verified, NOOA reaches an 82.2% pass rate with GPT-5.5 (xhigh effort), outperforming existing open-source frameworks like OpenCode and PI. +11.4 percentage point improvement over the previous CodeAct implementation.

The interface is highly intuitive for current-generation LLMs.

Across 4,400 capability test records, models achieved a 97.9% pass rate, demonstrating fluency in typed method calls, stateful object manipulation, and REPL-based code execution.

Why does this approach outperform existing frameworks that also use code-based actions?

NOOA uses "pass-by-reference" for live Python objects, allowing models to operate on large datasets via bounded previews rather than serializing full content into the prompt. This reduces token consumption and prevents the lossy transcript compaction common in other frameworks.

What is the scope of this framework — does it replace existing agent orchestration tools?

NOOA is a model-agnostic programming model rather than a replacement for orchestration logic; it adopts standard Python control flow (asyncio, loops, conditionals) to handle orchestration, meaning developers use the same language for both agent logic and system-level coordination.

By treating agents as standard Python objects, NOOA allows developers to test, trace, and refactor agent behavior using familiar software engineering tools, effectively collapsing the distinction between prompt engineering and application development.

Introduction to NOOA

We expose fragmented agent development and introduce the NOOA Python framework.

Current agent toolkits scatter functionality across prompt templates, tool schemas, callback code, and workflow graphs, forcing developers to learn multiple, incompatible abstractions.

We propose NOOA, a model‑agnostic Python framework that collapses this fragmentation: an agent is a plain Python object whose methods are actions, fields are state, docstrings are prompts, and type annotations are contracts.

NOOA turns an AI agent into an ordinary Python class, letting developers write, test, and refactor agent logic exactly like any other software component.

How does NOOA differ from existing agent frameworks that already let you write Python classes?

Existing frameworks typically require a separate prompt DSL or configuration files for actions, whereas NOOA embeds the prompt directly in the method’s docstring and treats the whole class as the agent’s source code. The model sees the same Python syntax it was trained on, and only methods marked with “…” become LLM‑driven; all other methods run deterministically.

The shift from fragmented agent code to standard Python objects simplifies development and makes agent behavior testable and refactorable.

Design Principles

NOOA’s design follows five concrete principles that turn agentic loops into ordinary Python method calls.

Five principles guided the design of NOOA, each materializing as a concrete interface capability that developers and agents can use directly.

Calling an agentic loop is just like invoking a regular Python function: you pass typed arguments, the function runs deterministic code, and you get a typed result back.

The model receives a request to compute the sum of two numbers and constructs the argument tuple

The harness validates that both arguments satisfy the

The deterministic Python body executes

The harness checks that the return value matches the declared

This shows that the LLM never performs the arithmetic itself; it merely orchestrates a typed function call, guaranteeing exact numeric results.

How does this differ from asking the model to “return the sum of 3 and 5” in a free‑form prompt?

In the free‑form case the model generates text, which must be parsed and can contain errors. The typed method call enforces a concrete int contract, validates arguments, and executes deterministic Python code, so the result is guaranteed correct and type‑safe.

Deterministic tasks—arithmetic, parsing, state updates—are moved into ordinary Python methods so the LLM focuses on high‑level reasoning.

The model receives the user request, identifies that a date is needed, and constructs the argument

The harness validates the

The deterministic parser returns a

The harness checks that the return type matches

By delegating parsing to a proven library, the model never mis‑interprets the date format, and the overall loop remains robust.

Why not let the LLM perform the date parsing itself?

LLMs are stochastic and can mis‑read ambiguous formats, producing incorrect or inconsistent dates. A deterministic parser guarantees a correct datetime object every time, and the model can rely on that exact value for downstream planning.

The Agent Loop and Interface

Unifies agent execution into a single, model‑driven loop.

Existing agents are split between plain Python methods and ad‑hoc prompt templates, forcing developers to juggle two execution models. NOOA collapses this split into a single, model‑driven loop that treats agents as ordinary objects.

An agentic method is a typed Python function whose body is replaced at runtime by a loop that lets the LLM read, write, and execute Python until a type‑checked result is produced.

How does an Agentic Method differ from a regular Python method?

A regular method runs its body directly; an Agentic Method replaces its body with an LLM‑controlled REPL that iteratively generates and executes Python until the return type is satisfied.

CodeAct runs a read‑eval‑print loop: each turn renders the current state, the LLM emits a Python cell, the cell is executed, and the updated state is fed back into the next turn.

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

The LLM writes a cell that iterates over $records$ to compute the sum of the first ten elements.

Execution returns `partial_sum` = 42+17+89+33+8+56+71+12+45+28 = 421.

The harness records a PythonOutput event containing $partial_sum$ and updates the dynamic context with `partial_sum`=421.

On the next turn the model sees the updated dynamic block and can decide whether to continue processing the remaining 90 elements.

The preview gives the model enough shape to index or slice the full list without ever sending the entire 100‑item payload.

Why not use PredictStrategy for the same task?

PredictStrategy makes a single LLM call and therefore cannot inspect or modify large objects; CodeAct’s iterative loop lets the model run arbitrary Python on the full data while only a tiny preview travels in the prompt.

ContextManager stores three kinds of text that together form the model’s prompt: static blocks (unchanging), dynamic blocks (re‑evaluated each turn), and the event‑history block (append‑only log).

EventManager is an ordered log of typed events that grows as the agentic method runs, enabling the model to query or summarize past actions.

```python from nooa import Agent TicketKind = Literal["refund", "damaged", "other"] # Return type: validated by the runtime before triage() returns. # Descriptions and constraints are model-visible. class Ticket(BaseModel): kind: TicketKind priority: int = Field(ge=1, le=5, description="Urgency from 1 (low) to 5 (high).") summary: str = Field(description="Customer-visible summary of the issue.") # The Agent is a Python object. class SupportAgent(Agent): """You are a support agent for a customer service system.""" # Object state: model-visible, passed by reference. order_db: OrderDB # Real body: ordinary Python. Deterministic, testable, callable by the model. def is_refund_eligible(self, order: Order) -> bool: """Return whether an order is eligible for a refund.""" return order.delivered and order.days_since_delivery <= 30 # "..." body: an agentic method. Predict makes a single typed LLM call. @strategy(PredictStrategy()) async def classify(self, message: str) -> TicketKind: """Classify the customer message into the best ticket kind.""" ... # The default strategy, CodeAct, runs a loop in which the model writes # Python: it can inspect order, call is_refund_eligible() and classify(), # and must return a Ticket. Inputs are live objects, not serialized text. @strategy(CodeActStrategy()) async def triage(self, message: str, photo: Image | None, order: Order | None) -> Ticket: """Triage a customer message and create a support ticket.""" ... ```

**Figure 2** | The CodeAct strategy loop within an agentic method. A caller invokes the method, then each turn renders context, calls the LLM, executes Python actions, and updates events and state. Once a successful, type-validated value is recorded, it is returned to the caller.

**Figure 3** | Context rendering in NOOA. The ContextManager and EventManager populate static context, event history, and dynamic context before each LLM turn.

**Figure 4.** Context engineering in NOOA. Context blocks and the event history are Python APIs available to both the developer and the agent.

Empirical Evaluation

NOOA achieves near‑perfect interface fluency and outperforms open harnesses on end‑to‑end benchmarks.

NOOA agents pass 97.9 % of the targeted capability suite, demonstrating fluent use of the NOOA interface across ten models.

4,309 of 4,400 test‑model runs succeed; small/efficient models achieve 96.0 % and large/frontier models 99.2 %.

**Figure 8.** Memory engagement per decision vs. performance in the ARC-AGI-3 fleet (25 games; a decision is one agent turn ending in `submit_actions`). Deliberate recalls per decision (left) and memories written per decision (right) against levels completed over the full run. Memory engagement per decision correlates positively with performance; every winning game makes at least one deliberate recall per decision.

Comparison to Other Harnesses

NOOA unifies fragmented agent tooling into a single Python framework where agents are ordinary objects.

Section 5 scored fourteen existing harnesses against the six capabilities NOOA provides; here we place those capabilities in the broader research landscape.

The table lists various AI harnesses, their underlying models, network access status, solve rates, and open-source availability.

**Table 7.** Emerging design patterns across agent development kits and harnesses. The field is broadly converging on six harness-interface patterns; shading shows how each system realizes each pattern today: native, emerging, or minimal. Detailed evidence appears in Appendix A.

Typed I/O has been explored in DSPy [26], LMQL [13], Outlines [55], Instructor [30], TypeChat [36], and ADK [22]; these systems let the model emit structured data that is later validated against a schema.

Code‑as‑action research includes PAL [21], Program of Thoughts [15], Chain of Code [29], Code‑Act [52], smolagents [48], OpenHands [53], SWE‑Agent [57], Anthropic’s tool‑calling [6], and Recursive Language Models [58]; they treat generated code as the primary action channel.

Pass‑by‑reference ideas appear in Cheng et al. [16] (Nightjar), AskIt [40], ANPL [24], and TaskWeaver [47]; they let the model read and write live Python objects rather than copying everything as text.

Loop engineering is supported by LangGraph [27], Microsoft Agent Framework [37], Google ADK [22], smolagents, and Claude Code [10], which expose control‑flow primitives to the model.

Object‑state handling is addressed by MemGPT [43], Letta [2], and Memory‑R1 [56]; they keep a persistent memory store that the model can query but not directly edit.

Model‑visible harness APIs are demonstrated in MemGPT, Letta, and Memory‑R1, where the model can invoke context‑management tools; NOOA extends this by making such APIs first‑class members of the agent object.

Stress Test Traces

Stress‑test runs reveal how a single return‑result mistake drops accuracy.

Load the shared system prompt, strategy prompt, and execution context (identical for all runs).

Instantiate the SentimentBatchAgent and call its

The model inspects the

In the first model‑authored cell, a fan‑out async function classifies each text in parallel and returns the list via

In the second model‑authored cell, the model mistakenly transcribes the printed list into a literal and calls

The scorer compares the returned list against the 50 reference labels; any missing or mis‑ordered entry reduces the exact‑match score.

When the model returns the live results variable directly, all 50 classifications match the reference labels.

Run B.1 (Nemotron 3 Ultra) executes the fan‑out async function and calls `return_result`(results) from inside the cell, yielding a perfect 50/50 match.

Transcribing the printed output into a literal and calling `return_result` causes a single missing classification, lowering the exact‑match score.

Run B.2 (Claude Opus 4.8) prints the list, then returns a literal that omits item 43 (“Typical response time.”), resulting in 49/50 correct.

Memory System Details

NOOA unifies fragmented agent development into a single Python framework of ordinary objects.

The central premise of NOOA is that agents can be ordinary Python objects with typed methods and state, eliminating the need for bespoke prompt templates or callback code.

MemoryManager gives an agent a single, mutable SQLite‑backed store that handles writes, retrieval, and lifecycle hooks without altering the agent’s core code.

Call

Tool

Spontaneous recall runs

Deliberate recall

Uninstall with

Pass‑by‑reference ensures the retrieved value reflects the current agent state, while the SQLite file guarantees a single source of truth for all memory operations.

How does NOOA’s MemoryManager differ from a typical vector store?

A vector store indexes embeddings and returns nearest neighbours, but it is opaque and lacks lifecycle hooks. MemoryManager stores typed records in SQLite, supports explicit importance scoring, and provides deterministic hooks (write, recall, reflection) that integrate with the agent’s execution flow.

The ARC‑AGI‑3 ablation shows that adding the NOOA memory subsystem improves performance.

In the controlled experiment, agents with the memory system achieved +11.8 RHAE points over identical agents using only file‑based notes.

Current agent harnesses fall into three families: flat markdown files, opaque vector stores, and structured self‑edited context blocks.

**Figure 5.** The NOOA memory system. `MemoryManager.install(agent)` attaches memory to an unmodified agent. The agent curates its own store through seven tools (write, green; deliberate recall, blue); a `BeforeTurn` hook injects associated memories into a dynamic context block (spontaneous recall, amber); reflection consolidates the store (magenta); every access is recorded (gray). All state lives in one human-inspectable SQLite file; the vector index is derived and pluggable.

**Figure 9 | Memory-system use by interface** in the ARC-AGI-3 fleet (25 games). Left: share of each memory type within the write, spontaneous-injection, and deliberate-read channels. Right: share of each verbal importance level per channel – both read channels concentrate on HIGH, and the concentration strengthens from written to injected to deliberately recalled.

Table 8 compares eight existing frameworks to NOOA, highlighting that NOOA uniquely offers a single human‑editable SQLite store with full observability.

Table 6 reports that “info” memories account for the majority of writes and reads, and that reflection memories have the lowest mean importance, confirming the design focus on high‑value knowledge.

Conclusion

We recap NOOA’s unifying design, its current limits, and promising research avenues.

NOOA unifies recent agent‑design advances into a single ergonomic Python kit where an agent is just an object with methods and state. This makes agentic software indistinguishable from ordinary software, letting developers and models share the same interfaces, libraries, and tools. Our evaluation shows that existing models already use this interface effectively despite never being trained on it.

A key limitation is that NOOA runs model‑written code in the agent’s own process, so the validator protects only the agent loop, not the host. In‑process execution preserves pass‑by‑reference, whereas sandboxed modes serialize objects at the boundary and lose that advantage. We therefore recommend deploying NOOA with OpenShell, which provides a container‑style sandbox while retaining the preferred execution model.

Future work includes agent rewriting, extending optimization beyond prompt search to rewrite prompts, docstrings, method signatures, helper code, tool descriptions, context policies, retry loops, and decomposition structure—GEPA‑style reflective optimization is a natural starting point. Typed interfaces also open a path toward self‑evolving skills that become full software packages with APIs, tests, examples, subagents, and versioned interfaces that agents can inspect, call, repair, and extend. Finally, reinforcement learning could teach agents inductive reasoning over complete trajectories, letting them choose context, preserve variables, generate deterministic helper code, promote reusable patterns, and decompose tasks, turning the harness itself into a learnable action space.

Taken together, progress in agent capability will stem from co‑development of models and their harnesses rather than merely larger models or better prompts. The software interface is the natural venue for this joint evolution, and NOOA represents a concrete step: an object‑oriented harness where agents are programs that humans and models can read, execute, test, and improve.

Harness Comparison Details

Detailed scoring of each agent framework expands Table 7.

This appendix expands the compact comparison in Table 7. Each subsection begins with the pinned source snapshot (repository, commit, and package version) used for verification, followed by scores on six axes: typed loop I/O, pass‑by‑reference, code as action, loop engineering, object state, and harness APIs.

**A.1 LangGraph / LangChain** – Evidence base: langgraph 1.2.8 (commit 23652c5…) and langchain 1.3.11 (commit 2d8100c…). Typed loop I/O: Partial; Pass‑by‑reference: Partial; Code as action: Partial; Loop engineering: Partial; Object state: Partial; Harness APIs: Partial.

**A.2 LangChain Deep Agents** – Evidence base: deepagents 0.6.12 (commit 7be76c7…). Typed loop I/O: Partial; Pass‑by‑reference: Partial; Code as action: Strong (opt‑in); Loop engineering: Strong (opt‑in); Object state: Partial; Harness APIs: Partial.

**A.3 Microsoft Agent Framework** – Evidence base: agent‑framework‑core 1.10.0 (commit 9c4cd07…). Typed loop I/O: Partial; Pass‑by‑reference: Partial; Code as action: Strong (opt‑in); Loop engineering: Partial; Object state: Partial; Harness APIs: Partial.

**A.4 OpenAI Agents SDK** – Evidence base: openai‑agents 0.18.0 (commit 078a28f…). Typed loop I/O: Partial; Pass‑by‑reference: Partial; Code as action: Partial (beta sandbox‑agents); Loop engineering: Partial; Object state: Limited (core) / Partial (beta); Harness APIs: Partial.

**A.5 Google ADK** – Evidence base: google‑adk 2.3.0 (commit 44d747e…). Typed loop I/O: Strong; Pass‑by‑reference: Partial; Code as action: Partial; Loop engineering: Partial; Object state: Partial; Harness APIs: Partial.

**A.6 PydanticAI** – Evidence base: pydantic‑ai (retrieved 2026‑07‑08, commit fc597c4…). Typed loop I/O: Partial (typed output only); Pass‑by‑reference: Partial; Code as action: Strong (opt‑in CodeMode); Loop engineering: Partial; Object state: Partial; Harness APIs: Partial.

**A.7 smolagents** – Evidence base: smolagents 1.27.0.dev0 (commit 526069c…). Typed loop I/O: Partial; Pass‑by‑reference: Strong; Code as action: Strong; Loop engineering: Strong; Object state: Partial; Harness APIs: Limited.

**A.8 Claude Agent SDK** – Evidence base: claude‑agent‑sdk 0.2.111 (commit 638e190…). Typed loop I/O: Partial; Pass‑by‑reference: Partial; Code as action: Partial; Loop engineering: Strong; Object state: Partial; Harness APIs: Partial.

**A.9 OpenAI Codex** – Evidence base: codex‑rs (commit f659eb1…) and SDK 0.142.x (July 2026). Typed loop I/O: Partial; Pass‑by‑reference: Partial; Code as action: Strong (flag‑gated); Loop engineering: Strong (flag‑gated); Object state: Partial; Harness APIs: Partial.

**A.10 OpenHands** – Evidence base: openhands‑ai 1.10.0 (commit 1869baf…) and SDK 1.33.0 (commit 2eff609…). Typed loop I/O: Limited; Pass‑by‑reference: Partial; Code as action: Partial; Loop engineering: Strong (opt‑in); Object state: Partial; Harness APIs: Partial.

**A.11 PI** – Evidence base: coding‑agent 0.80.3 (commit 351efc8…). Typed loop I/O: Limited; Pass‑by‑reference: Partial; Code as action: Partial; Loop engineering: Partial; Object state: Limited; Harness APIs: Partial.

**A.12 Hermes** – Evidence base: hermes‑agent 0.18.0 (commit 3c63ed3…). Typed loop I/O: Limited; Pass‑by‑reference: Partial; Code as action: Strong; Loop engineering: Partial; Object state: Partial; Harness APIs: Partial.

**A.13 OpenCode** – Evidence base: opencode 1.17.14 (commit 1c25b2f…). Typed loop I/O: Limited; Pass‑by‑reference: Partial; Code as action: Strong (flag‑gated); Loop engineering: Partial; Object state: Limited; Harness APIs: Partial.

DreamTeam Mapping

Appendix details the DreamTeam‑NOOA mapping, security audit, world‑model use, memory analysis, and reproducibility.

DreamTeam is a multi‑agent framework where each agent role is a plain Python object exposing typed methods and state, and the harness coordinates them via a REPL‑style protocol.

D.1 From DreamTeam to one agent and one skill – Table 9 aligns each DreamTeam element (latent encoding, executable dynamics, retrodiction, search, level‑boundary reflection, carry‑forward) with the NOOA example, preserving the methodology while collapsing the multi‑role apparatus into framework primitives or the agent’s own REPL.

This table compares the "DreamTeam" paper system with the "NOOA" example across seven functional elements: Encode $arrow$ latent $z$, Predict dynamics, Retrodiction, Search / planning, Verification, Memory across levels, and Team communication.

D.2 Containment and red‑team audit – the threat model enforces three rules: no internet, no access to a game’s source or identity, and no cross‑run or prior‑solution access. Defenses are layered: (i) per‑cell AST guard, module denylist, and an OS sandbox that forks each CodeAct cell with Landlock default‑deny, seccomp socket block, and strict memory/CPU caps; (ii) per‑run UID drop and a bubblewrap namespace sandbox; (iii) end‑to‑end anonymisation that exposes only opaque game‑ aliases.

A red‑team loop rescanned the 25‑game fleet every 30 minutes (18 passes). No rule was violated: zero network calls, zero game‑source bytes, and cross‑game reads failed with EACCES. One agent attempted a filesystem‑recon shell command; the cell guard intercepted it and returned no data. A latent finding (world‑readable harness logs) was fixed with a one‑line patch, and a known AST‑scan gap is back‑stopped by the UID‑drop sandbox.

D.3 World‑model usage evidence – 22 of 25 games persisted executable model code (37 modules, ~4.4 k lines). Five games ran the full predict + search + retrodiction loop, seven performed planning or prediction only, and ten used models for perception/encoding. Successful loops achieved near‑cap per‑level scores, demonstrating that curated persisted artifacts outperform ad‑hoc in‑cell code.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers