NVIDIA NOOA is an open-source, model-agnostic Python framework from NVIDIA Labs that collapses an entire AI agent into a single Python class: methods become the actions the model can take, fields hold agent state, docstrings are the prompts, and type annotations are contracts the runtime enforces. A 253-line agent built this way scores 82.2% on SWE-bench Verified with GPT-5.5 at xhigh effort — ahead of OpenCode at 78.6% and PI at 78.2%. It ships under Apache 2.0 as NVIDIA-NeMo/labs-OO-Agents.
The trick that makes it work is almost rude in its simplicity. Write a method body as ... and the runtime fills it in with an LLM-driven loop. Write a normal body and it stays deterministic Python. One file, one class, and the boundary between "the model decides" and "the code decides" is a single line of syntax.
This article covers how NOOA actually works, what the benchmark number does and does not prove, how the abstraction compares to LangGraph-style graphs, and the security problem sitting at the center of the design.
Key Takeaways
- NOOA (NVIDIA Object-Oriented Agents) models an agent as one Python class — no graph builder, no YAML, no separate prompt files.
- A method body of
...is completed at runtime by an LLM loop; a normal body runs as ordinary deterministic Python.- A 253-line NOOA agent hit 82.2% on SWE-bench Verified with GPT-5.5, and 79.8% with Claude Opus 4.6 — the framework is model-agnostic by design.
- Type annotations are enforced contracts, not hints, which is where most of the reliability gain comes from.
- NOOA can execute LLM-generated Python, so sandboxing is mandatory, not optional.
What is NVIDIA NOOA?
NOOA stands for NVIDIA Object-Oriented Agents. It is a Python framework, released open-source by NVIDIA Labs and documented in arXiv paper 2607.20709, for building agents as plain Python objects rather than as orchestration graphs, config files, or chains.
The framework arrived as part of a broader NVIDIA push into open agent infrastructure, announced alongside the company's 37-member Open Secure AI Alliance. The Hacker News reported both moves together on July 27, 2026, with detailed framework coverage following in early August.
The core idea is a mapping, and it is worth stating precisely because everything else follows from it:
| Python concept | Agent concept |
|---|---|
| Class | The agent itself |
| Method | An action the model can take |
| Field | Agent state, persisted across steps |
| Docstring | The prompt for that action |
| Type annotation | A contract the runtime enforces |
Method body ... |
Delegate this step to the LLM |
| Normal method body | Deterministic Python, no model involved |
If you have built agents before, notice what is missing: there is no tool registry, no JSON schema you hand-write, no separate system prompt, no graph edges. The class is all of those things.
How does NOOA actually work in code?
You define a class, annotate it, and leave the bodies you want the model to fill in as .... Here is the shape of a minimal NOOA-style agent:
from nooa import agent, llm
@agent
class TriageBot:
"""Triages incoming bug reports for a Python web service."""
open_issues: list[str] = []
@llm
def classify(self, report: str) -> str:
"""Return exactly one of: 'crash', 'perf', 'ux', 'security'."""
...
@llm
def draft_reply(self, report: str, category: str) -> str:
"""Write a two-sentence acknowledgement for the reporter.
Mention the category. Do not promise a fix date."""
...
def record(self, report: str) -> None:
# Deterministic: no model call, no ambiguity.
self.open_issues.append(report)
def handle(self, report: str) -> str:
category = self.classify(report)
self.record(report)
return self.draft_reply(report, category)
Three things are doing real work here. The -> str on classify is enforced — the runtime will not hand your code a dict because the model felt like emitting one. The docstring is the prompt, so it lives next to the signature it governs instead of drifting in a separate file. And record is plain Python, so the append happens exactly once, every time, regardless of what the model does.
That last point is the design's actual thesis. Most agent bugs are not model failures; they are orchestration failures where something that should have been deterministic got routed through a language model. NOOA makes the deterministic path the default and the model path an explicit opt-in.
Is NOOA better than LangGraph or CrewAI?
For agents whose control flow is naturally expressed as ordinary code, yes — NOOA is dramatically less ceremony. For agents that genuinely need branching, cycles, and inspectable state transitions across many nodes, a graph framework still models the problem more honestly.
The trade-off is concrete. LangGraph makes control flow a first-class, inspectable object: you can render the graph, diff it, and reason about every edge before running anything. NOOA hides control flow inside Python method calls, which is far more readable but much harder to visualize or statically analyze. You gain expressiveness and lose a map. We compared the graph-based options in detail in our guide to AI agent frameworks: LangGraph, CrewAI, and AutoGen.
There is also an interoperability question. NOOA defines its own tool surface through methods, while much of the ecosystem has standardized on the Model Context Protocol for connecting agents to external systems — see our explainer on what MCP is and why it matters. Framework-native tools are ergonomic; protocol-native tools are portable. NOOA currently optimizes for the first.
Where NOOA is clearly ahead is the onboarding curve. A Python developer who has never built an agent can read that TriageBot class and understand it completely in under a minute. That is not true of any graph DSL, and it matters more than benchmark deltas for adoption inside a normal engineering team.
What does 82.2% on SWE-bench Verified actually prove?
It proves that harness quality is worth several points of benchmark score independent of the model — and that a very small harness can beat much larger ones. It does not prove NOOA is the best framework for your production workload.
The published comparison, from a benchmark-agnostic 253-line agent:
| Agent harness | SWE-bench Verified | Model |
|---|---|---|
| NOOA (253 lines) | 82.2% | GPT-5.5, xhigh effort |
| OpenCode | 78.6% | GPT-5.5, xhigh effort |
| PI | 78.2% | GPT-5.5, xhigh effort |
| NOOA (253 lines) | 79.8% | Claude Opus 4.6 |
Two readings are legitimate. The generous one: a 3.6-point gap over OpenCode on identical models is a real engineering result, and getting it from 253 lines suggests the abstraction is genuinely subtractive rather than just differently shaped. The skeptical one: SWE-bench Verified is a Python-repository patch benchmark, harness scores on it are notoriously sensitive to scaffolding details, and "benchmark-agnostic" is a claim about intent, not a property you can verify from the outside.
The number that survives both readings is the 79.8% with Opus 4.6. Model-agnostic frameworks usually degrade badly when you swap the model, because the scaffolding was tuned against one model's quirks. A 2.4-point drop across vendors is unusually small. For a framework whose entire pitch is "model-agnostic," that is the more persuasive data point than the headline.
If you are choosing a coding agent rather than a framework to build one, our comparison of parallel AI coding agents covers the shipped tools instead.
The security problem you cannot skip
NOOA can be configured to execute LLM-generated Python inside your process. NVIDIA says this plainly in its own documentation, and the recommended mitigation is to run agents inside a sandbox isolated from your primary filesystem, such as NVIDIA OpenShell.
Take that seriously. An agent that generates and runs Python has, by construction, the capability to read any file your process can read, make any network call your process can make, and delete anything your credentials permit. Every one of those is a feature when the agent is working correctly and an incident when it is not.
The realistic threat model is not a malicious model. It is indirect prompt injection: the agent reads a file, an issue comment, or a web page containing text crafted to steer it, and then generates code that acts on those instructions. This attack class has been the dominant AI security story of 2026, and we covered how it has played out against shipped tools in AI coding agent security: the 2026 reckoning.
Minimum viable precautions before you run a NOOA agent on anything real:
- Sandbox the execution environment — container or VM, with no mount of your source tree unless the agent needs it.
- Scope credentials to the task, never to the developer. An agent should not inherit your personal cloud tokens.
- Keep deterministic methods deterministic. Anything touching money, deletion, or deploys should be a normal method body, never
.... - Log every generated body. If you cannot reconstruct what the model wrote, you cannot audit the incident.
Frequently asked questions
What does NOOA stand for?
NOOA stands for NVIDIA Object-Oriented Agents. It is an open-source Python framework from NVIDIA Labs that represents an AI agent as a single Python class, published under the Apache 2.0 license in the NVIDIA-NeMo/labs-OO-Agents repository.
Is NVIDIA NOOA free to use? Yes. NOOA is released under Apache 2.0, which permits commercial use, modification, and redistribution. You still pay for whatever model provider you point it at — the framework is model-agnostic and does not include inference.
Does NOOA only work with NVIDIA models? No. NOOA is explicitly model-agnostic, and NVIDIA's own published results include runs against both GPT-5.5 and Claude Opus 4.6. The small performance gap between those two runs is one of the stronger arguments that the model-agnostic claim holds up.
How is NOOA different from LangGraph? LangGraph models an agent as an explicit graph of nodes and edges that you can inspect and visualize. NOOA models it as a Python class where control flow is ordinary method calls. NOOA is far more concise and readable; LangGraph gives you a static map of what the agent can do, which matters for complex branching logic and auditing.
Is it safe to run NOOA agents? Only inside a sandbox. NOOA can execute LLM-generated Python, which means a compromised or misled agent can read files, make network calls, and modify its environment with your process's permissions. NVIDIA recommends running agents isolated from your primary filesystem.
What is SWE-bench Verified and why does 82.2% matter? SWE-bench Verified is a benchmark of real GitHub issues from Python repositories, where an agent must produce a patch that passes the project's tests. NOOA's 82.2% with GPT-5.5 beat OpenCode's 78.6% on the same model, which suggests the harness design itself is worth several points regardless of which model you plug in.
The verdict
NOOA is the most interesting agent abstraction released in 2026, and it is interesting for a subtractive reason: it removes concepts rather than adding them. Methods, fields, docstrings, and type hints are things every Python developer already understands, and mapping the agent onto them means there is no framework vocabulary to learn.
Use it when your agent's control flow reads naturally as code and you want the deterministic path to be the default. Stay on a graph framework when you need to visualize, statically analyze, or audit complex branching before it runs. And sandbox it either way — a framework that executes generated Python is powerful in exactly proportion to how much damage it can do.
The best abstractions make the dangerous thing explicit. ... is one character, and it is the whole decision.
