Rebuilding the Runtime: What NVIDIA NOOA Reveals About Agent Frameworks
Its object-oriented model clarifies the trade-off between live program state and durable runtime control.

- NVIDIA's OO Agents framework (NOOA) collapses agent prompts, tools, state, and model-driven loops into a single Python class, where ordinary methods handle deterministic logic and methods with
...bodies are completed at runtime by the model. - NOOA supports two execution strategies per generation method:
PredictStrategyfor single structured predictions andCodeActStrategy, which gives the model an iterative Python REPL with access to live object state, avoiding repeated JSON serialization round-trips. - The framework's key trade-off is that live objects eliminate serialization overhead within a process but offer no built-in cross-session recovery, making durability, distribution, and replay harder compared to graph-based runtimes that treat checkpointing as a first-class mechanism.
- NOOA reports competitive benchmark results on SWE-bench Verified, Terminal-Bench 2.0, and ARC-AGI-3, though scores conflate model, prompt, tool design, and runtime and cannot isolate the object model as the causal factor.
- The article argues that framework proliferation stems from tool calling defining only an action boundary while leaving loop ownership, state location, termination conditions, and failure handling unresolved — the two key design questions being which loop layer the model should own and where state must survive.
Take one stateful task like working through a production incident, and try to write the agent for it. A single task turns into a list of tasks. You write a system prompt, JSON tool schemas, and callbacks that fire when a tool returns. One task ends up scattered across several configuration systems that share no vocabulary.
This scattering helps explain why agent frameworks keep multiplying. Tool calling solved the first problem, which was how a model invokes an external capability. In solving it, tool calling exposed how much it left unsolved.
A tool schema defines only an action boundary. It says what a single call looks like and what comes back. It does not say who runs the loop that strings calls together. It does not say where the state between calls lives, or what counts as done, or what happens when something fails halfway. Those decisions constitute the runtime. Many newer frameworks are really arguments about how to make them, including graph engines, file-and-shell agents, and now object-oriented ones.
NVIDIA's recently published OO Agents framework (NOOA) takes an unusually clean position: collapse prompts, tools, state, and model-driven loops into one Python class. NVIDIA reports competitive results on SWE-bench Verified, Terminal-Bench 2.0, and ARC-AGI-3. To understand why the design matters, first look at what an agent runtime controls.

What a Runtime Actually Controls
Strip away the branding and every runtime answers the same five questions. How does model output become an executable action? Who controls the loop and decides when the model gets control back? Where does state live across calls? What counts as done? And how are failures handled through errors, retries, checkpoints, and recovery?
Two of these questions dominate the rest. The first is who controls the loop, whether that is the model, the developer's application code, or a dedicated runtime. The second is where state lives, whether in the transcript, in files, in checkpoints, or in live program objects.
One useful version of the first splits the agent loop, where the model calls tools and reads results inside one session, from the harness loop outside it. The harness loop decides whether the task is finished and injects more work if not.
I think most framework disagreements are really about where the boundary between those two loops belongs. They are also about which loop owns the state.
Four Ways to Represent an Agent
Frameworks cluster into four models. The table below maps where each one places control and state. Real systems routinely combine two or more.

Typed tool calls keep the cleanest contracts. Every action has a schema and every result has a shape. They pay for that clarity by serializing data in and out of the transcript on every turn.
Graph workflows, the LangGraph lineage, make control durable and inspectable. The cost is a workflow abstraction layered on top of the model's own reasoning. The core move is to represent the task as explicit states, with transitions governed either by fixed rules or by the model.
StateFlow stated this crisply. It separates process control (i.e., the state machine) from task judgment (i.e., the work done inside a state). That separation is the row's defining idea. Durable checkpointing and restart are properties of specific engines, not of the abstraction itself. File-and-shell agents give the model the most expressive action space, since it can write and run arbitrary code. This is the design behind coding tools like Claude Code and Mario Zechner's deliberately minimal Pi. Their persistent state usually lives indirectly and untyped in the file system, even where the tool boundaries stay typed.
The idea that a model should act by emitting executable code, rather than a constrained JSON call, is not new. CodeAct made the case in 2024. It consolidated agent actions into a single Python action space, precisely because pre-defined tool schemas limit what the model can compose. Live-object frameworks are the newest entry, and NOOA is the clearest specimen.
Don't miss what's next in AI
Join 300,000+ engineers and researchers who get the signal, not the noise. Create a free account to read the rest of this story.
- Full access to in-depth AI research breakdowns
- Be the first to know what's trending before it hits mainstream
- Daily curated papers, repos, and industry moves