top of page
Search

NVIDIA NOOA: The Python-Class Framework for AI Agents





You know how every time you build an agent, you end up juggling five different things at once? A prompt template over here, a tool schema over there, some callback code to glue it together, and a workflow graph to keep it all moving.


It is not that it is hard, exactly. It is that it is scattered. You are not writing one thing, you are writing four things that all have to agree with each other, and the moment one drifts out of sync, the bugs that show up are annoying to trace.



What NVIDIA's NOOA Actually Proposes


NVIDIA introduced NOOA, short for NVIDIA Object-Oriented Agents. The pitch is refreshingly simple: what if an agent was just a Python class? Not “inspired by” a class. Actually just a class, the same kind you have been writing since you learned Python.


Fields hold state. Methods are what the agent can do. Docstrings become the prompt. Type hints become contracts the runtime actually enforces.


This is worth understanding properly, not just skimming the README. So here is the walkthrough: what NOOA actually is, what ships in the box, where it fits next to the frameworks you already know, and what NVIDIA is, and is not, claiming about how well it performs.





NOOA Turns an Agent Into a Single Typed Python Object



Fields Are State, Methods Are Capabilities, Docstrings Are Prompts


Think about a class you would write for anything else, say, something that manages customer orders in a normal backend project. It has fields that hold its data, and methods that do things with that data. NOOA just says: treat an agent exactly like that.


Picture a support agent built this way. The class docstring itself, a single sentence describing the agent's role, becomes the system prompt. A field on that class holds a reference to the order database, typed like any other Python attribute, the same way state would live on any object. One method might check whether an order qualifies for a refund, written as plain, deterministic Python with no model involved at all, since it is just returning a straightforward true or false based on the order's data. Another method might take an incoming customer message and turn it into a structured support ticket, and this one behaves differently.



What Makes a Method "Agentic" Instead of Deterministic?


That is the part that trips people up the first time, so let us slow down on it. That ticket-creating method has no real body at all, just a placeholder marker. That is not a forgotten implementation. In NOOA, a method left without a body is a signal to the runtime: "hand this one to the model." The method's name, its parameters, its docstring, and its return type together become the prompt and the contract for what the model needs to produce.


So in that one class, you have got a method that runs as plain code and a method that runs as an LLM call, sitting right next to each other, using the exact same syntax you already know. No separate "this is a tool" registration step. No JSON schema you have to keep in sync by hand.



Code as Action: The Model Writes Python, Not JSON Tool Calls


Most agent frameworks have the model output a JSON blob describing which tool to call and with what arguments, and then some orchestration layer parses that JSON and actually calls the function. NOOA skips that translation layer entirely. The model acts by writing real Python in a Jupyter-style REPL, with direct access to self, to imports, and to whatever helpers the agent exposes. Your methods and type annotations already describe what is callable, so there is no separate tool-schema definition to maintain in parallel.



Live-Object Arguments Passed by Reference


One more piece worth knowing: because everything is just Python objects, arguments can be passed by reference the way they normally would be in any Python program. You are not constantly serializing an object to a string, handing it to the model, and deserializing it back. The agent can hold onto a live object and keep working with it directly, which matters more than it sounds like once your agents start juggling anything more complex than plain text.





NOOA's Design Principle: Method Boundary, Not Serialization Boundary



What Does This Design Principle Actually Mean?


The answer comes down to one design principle NVIDIA keeps repeating: the line between "code the developer wrote" and "code the model wrote" should be a method boundary, not a serialization boundary.



What That Buys You in Practice


Once an agent is just a class, everything already familiar from Python classes carries over directly. Individual methods can be unit tested. Tracing shows exactly which method ran and in what order. Refactoring a method name lets an IDE catch every place that breaks. The whole thing sits in version control and produces a diff that looks like a normal code diff, not a diff spread across four different file formats that all have to be read together to understand what changed.



Where the Old Complexity Actually Came From


That is really the whole argument. Most of the complexity in older agent frameworks was not complexity the task needed. It came from splitting one idea, what should this agent do, across four separate abstractions that all had to be kept in sync by hand.





