# NVIDIA's NOOA turns an AI agent into one Python class > Source: > Published: 2026-08-10 21:46:05+00:00 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.