--- title: "Rebuilding the Runtime: What NVIDIA NOOA Reveals About Agent Frameworks" subtitle: "Its object-oriented model clarifies the trade-off between live program state and durable runtime control." url: "https://alphasignal.ai/news/rebuilding-the-runtime-what-nvidia-nooa-reveals-about-agent-frameworks" author: "Akruti Acharya" author_url: "https://alphasignal.ai/author/akrutireports" published: "2026-09-02T14:57:13.286Z" updated: "2026-09-02T14:57:14.518Z" type: "Deep Dive" topics: - "Agents" subtopics: - "Agent Frameworks" upvotes: 2 comments: 0 truncated: true --- # 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. 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](https://arxiv.org/abs/2607.20709) (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. ![](https://imagedelivery.net/kokADdxuw1FCXyR2p8D2CQ/7e280fb9-ca34-47f1-e715-f00814538000/public) ## 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. ![](https://imagedelivery.net/kokADdxuw1FCXyR2p8D2CQ/e4674161-b8b9-4530-6391-c6fb3cbda900/public) 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](https://newsletter.pragmaticengineer.com/p/building-pi-and-what-makes-self-modifying). 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](https://machinelearning.apple.com/research/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. _Preview only. Full text requires an AlphaSignal Pro account._ ## Sources - [Arxiv](https://arxiv.org/abs/2607.20709) - [Arxiv](https://arxiv.org/html/2606.15874v1) - [Newsletter](https://newsletter.pragmaticengineer.com/p/building-pi-and-what-makes-self-modifying) - [Machinelearning](https://machinelearning.apple.com/research/codeact) - [Arxiv](https://arxiv.org/abs/2512.14805) - [Support](https://support.hackerrank.com/articles/6745090586-repl-%5B-read%E2%80%8A%E2%80%94%E2%80%8Aeval%E2%80%8A%E2%80%94%E2%80%8Aprint%E2%80%8A%E2%80%94%E2%80%8Aloop%5D-)