NOOA Ships as a Modular Set of Framework Components


Alright, let us open the box and see what is actually in here, because NOOA is not just the core class idea, there is a real set of tooling around it.



A Model-Agnostic Core Built on LiteLLM


NOOA does not lock you into one model provider. It uses LiteLLM under the hood, so you can point an agent at Anthropic's Claude, OpenAI's models, a locally hosted Ollama model, or a self-served vLLM endpoint, all through the same get_llm_client call. That matters if you are the kind of team that wants to A/B a hosted model against a local one without rewriting the agent itself.



What Does the NOOA Command-Line Interface Provide?


There is an optional nooa-cli package that adds a nooa command, a trace viewer you can run locally, and an eval runner for scoring agent behavior. It is marked as beta, so treat it as genuinely useful but still a little rough around the edges, not something you would wire into a production release pipeline yet without kicking the tires first.



The Memory Subsystem: A Typed, Human-Readable Knowledge Store


This is one of the more interesting pieces, and it is worth slowing down on. The memory subsystem attaches to an agent without you having to modify the agent's code. Underneath, it is a single, human-readable SQLite file, so you can actually open it up and look at what your agent remembers instead of trusting a black box.


The records are not just a flat log either. They are connected by typed relationships, things like "supports," "contradicts," and "derived-from", so the whole thing behaves more like a small knowledge graph than a simple chat history. There is also a background reflection pass that periodically merges duplicate entries, links related records together, and prunes information that is gone stale. Seven model-callable tools handle writing and recalling records, ranked by something called ACT-R activation, a way of prioritizing what is most relevant to recall right now rather than just what is most recent.



Skills as Composable, Reusable Agent Capabilities


NOOA also has a concept of "skills," reusable, packaged bundles of tools, prompts, and state patterns that you can drop into different agents instead of rebuilding the same capability from scratch each time. The repo ships example skills and a "cyber gym" agent as a working demonstration of the pattern.



What Does NOOA's Evaluation Package Add for Testing Agents?


There is a separate eval_pipeline package specifically for testing agent behavior in a structured way, rather than eyeballing a handful of runs and calling it good. If you have read our earlier post on building a proof-of-concept framework for enterprise agents, this is the kind of tooling that makes a real golden-task-set evaluation practical instead of a manual chore.



Tracing Runs by Default Across Every Call and Method


Every LLM call, every piece of executed code, and every method invocation gets traced automatically, with parent-child relationships preserved so you can see exactly how a complex, multi-step run unfolded. If you have got the CLI and viewer installed, you can launch a local dashboard and inspect a run in your browser. If the viewer is not running, tracing just quietly does nothing extra, no configuration required either way.





NOOA's Role in NVIDIA's Open Secure AI Alliance


Here is something that does not show up if you only skim the GitHub README, and it changes how you should think about NOOA's whole positioning.



NVIDIA Frames NOOA as Security and Governance Infrastructure


NOOA was not released as a standalone side project. It was released as the first named technical contribution to something called the Open Secure AI Alliance, a coalition NVIDIA formed with around 37 partner organizations, including names like Microsoft, Cloudflare, CrowdStrike, Hugging Face, IBM, and Red Hat. According to NVIDIA's own announcement, the whole point of NOOA in that context is to make agent behavior easier to test, trace, audit, and govern.


So this is not just "here is a cleaner way to write agents." NVIDIA is explicitly pitching NOOA as part of a bigger security and governance story, where being able to inspect exactly what an agent did, and why, is treated as a first-class requirement rather than a nice-to-have.



What Does "Auditable by Design" Mean in Practice?


Practically, it comes back to the same object-oriented structure we already walked through. Because state lives in typed fields instead of being buried somewhere in a prompt or a chat transcript, you can inspect exactly what an agent believes at any point without parsing LLM-generated text to figure it out. Because inputs are enforced at the interpreter level, malformed or malicious data has a much harder time slipping through a tool call unnoticed. And because the whole thing is ordinary Python, standard tools, type-checkers, static analyzers, debuggers, can be pointed directly at agent code the same way they would be pointed at any other part of your codebase.





