NVIDIA's NOOA turns an AI agent into one Python class

NVIDIA Labs has open-sourced NOOA (NVIDIA Object-Oriented Agents), a framework that models AI agents as Python classes, eliminating the need for separate tool schemas and pipeline configurations. An engineer who tested the framework found that while it is not yet on PyPI and lacks Python 3.14 support, the core concept of using method signatures as tool definitions simplifies agent development. NVIDIA reports that a 253-line NOOA agent achieves 82.2% on SWE-bench Verified and 86.8% on CyberGym L1, though the engineer cautions against taking vendor benchmarks at face value and emphasizes the need for sandboxing due to the framework's use of LLM-generated code execution.

NVIDIA Labs open-sourced NOOA https://github.com/NVIDIA-NeMo/labs-OO-Agents NVIDIA Object-Oriented Agents this week, and the pitch is unusually simple: an agent is a Python class. Not a graph, not a chain, not a YAML pipeline. A class. I cloned it and got it running the same day. Here's what it actually looks like, what broke, and why I think the core idea matters more than the framework itself. python from nooa import Agent class InventoryAgent Agent, llm=llm : """You are an agent that checks inventory using deterministic helper methods.""" Plain Python — automatically available as a tool for the LLM def get stock self, item: str - int: """Get current stock for an item.""" return self.inventory.get item, {} .get "stock", 0 ... body — the LLM implements this at runtime, calling the methods above async def can fulfill order self, items: list str , budget: float - Result: """Check if order can be fulfilled within budget.""" ... That's from the repo's quickstart, lightly trimmed. The mapping is: ... bodiesNo separate tool-schema JSON. No registration step. The model acts by writing Python in a REPL with access to self , so your method signatures are the tool definitions. The README says pip install nooa . Two things I hit on a clean machine: 1. It's not on PyPI yet. As of today, pip install nooa returns No matching distribution found . Install from source instead: git clone https://github.com/NVIDIA-NeMo/labs-OO-Agents.git uv venv --python 3.13 && uv pip install ./labs-OO-Agents 2. No Python 3.14 support. The package pins =3.12,<3.14 . My default interpreter is 3.14, and the install fails with a version error. Use 3.12 or 3.13. After that, everything imported cleanly and defining an Agent subclass with a generation method worked first try version installed: 0.0.1.dev1 — this is early software, and it behaves like it . Most agent frameworks make you maintain two parallel worlds: your code, and a shadow copy of your code described in schemas, prompt templates, and callback wiring. Every refactor has to happen twice. NOOA's bet is that the language already has all the metadata an LLM needs — signatures, types, docstrings — so the shadow world can be deleted. Your agent diffs like code, tests like code, and refactors like code. mypy and your IDE understand it because there's nothing else to understand. There's also a strategy layer worth knowing about: PredictStrategy single completion vs CodeActStrategy iterative code execution, capped by max iterations , swappable per method via a decorator. That's a clean answer to "some steps need one LLM call, some need a loop" without restructuring the agent. NVIDIA's paper claims a 253-line NOOA agent hits 82.2% on SWE-bench Verified and 86.8% on CyberGym L1. I haven't reproduced those numbers, and you shouldn't take vendor benchmarks at face value — but the interesting claim isn't the score, it's the line count. A NOOA agent acts by executing LLM-generated Python. With access to self , imports, and whatever your process can reach. NVIDIA's own docs tell you to run agents in a sandbox, and they mean it — this is exec with extra steps, by design. If you wouldn't run curl | sh from a model, don't run NOOA agents outside a container either. My own bias here: I build AI products, and the biggest lesson from my last one was that quality came from composing many small, checkable steps — not from trusting one big end-to-end model call. Most agent frameworks fight that instinct: they want the composition described in their vocabulary of chains and graphs instead of the language I already work in. NOOA is the first design I've seen where the composition just is Python. Which is also why the sandbox warning matters double — when wiring agents into real systems gets this frictionless, you'll ship one faster than you audit it. Today: probably not in production. It's a 0.0.1.dev1 that isn't on PyPI yet. But I'd bet on the direction. We spent two years building agent frameworks that look like workflow engines, and the results are brittle in ways every practitioner knows. "The programming language is the agent definition language" is the first framing I've seen that gets simpler as your agent gets bigger. Worst case, NOOA becomes the CoffeeScript of agents: the thing itself fades, but every framework after it steals the idea. The examples directory https://github.com/NVIDIA-NeMo/labs-OO-Agents/blob/main/examples/README.md is a genuinely good progressive tutorial — 11 numbered files from first generation method to MCP tools. Start with 03 codeact tools.py ; it's the one that made the design click for me. Have you tried collapsing your agent stack into plain code? I'd like to hear where it broke.