NOOA (NVIDIA Object-Oriented Agents)
NOOA (NVIDIA Object-Oriented Agents) is an open-source, model-agnostic Python framework for building AI agents, released by NVIDIA in July 2026 [1][2]. Its central idea is that an agent is a single Python object: the class's methods are the actions the model can take, its fields are the agent's state, its docstrings are its prompts, and its type annotations are contracts that the runtime validates [1]. A method whose body consists of the ellipsis literal (...) is completed at runtime by an LLM-driven loop, while a method with a normal body runs as ordinary, deterministic Python [1]. The accompanying paper is titled "NVIDIA-labs OO Agents: Native Python Object-Oriented Agents", and NVIDIA's announcement blog describes the project as an open-source research preview from NVIDIA Labs [1][3]. The code is hosted in the NVIDIA NeMo organization on GitHub under the Apache 2.0 license [2].
Key facts
| Developer | NVIDIA (NVIDIA Labs) |
| Type | Open-source Python framework for AI agents (research preview) |
| Paper | "NVIDIA-labs OO Agents: Native Python Object-Oriented Agents", arXiv:2607.20709, submitted July 22, 2026 [1] |
| Announcement | NVIDIA Technical Blog, July 27, 2026 [3] |
| Repository | github.com/NVIDIA-NeMo/labs-OO-Agents, created July 20, 2026 [2][5] |
| First public release | v0.0.7 on PyPI (package nooa), July 30, 2026 [4] |
| License | Apache 2.0 [2] |
| Model support | Model-agnostic via LiteLLM: hosted APIs (OpenAI, Anthropic) and local backends (Ollama, vLLM) [2] |
Design
Most agent frameworks represent prompts, tool schemas, callbacks, and workflow graphs as separate abstractions. NOOA collapses these into one construct, the Python class: a SupportAgent class can mix a deterministic method such as is_refund_eligible, which runs as plain Python, with "agentic methods" whose bodies are the ellipsis literal and whose behavior is produced by an LLM at runtime [1][2]. For an agentic method, the docstring and arguments become the prompt, the type signature defines the input and output contract, and the methods and fields on self become the tools and state the model can use [1]. The paper argues this brings prompt engineering back into software engineering: agents can be diffed, unit-tested, traced, versioned, and refactored with standard tools [1][3].
Agentic methods are implemented through strategies, declared with a @strategy decorator. NOOA ships two: PredictStrategy makes a single typed LLM call and validates the output against the return annotation with a local retry loop, while CodeActStrategy, the default, runs an iterative loop in which the model writes Python in a restricted, Jupyter-style REPL session [1]. In a CodeAct turn the model chooses between execute_python(...) to compute and return_result(...) to terminate; the returned value is validated against the method's return type before control goes back to the caller [1]. Executed cells receive the method arguments, the live agent as self, and the agent's imports as locals, and can call helpers, await other generation methods, or spawn subagents; APIs such as eval, exec, compile, and input are rejected with specific errors [1].
The paper identifies six model-facing interface ideas that, to the authors' knowledge, NOOA is 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 [1]. It compares fourteen other frameworks and harnesses against these capabilities, including LangGraph/LangChain, Microsoft Agent Framework, OpenAI Agents SDK, Google ADK, PydanticAI, smolagents, Claude Agent SDK, OpenAI Codex, OpenHands, and OpenCode, finding the community "already converging" on several of the ideas as experimental or partial features [1]. The authors state that NOOA is inspired by PyTorch, which showed that a powerful runtime can still present users with a simple Python programming model [1].
Context for each model turn is assembled from three regions: static context blocks computed once per call, an append-only history of typed events, and dynamic context blocks re-evaluated every turn; both the developer and the agent can manipulate these through Python APIs [1]. An optional long-term memory subsystem, MemoryManager, attaches to an unmodified agent and lets the model curate its own store through seven tools (remember, recall, search, update_memory, forget, associate, deref); retrieval ranks candidates by ACT-R activation, a background reflection pass consolidates the store, and everything persists in a single inspectable SQLite file [1][3].
The project labels itself research software and warns that agents configured to execute LLM-generated code can take dangerous actions. Its AST validation and module deny-lists are described as defense-in-depth guardrails, not a containment boundary, and the README instructs users to run code-executing agents inside OS-level isolation such as a container, VM, or NVIDIA OpenShell [2].
Data handling
NOOA passes method arguments to CodeAct methods by reference as live Python objects rather than serializing them into the prompt. For large arguments the model sees only a bounded preview: the variable name, its concrete type, its true length, and a short head/tail sample [1]. A list of one hundred integers, for example, renders as a single line showing len=100 plus the first and last five elements, while the full list stays bound as a local in the execution environment, so generated code can index, slice, or iterate over all of it even though only ten elements ever appear in the context window [1].
The paper presents this as the mechanism that 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, so a method can accept a multi-million-row table or a multi-megabyte string while the prompt carries only a fixed-size preview [1]. Tool calls are typed and pass by reference in both directions, so an agent can bind a large result to a variable and process it programmatically across cells, a pattern the authors contrast with agents spilling untyped text to files on disk [1]. NVIDIA also reports that this design removes the need for context compaction on SWE-bench with frontier models: because transcripts stay append-only and cache-valid, median sessions peaked at 22k to 72k prompt tokens against 200k to 400k context windows [3]. Methods using the Predict strategy instead render argument values in full, guarded by a size cap, since a single-shot call gives the model no opportunity to inspect a variable [1].
Evaluation
All results below are reported by NVIDIA in the NOOA paper and blog post; the harness comparisons were run by the authors themselves [1][3].
Capability tests
To test whether current models can use the interface, the authors built a suite of 88 integration tests across 36 families, covering typed method calls, structured returns, stateful object manipulation, bounded-preview interpretation, REPL use, batching, and error recovery. Running each test five times across ten models (four small models including Claude Haiku 4.5, Gemini 3.5 Flash, Nemotron 3 Nano 30B, and GPT-5.4 Mini, and six frontier models including Claude Opus 4.8, Gemini 3.1 Pro, GLM-5.2, Kimi K2.6, Nemotron 3 Ultra, and GPT-5.5) produced 4,400 records, of which 4,309 passed (97.9%); GPT-5.5 was perfect on the suite [1]. The authors attribute this fluency to the interface being ordinary Python, close to the code distribution the models were trained on [1].
SWE-bench Verified and Terminal-Bench 2.0
On SWE-bench Verified, the paper compares a single benchmark-agnostic NOOA agent of 253 lines of Python ("BenchAgent") against two open general-purpose coding agents, OpenCode 1.14.33 and PI v0.72.1, with the same GPT-5.5 and Claude Opus 4.6 backends at matched reasoning-effort settings [1]. With GPT-5.5 at the highest ("xhigh") effort, NOOA reached 82.2%, against 78.6% for OpenCode and 78.2% for PI; with Opus 4.6 at high effort it reached 79.8%, against 75.2% and 75.8% [1]. The paper notes the published leaderboard state of the art at submission was 79.2% (a specialized agent with Opus 4.5), and that specialized closed systems have reported 88.7% (Codex) and 80.8% (Claude Code) [1].
The gains did not come from longer trajectories: at GPT-5.5 xhigh, NOOA used approximately 28 model calls and 1.1 million tokens per task for its 82.2%, while OpenCode used a similar number of calls but about 1.3 million tokens for 78.6%, and PI used 66 calls and 2.2 million tokens for 78.2% [1]. The authors credit pass-by-reference (tool outputs remain live Python values instead of being re-serialized through the transcript) and typed termination: a NOOA agent must return a validated TaskResult with evidence and a verification command, whereas OpenCode stops whenever the model responds without a tool call [1].
On Terminal-Bench 2.0 (89 tasks), NOOA with GPT-5.5 at high effort reached 73.0%, ahead of OpenCode (60.7%) and PI (68.5%), and with Opus 4.6 at high effort reached 65.2% against 43.8% and 58.4%; PI obtained the best GPT-5.5 xhigh result at 75.3%, ahead of NOOA's 73.0% [1]. The published leaderboard state of the art at submission was 84.7% [1].
CyberGym L1 and ARC-AGI-3
On the CyberGym L1 vulnerability-discovery benchmark, a NOOA CodeAct agent with GPT-5.5 and network access blocked solved 86.8% of tasks, which the paper reports as the top open-source result, behind the closed systems Microsoft MDASHv2 (95.6%) and Crystalline (89.6%) but ahead of OpenAI Daybreak (85.6%) and OpenAI Codex configurations [1][3].
On ARC-AGI-3, an interactive-reasoning benchmark of unknown grid games, the authors compressed their six-agent "DreamTeam" world-model system into a single NOOA agent with a roughly 50-line skill. Under the competition's two-hour cap, the agent reached a fleet-mean RHAE (action-efficiency) score of 50.2% with GPT-5.5 and 85.1% with GPT-5.6-sol at under 20 dollars per game; the paper notes for scale that ARC Prize's own evaluation of raw GPT-5.6-sol on the same 25 public games averaged 13.3%, while cautioning that evaluation budgets differ and the comparison is indicative [1].
See also
References
- ^Furgale, Paul; Klingler, Severin; Nolan, James; Staats, Matt; Di Lorenzo, Gaia; Martinez Abad, Elisa; Schüller, Christian; Dinu, Razvan; Devoto, Alessio; Berard, Pascal; Kaplun, Gal; Sarafian, Elad; Roveri, Riccardo; Derczynski, Leon; Silveira Cabral, Ricardo. "NVIDIA-labs OO Agents: Native Python Object-Oriented Agents." arXiv:2607.20709, July 22, 2026. arxiv.org/...2607.20709
- ^NVIDIA-NeMo. "labs-OO-Agents" repository README. GitHub. Retrieved August 5, 2026. github.com/...labs-OO-Agents
- ^Silveira Cabral, Ricardo; Furgale, Paul. "Six Agent Harness Capabilities for Higher Model Performance." NVIDIA Technical Blog, July 27, 2026. developer.nvidia.com/...r-higher-model-performance
- ^"nooa" project page (release history). PyPI. Retrieved August 5, 2026. pypi.org/...nooa
- ^GitHub API repository metadata for NVIDIA-NeMo/labs-OO-Agents. Retrieved August 5, 2026. api.github.com/...labs-OO-Agents
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation. Every suggestion is reviewed for sourcing before it goes live.
v1 · 1,725 words · full history
Fact-checks are independent of edits: a reviewer re-verifies the article against its sources and stamps the date. How we verify
Research and drafting on this wiki are AI-assisted, under named human editorial standards. How AI is used here
Reviewer note: New article fact-checked on publication: every design and benchmark claim verified against the full arXiv paper (2607.20709), the GitHub repository and releases API, PyPI, and NVIDIA's July 27, 2026 blog post; benchmark comparisons carry their exact model and harness conditions, and a benchmark where a rival harness beats NOOA is included for balance.
Cite this page: AI Wiki. "NOOA (NVIDIA Object-Oriented Agents)." aiwiki.ai, updated 5 Aug 2026, fact-checked 5 Aug 2026. CC BY 4.0. https://aiwiki.ai/wiki/nooa