NOOA's Place Inside an AI Agent Development Workflow


Let us zoom out from the internals for a second and talk about where this actually slots into the kind of work you are already doing.



Typed I/O With Auto-Retry as a Reliability Layer


Since every generation method has a typed return contract, NOOA can automatically retry a call when the model's output does not match what the method promised to return. That is a small thing on paper, but it removes a whole category of "the model returned malformed JSON and my code crashed" bugs that eat up more debugging time than they should.



Does NOOA Support MCP and External Tool Integration?


Yes. NOOA's progressive tutorial covers connecting agents to external context sources, databases, file systems, APIs, through the Model Context Protocol, alongside the framework's own native tool patterns. If you have been reading our Agentic AI series, you already know MCP is the vertical, agent-to-tool layer most production systems lean on today, and NOOA plugs into that same ecosystem rather than reinventing it.



Context Blocks and Dynamic Prompts


Beyond the static class docstring, NOOA supports context blocks and dynamic prompt construction, so an agent's effective instructions can shift based on what is happening in a given run, rather than being frozen at class-definition time.



Sandbox Execution as a Core Design Assumption


Here is the single most important thing to understand before touching this framework for anything beyond a toy example. NOOA's own documentation says plainly that in-process validation is not a containment boundary. Since the model is writing and executing real Python, a misbehaving or manipulated agent could, in theory, send data somewhere it should not, delete files, or otherwise mess with its environment.


NVIDIA's answer to that is not "trust the model," it is "isolate the execution." The documentation tells you to run any agent capable of executing generated code inside proper operating-system isolation, a container, a virtual machine, or NVIDIA's own OpenShell project, rather than assuming the framework itself will catch everything. Treat that as a hard requirement, not a suggestion.





NOOA's Benchmark Results Are NVIDIA's Own Reported Numbers



Why This Distinction Matters Before Looking at Any Figures


Before getting too excited about any numbers, a caution is worth stating plainly: these figures come from NVIDIA's own paper and NVIDIA's own technical blog. They are not independently verified by a third party, and that distinction matters.



What Does NVIDIA Actually Report?


Using a compact, roughly 253-line benchmark-agnostic agent built on top of NOOA, NVIDIA reports 82.2% on SWE-bench Verified with GPT-5.5 at high reasoning effort, 73.0% on Terminal-Bench 2.0 at high effort, and 86.8% on CyberGym L1, a vulnerability-rediscovery benchmark, with network access blocked during testing. NVIDIA also reports these results were reached at roughly half the token cost of the other open harnesses they compared against.



What This Means for Your Own Evaluation


Those are strong numbers if they hold up under independent scrutiny. But "if they hold up" is doing real work in that sentence. Vendor-authored benchmarks are a reasonable starting signal, not a substitute for running your own evaluation against your own tasks, which is exactly the discipline covered in the proof-of-concept framework post linked below.





Getting Started With NOOA



Installing the Core Framework With uv


NOOA is installed directly from GitHub using uv, added to a new or existing Python project as the nooa core package. There is no PyPI release yet, so getting started means pulling straight from the repository rather than reaching for a standard package index.



Which Sub-Packages Should You Add First?


Beyond the core, you have got a few optional pieces to decide on: nooa-cli for the command-line tool and trace viewer, nooa-memory for long-term state through the memory subsystem we talked about earlier, and eval_pipeline for structured evaluation. For a first project, the CLI is worth grabbing early since tracing is central to actually understanding what your agent is doing. Memory and evaluation packages tend to matter more once you are past a first prototype and into something you are actually trying to harden.



Choosing a Model Backend: Anthropic, OpenAI, Ollama, or vLLM


Because the core is model-agnostic through LiteLLM, this comes down to a straightforward trade-off. Hosted providers like Anthropic and OpenAI mean less infrastructure to manage, at the cost of API usage and a dependency on an external service. Local options like Ollama and vLLM mean more setup work, but they give you a fully local, sandboxed environment to test in, which fits neatly with the isolation requirements we already talked about.



Writing Your First Agentic Method


Conceptually, building your first agent comes down to the same pattern we walked through earlier: a class with typed state fields, a docstring acting as the system prompt, and one or more methods where an ellipsis body marks a generation method and a real body marks deterministic Python. The mental shift that takes people the longest to internalize is that the method's name and docstring are not just documentation, they are the actual prompt the model receives.



Viewing Traces in the Local Dashboard


Once you are running agents, NOOA's default tracing means every LLM call, code execution, and method invocation is already being recorded with parent-child relationships intact. A local trace viewer exists specifically to let you inspect those runs visually rather than reading through raw logs, and it is one of the more genuinely useful pieces of the tooling once you are debugging anything with more than a couple of steps.





Advantages and Limitations of NOOA



Advantages of NOOA


Advantage

Details

Single mental model

State, capabilities, and prompts all live in one Python class, instead of four separate abstractions you have to keep in sync.

Reduced schema drift

Typed method signatures serve as the contract, so there is no separate JSON tool schema that can quietly fall out of sync with the code.

Built-in tracing

Every call and method invocation is traced by default, with parent-child spans, no extra observability setup required.

Model-agnostic core

Works with Anthropic, OpenAI, and local models through LiteLLM, without rewriting the agent for each provider.

Fits existing Python workflows

Testing, refactoring, version control, and debugging all work the normal way, since the agent is just code.

Alliance-backed governance focus

Built as a named contribution to NVIDIA's Open Secure AI Alliance, with auditability treated as a design goal rather than an afterthought.



What Are the Trade-Offs of Using NOOA?


Limitation

Details

Research-preview maturity

NVIDIA describes NOOA as research software with real rough edges, not a production-hardened release.

Execution requires real isolation

The framework can execute LLM-generated Python, and NVIDIA's own documentation says in-process validation is not a containment boundary. Sandboxing is mandatory, not optional.

Smaller ecosystem

Compared to LangGraph, CrewAI, or AutoGen, NOOA has far fewer integrations, tutorials, and community-built examples to lean on today.

Beta-stage tooling

The CLI, trace viewer, and eval runner are explicitly marked beta, so expect some instability.

A different mental model to learn

Teams used to graph-based or role-based agent frameworks will need to unlearn some habits before the object-oriented approach feels natural.





How Much Does NOOA Cost to Use?


NOOA itself is free. It is released under the Apache 2.0 license, so there is no framework licensing fee standing between you and using it. The real cost lives elsewhere: whatever LLM API usage your agents rack up, plus the engineering time to set up a properly


sandboxed execution environment, since that isolation step is not something you can skip.

One thing worth factoring into that cost picture: NVIDIA reports its benchmark results were reached at roughly half the token cost of comparable open harnesses. If that efficiency claim holds up under your own testing, it is a real cost-per-completed-task advantage, not just a headline accuracy number, and it is the same "cost per completed task, not cost per call" lens we walked through in our proof-of-concept framework post.





NOOA Compared to Other Frameworks for Building AI Agents



NOOA vs. LangGraph: Object Methods vs. Graph Orchestration


LangGraph organizes an agent's behavior as an explicit graph of nodes and edges, which gives you very fine-grained control over branching, looping, and multi-agent handoffs. NOOA takes the opposite bet: instead of drawing the flow out as a graph, you write methods on a class and let the model's own reasoning decide the path through them. LangGraph tends to win when you need tight, predictable control over exactly how a workflow branches. NOOA tends to win when you want the agent's logic to read like ordinary Python rather than a graph definition.



NOOA vs. CrewAI and AutoGen: One Class vs. Role-Based Multi-Agent Design


CrewAI and AutoGen are built around the idea of multiple agents with distinct roles talking to each other to complete a task. NOOA's core unit is a single class per agent, so multi-agent setups in NOOA look more like several typed Python objects interacting directly, rather than a framework-managed conversation between roles. If your use case genuinely needs several distinct personas negotiating a task, CrewAI or AutoGen's role-based model may fit more naturally out of the box. If you want tighter type safety and less framework-imposed structure, NOOA's object model gives you more room to build that multi-agent pattern yourself.



NOOA and Provider-Native SDKs Like OpenAI Agents SDK and Claude Agent SDK


Provider-native SDKs are convenient when you are committed to one model provider and want the tightest possible integration with that provider's specific tool-calling and agent features. NOOA deliberately sits a layer above any single provider, trading some of that provider-specific polish for the freedom to swap models without rewriting your agents.



NOOA vs. Google ADK and LlamaIndex Agents


Google ADK leans into Google Cloud's broader ecosystem, and LlamaIndex Agents leans into that project's strength in data indexing and retrieval-heavy workflows. NOOA does not have that kind of ecosystem gravity yet. What it offers instead is a genuinely different structural approach, worth considering specifically when the appeal is the object-oriented design itself, not a particular cloud or data-retrieval integration.



Which Teams Get the Most Value From NOOA Today?


Realistically, this fits best for Python-heavy teams who already think in terms of classes and objects, teams comfortable running agents inside proper sandboxed isolation, and teams working on research, prototyping, or internal tooling where NOOA's research-preview status is not a dealbreaker. Teams that need a mature, battle-tested ecosystem with a large library of existing integrations are probably better served sticking with an established framework for now, and revisiting NOOA once it matures further.





Does Adopting NOOA Actually Improve Agent Reliability?


Let us be honest about what the evidence actually shows here, rather than taking the marketing framing at face value.


NVIDIA's own capability-test suite ran 88 test instances across 36 different families, repeated five times across ten different models, for 4,400 total test records. The reported pass rate was 97.9% overall. But dig one layer deeper: on a harder stress subset specifically covering things like batching, error recovery, and task decomposition, that pass rate dropped to 84.7%, and the gap between small models and frontier models widened noticeably on that harder subset, from roughly 3 percentage points on the easier tests to about 23 percentage points on the harder ones.


That is a genuinely useful data point, and again, it is NVIDIA's own reported evaluation, not an independently audited one. What it tells you honestly is this: typed contracts and built-in tracing do reduce a real category of failures, schema drift, malformed outputs, silent tool-call errors. What they do not do is replace the need for your own evaluation against your own tasks, or the sandboxing discipline NVIDIA itself insists on. NOOA gives you better tools to catch problems. It does not make the problems disappear on its own.





CodersArts Support for NOOA and AI Agent Projects



Framework Evaluation and Proof-of-Concept Builds


If you are trying to figure out whether NOOA, or any object-oriented approach to agent development, is the right fit for your team, we help run that evaluation properly, using the same golden-task-set discipline we cover in our proof-of-concept framework post, rather than a quick demo that tells you very little.



What Does a NOOA Evaluation Engagement Actually Involve?


Typically, it starts with scoping a bounded, measurable use case, building a realistic sandboxed environment, running the agent against a real task set, and reporting back on task success, tool reliability, cost, and safety, the same six dimensions we use for any agent PoC, adapted to NOOA's specific architecture and its object-oriented method boundaries.



Sandboxed Environment Setup for Code-Executing Agents


Since NOOA agents can execute generated Python, proper isolation is not optional. We help teams set up that sandboxed execution layer correctly from the start, whether that is containerized isolation, a dedicated VM, or an OpenShell-style setup, so testing and eventual deployment do not inherit unnecessary risk.





Frequently Asked Questions



Is NOOA Safe to Use in Production?


NVIDIA describes NOOA as a research preview, not production-hardened software. It can be configured to execute LLM-generated code, which NVIDIA's own documentation says requires running inside proper OS-level isolation. Treat it as suitable for prototyping and internal tooling today, with production use requiring careful sandboxing and your own evaluation first.



Does NOOA Work With Claude, GPT, and Open-Source Models?


Yes. NOOA's core is model-agnostic through LiteLLM, so it supports hosted models like Anthropic's Claude and OpenAI's GPT models, as well as locally hosted models through Ollama or vLLM, all through the same interface.



How Is NOOA Different From LangChain-Style Tool Calling?


Instead of registering tools through separate schema definitions the model calls via structured JSON, NOOA methods are already the interface. The model writes and executes real Python against self, so there is no separate tool-schema layer to keep in sync with your actual code.



Do I Need the CLI or Memory Package to Get Started?


No. The core nooa package is enough to build and run a basic agent. The CLI, memory, and evaluation packages are optional additions worth adding once you need tracing visibility, persistent memory across sessions, or structured evaluation.



How Does NOOA's Memory Subsystem Work Across Sessions?


It stores records in a single, human-readable SQLite file, connected through typed relationships that form a small knowledge graph rather than a flat log. A background reflection process periodically merges duplicates, links related entries, and prunes stale information, so an agent can accumulate knowledge across sessions without retraining.



What Benchmark Results Has NVIDIA Published for NOOA, and Are They Independently Verified?


NVIDIA reports 82.2% on SWE-bench Verified, 73.0% on Terminal-Bench 2.0, and 86.8% on CyberGym L1, alongside a 97.9% pass rate on its own capability-test suite. These figures come from NVIDIA's own paper and technical blog and have not been independently verified by a third party, so they are a useful starting signal rather than a substitute for your own evaluation.



What Is the Open Secure AI Alliance, and How Does NOOA Fit Into It?


The Open Secure AI Alliance is a coalition NVIDIA formed with roughly 37 partner organizations, including Microsoft, Cloudflare, CrowdStrike, Hugging Face, IBM, and Red Hat, focused on building open, inspectable AI security tooling. NOOA was released as the alliance's first named technical contribution, specifically aimed at making agent behavior easier to test, trace, audit, and govern.





What Services Does CodersArts Offer?


Beyond framework evaluation and agent-specific delivery work, CodersArts offers a wider range of services that agencies, businesses, and individual developers regularly rely on.



AI and RAG Development


Custom AI and RAG development, starting from proof of concept through to full production builds, along with broader LLM and generative AI development for businesses building AI-powered products and internal tools.



Consultation


Project consultation for businesses and agencies evaluating an AI or infrastructure initiative, helping assess feasibility, recommend the right technical approach, and scope a project before committing to full development.



One-on-One Mentorship


Personalized, expert-led mentorship for developers and teams looking to build hands-on AI, machine learning, or infrastructure engineering skills, with guidance tailored to individual or team goals and current experience level.



Dedicated Team and Team Augmentation


Dedicated AI and infrastructure engineering teams, or engineers who work as an extension of an existing in-house or agency team, scaling up or down based on project needs.



Ongoing Support and Maintenance


Post-launch monitoring, optimization, and maintenance for AI systems and infrastructure already in production, helping ensure performance and reliability do not degrade over time.



Job Support Services


Remote job support for developers and engineers working on live AI, infrastructure, or LLM projects, including pair programming, code reviews, workflow setup, debugging, and help meeting sprint deadlines under expert guidance.



Corporate and Team Training


Structured training and workshops for teams looking to build internal AI and infrastructure capability, covering hands-on implementation as well as best practices for evaluation and production readiness.



White-Label and Partnership Delivery


CodersArts also partners with agencies, consultancies, and technology companies to deliver AI and infrastructure development on their behalf, whether white-label, co-branded, or embedded alongside an existing team.


Whether you are a team deciding if NOOA or another agent framework fits your project, an agency looking for a delivery partner, or a developer wanting hands-on mentorship, CodersArts offers services to support your AI journey.


Reach out at contact@codersarts.com or visit www.codersarts.com to discuss your agent development project.





Continue Exploring AI Resources


If you found this blog helpful, explore more AI resources from CodersArts AI to see how organizations are applying these systems to real world applications.





Comments

bottom of page