PaperlayerView exact revision on arXiv

Source-linked AI summary

NVIDIA-labs OO Agents: Native Python Object-Oriented Agents

Paul Furgale, Severin Klingler, James Nolan, Matt Staats, Gaia Di Lorenzo, Elisa Martinez Abad, Christian Schüller, Razvan Dinu, Alessio Devoto, Pascal Berard, Gal Kaplun, Elad Sarafian, Riccardo Roveri, Leon Derczynski, Ricardo Silveira Cabral

arXiv:2607.20709v1cs.AIcs.CL

TL;DR

Agent development often fragments familiar programming abstractions across prompts, schemas, callbacks, and orchestration. NOOA makes agents Python objects with methods, state, and contracts, and evaluations show current models operate this interface effectively despite never being trained on it.

  • Problem

    Agent frameworks often split familiar programming abstractions across prompt templates, schemas, callbacks, configuration, and orchestration code.

  • Method

    NOOA unifies agent development around Python objects whose methods and state form a shared interface for developers and models.

  • Results

    Current models operate the NOOA interface effectively, with 4,309 of 4,400 capability-suite records passed (97.9%).

  • Takeaways & Limitations

    NOOA suggests that agent progress can involve co-developing models and harnesses around software interfaces that agents and humans can execute, test, and improve.

  • Takeaways & Limitations

    NOOA executes model-written code in the agent process, so safe deployment requires external sandboxing because its validator does not protect the host.

Abstract

from arXiv · show

Traditional agent development is split across prompt templates, tool schemas, callback code, and workflow graphs. We present NVIDIA Object-Oriented Agents (NOOA), a model-agnostic Python framework for building reliable AI agents. NOOA takes a simpler approach: an agent is a Python object. Its methods are the actions the model can take, fields are its state, docstrings are its prompts, and its type annotations are contracts. A method whose code body consists of "..." is completed at runtime by an LLM-driven agent loop, while methods with normal bodies remain standard deterministic Python. This gives developers and agents the same interface, so agent behavior can be tested, traced, refactored, and improved just like other software. This paper makes three contributions. (1) We present the agent-as-a-Python-object programming model and the design principles behind it. Where Python has existing abstractions, we adopt them directly. Agent-specific capabilities--context, events, state rendering, long-term memory, and validated LLM loops--are exposed through simple Pythonic APIs, so both developers and agents share one familiar programming model. (2) We identify six model-facing ideas that NOOA is, to our knowledge, the first to combine on a single surface: typed input/output, pass-by-reference over live objects, code as action, programmable loop engineering, explicit object state, and model-callable harness APIs for context and events. We find the community already converging on several of these ideas--often as experimental or partial features--and present the comparison to encourage further adoption. (3) We demonstrate that current models use this interface effectively, both in targeted capability tests and on agentic and reasoning benchmarks such as SWE-bench Verified and Terminal-Bench 2.0 and ARC-AGI-3.

1. Introduction

NOOA presents agents as ordinary Python objects, replacing fragmented prompts, schemas, callbacks, and orchestration with a unified programming model. Its classes combine state, deterministic and agentic methods, while signatures, docstrings, tools, and runtime loops define the model-facing interface.

  • Motivation: Existing agent kits provide useful primitives but often fragment source code across prompts, schemas, callbacks, configuration, and orchestration.This forces developers to learn new programming models for capabilities with mature equivalents in ordinary programming languages.
  • Design principle: NOOA uses ordinary Python abstractions for agent actions, helper logic, and harness extension points, exposing agent-specific concepts through simple Pythonic APIs.The design covers concepts such as context construction, event history, and model-visible state.
  • Agent structure: A complete NOOA agent is a single Python class combining object state, deterministic code, and agentic methods such as single-shot Predict and iterative CodeAct.This class-based structure provides one surface for the agent’s implementation and behavior.
  • Agent structure: The class simultaneously serves as source code, prompt surface, type contract, tool interface, and state boundary.Methods with normal bodies execute as Python, whereas methods containing ... are run as LLM-driven loops.
  • Model-facing interface: Method signatures provide structured inputs and output validation, docstrings become prompts, and self methods or imported libraries become callable tools.Inputs can include non-text values, including images and live objects passed by reference rather than serialized into the prompt.

2. Design Principles

NOOA’s design principles build agents from familiar Python abstractions, separating deterministic code from LLM-driven method loops. The framework exposes typed object interactions, explicit state, code-based actions, and harness capabilities through Pythonic interfaces.

  • P1. Reuse Python abstractions: NOOA reuses mature Python abstractions: classes define agents, methods define capabilities, fields hold model-visible state, annotations define contracts, and control flow remains ordinary Python.Asyncio expresses concurrency and exceptions signal failures, making the same programming model available to developers and agents.
  • P2. Reframe agentic loops as method calls: Agentic loops appear as typed Python method calls operating on live objects, while the harness supplies context and validates return values.Arguments and object state are injected into the loop, with bounded previews rendered for the agent.
  • P3. Move deterministic work out of the agentic loop: NOOA assigns semantic judgment and open-ended work to LLMs while keeping exact rules, arithmetic, parsing, and state transitions in deterministic Python methods.A real method body marks deterministic work; an ellipsis body marks an agentic loop.
  • P4. Unlock the model’s existing Python knowledge: Models act by writing ordinary Python code, reusing loops, conditionals, asyncio, database clients, plotting libraries, and imports without a bespoke DSL.This is intended to make NOOA intuitive for autonomous coding agents and human developers alike.
  • P5. Expose the harness as explicit APIs: NOOA exposes structured context, context rendering, and event history through explicit Python APIs that are available to both developers and the model.The Agent can access and manage its own context through Pythonic primitives.

3. Agent Loop

NOOA makes an agent loop a typed Python method: ordinary control flow reaches ellipsis-body methods, which the harness executes through configurable LLM strategies. The loop renders structured context, lets the model act on live Python objects, records execution, and validates the returned value against the method’s type contract.

  • Agent loop: Ellipsis-body methods become agent loops whose docstrings and arguments prompt the model, while type signatures define input and output contracts.Ordinary methods execute directly; agentic methods are implemented at runtime by the harness, and the model can use methods and state on self.
  • Strategies: Strategies preserve typed Python boundaries while controlling context rendering, turn execution, and candidate validation on a per-method basis.PredictStrategy performs single-shot generation with local retries after type-validation failures, whereas CodeActStrategy provides an iterative Python REPL.
  • Agent loop: After Python actions update events and state, the harness validates submitted results against the return type, returning errors to the model or success to the caller.The CodeAct loop records code output, errors, return values, and locals before rendering the next turn.
  • Context rendering: Each CodeAct turn renders static context, append-only typed event history, and dynamic context blocks before calling the model.Event history records model calls, Python outputs, and return values; histories can be summarized and visibility can be restricted for nested calls.
  • Context rendering: NOOA exposes context management through Pythonic APIs that both developers and agents can use, rather than requiring external prompt-building scripts.Developers can dynamically override every context block, while the harness and agent interact with the same object-oriented interface.
  • Pass by reference: The model receives bounded previews of live Python arguments but can inspect and manipulate their complete values through code.Previews expose concrete type, true length, and head/tail samples, while execution retains the full object, allowing processing beyond the prompt context window.

4. Evaluation

NOOA is evaluated through targeted interface-capability tests and end-to-end benchmarks spanning software engineering, terminal interaction, cybersecurity, and interactive reasoning. Current models show strong basic interface fluency, while reliable multi-step harness use remains a frontier; NOOA agents achieve competitive benchmark performance through typed state, validated termination, and efficient live-object interactions.

  • Evaluation design: NOOA evaluation combines targeted capability tests with end-to-end benchmarks in software engineering, terminal interaction, cybersecurity, and interactive reasoning.The evaluation is organized into interface understanding and complete-agent performance levels.
  • Interface capability: 4,309 of 4,400 records pass overall (97.9%), with small/efficient models at 96.0% and large/frontier models at 99.2%.The tested models include four small/efficient and six large/frontier models.
  • Interface capability: 254 of 300 stress records pass (84.7%), revealing remaining difficulties in bookkeeping, error recovery, REPL iteration, answer refinement, and helper-based decomposition.These failures concern disciplined multi-step harness use rather than basic self-understanding or method calling.
  • End-to-end benchmarks: On SWE-bench Verified, NOOA reaches 82.2% with GPT-5.5 at xhigh reasoning effort, using approximately 28 model calls and 1.1 million tokens per task.This compares with OpenCode’s 78.6% using approximately 1.3 million tokens and PI’s 78.2% using 66 calls and 2.2 million tokens.
  • End-to-end benchmarks: On Terminal-Bench 2.0, NOOA reaches 73.0% with GPT-5.5 at high effort, ahead of OpenCode by 12.3 points and PI by 4.5 points.At xhigh effort, PI obtains the best GPT-5.5 result at 75.3%, compared with 73.0% for NOOA.
  • End-to-end benchmarks: Validated TaskResult outputs require evidence and a verification command, preventing unsupported completion declarations and improving termination reliability.NOOA’s live Python values also reduce repeated transcript serialization, supporting lower interaction and context costs.

5. Comparison to other harness libraries

NOOA is compared with fourteen agent frameworks and harnesses across six interface capabilities. The comparison finds that prior systems support important subsets, but NOOA is the first agent development kit known to expose all six on one surface.

  • Comparison axes: The comparison evaluates fourteen frameworks and harnesses against typed I/O, pass by reference, code as action, programmable loops, object state, and model-visible harness APIs.These are the six interface capabilities identified in Section 2.
  • Overall comparison: NOOA is the first agent development kit known to combine all six capabilities on a single surface.Prior systems support important subsets, but no other system combines all six ideas.
  • Scoring method: Scores were assigned from documentation and source code, checked against pinned snapshots, and classified as Supported, Partial, or Limited.Supported means the capability is first-class in the model’s view; Partial means it is mainly developer-facing or behind a tool or file; Limited means no evidence was found.
  • Scoring method: For harness APIs, a capability counts as Supported only when the model can see or call the context and event machinery.Tracing dashboards, automatic compaction, and hidden callbacks do not count; experimental, flag-gated, or opt-in capabilities are marked rather than demoted.
  • Field convergence: Most systems expose versions of the six ideas to developers rather than directly to models, while newer capabilities often remain experimental or flag-gated.The paper identifies field convergence around these capabilities and notes that newer offerings emerged during the evaluation window.

6. Related Work

Section 6 situates NOOA’s six interface capabilities within related work on typed LLM programming, code as action, reference-passing, orchestration, object state, and model-visible harness APIs. It shows that NOOA combines emerging ideas through a unified object-oriented Python runtime.

  • Typed I/O: Typed I/O systems constrain or validate model inputs and outputs, while NOOA enforces type annotations at generation-method boundaries.Prior approaches include declarative signatures, decoding-time constraints, schema validation, and framework-level input or output schemas.
  • Code as action: Code-as-action systems use executable programs for computation and tool interaction, a paradigm NOOA realizes as an object-oriented Python runtime.PAL, Program of Thoughts, Chain of Code, CodeAct, and smolagents develop or package this approach; a broader survey frames code as the substrate for reasoning, planning, memory, and coordination.
  • Pass by reference: Pass-by-reference approaches preserve live variables or inspect data recursively, whereas NOOA keeps typed Python inputs and outputs live in the session namespace.NOOA previews types and bounded sizes before exploration, allowing large inputs to be processed by shape without fully entering the context window.
  • Loop engineering: Agent frameworks expose orchestration through developer-defined graphs and workflows, while NOOA makes loop control available to both developers and agents.Examples include LangGraph, Microsoft Agent Framework, and Google’s ADK.
  • Object state: Durable-state systems use paged memory, files, searchable histories, or memory tools, but these approaches generally preserve untyped text outside working state.NOOA instead places typed fields and named context blocks on the agent instance and renders public fields from the live object each turn.
  • Harness APIs: MemGPT, Letta, and Memory-R1 expose memory-related harness operations, while NOOA uniformly provides model-callable context blocks and queryable event history.NOOA lets developers opt into visibility per agent and supports scoped overrides in harness code.

7. Conclusion · A. Appendix: Harness comparison details

NOOA presents agent development as ordinary Python software, while identifying in-process execution as a security limitation and outlining co-evolution of agents and harnesses. The appendix documents how harness-comparison scores were verified and how state and harness APIs are assessed.

  • 7. Conclusion: NOOA unifies agents, methods, and state as Python objects, giving developers and models the same interface, libraries, and tools.The evaluation reports that current models operate this interface effectively despite not being trained on it.
  • 7. Conclusion: In-process execution preserves pass by reference but requires external sandboxing because NOOA’s validator protects the agent loop rather than the host.The paper compares this isolation philosophy with harnesses using shell tools and notes that in-process Python is no safer than a shell tool.
  • 7. Conclusion: Agent optimization should rewrite the whole agent object and harness, including prompts, typed signatures, helper code, context policies, retry loops, and decomposition structure.The paper presents GEPA-style reflective optimization as a natural starting point for this broader target.
  • 7. Conclusion: Typed interfaces and libraries could turn skills into versioned software packages with APIs, documentation, tests, examples, subagents, and dependencies that agents can inspect, repair, and extend.This direction is contrasted with today’s text snippets and informal procedures.
  • 7. Conclusion: Reinforcement learning may induce inductive reasoning for object-oriented agents over a richer action space than text alone.The proposed action space includes choosing context, variables, and other aspects of the agent’s operation; the supplied passage attributes the motivating result to DeepSeek-R1.
  • 7. Conclusion: Progress in agent capability should involve co-developing models and harnesses through software interfaces, with NOOA offering agents that humans and models can read, execute, test, and improve.The conclusion frames NOOA as one step toward this object-oriented harness model.
  • A. Appendix: Harness comparison details: The appendix verifies Table 7 scores against pinned repository, commit, and package-version snapshots retrieved on July 7, 2026.It states that the scores use the paper’s model-visible rubrics.
  • A. Appendix: Harness comparison details: The comparison rates state as Supported only when typed, model-visible state is live within the session, while dedicated tools or next-session append-only memory receive Partial.Harness APIs assess whether structured context blocks, per-turn dynamic context, and session events are exposed as model-visible APIs rather than hidden host machinery.

A.1. LangGraph / LangChain … A.15. NOOA

Across the compared frameworks, typed loop contracts, live-object references, code actions, model-authored orchestration, explicit state, and model-callable harness APIs are generally partial or opt-in rather than unified. The supplied comparison shows stronger support emerging in selected frameworks, while model-facing interfaces often remain text-, tool-, file-, or developer-mediated.

  • A.1. LangGraph / LangChain; A.2. LangChain Deep Agents; A.3. Microsoft Agent Framework: LangGraph/LangChain, Deep Agents, and Microsoft Agent Framework provide partial typed boundaries, but model-facing inputs and calls remain primarily message- or text-mediated.LangGraph/LangChain and Deep Agents type graph or output state, while Microsoft types workflows and responses; none provides a fully typed model-facing method contract.
  • A.1. LangGraph / LangChain; A.2. LangChain Deep Agents; A.3. Microsoft Agent Framework: These three frameworks expose partial pass-by-reference through injected state, files, or artifacts, but live typed objects do not cross the model boundary.LangGraph/LangChain hides injected live objects from schemas; Deep Agents and Microsoft use file-oriented substrates, with Microsoft rejecting non-JSON-safe sandbox values.
  • A.1. LangGraph / LangChain; A.2. LangChain Deep Agents; A.3. Microsoft Agent Framework: Deep Agents and Microsoft offer strong opt-in code-action capabilities, whereas LangGraph/LangChain defaults to JSON tool calling and lacks a CodeAct-style loop.Deep Agents adds a beta persistent JavaScript REPL, while Microsoft’s prerelease Monty and Hyperlight providers make model-written code the action surface when enabled.
  • A.4. OpenAI Agents SDK; A.5. Google ADK; A.6. PydanticAI: OpenAI Agents SDK, Google ADK, and PydanticAI provide partial or strong typed output mechanisms, but their root or run inputs remain untyped or text-mediated.Google ADK enforces output schemas and validates tool or workflow-node inputs; PydanticAI supports multiple typed-output modes and retries validation failures, while OpenAI provides typed final output and tool schemas.
  • A.4. OpenAI Agents SDK; A.5. Google ADK; A.6. PydanticAI: Google ADK and PydanticAI expose partial model-callable context loading, while OpenAI Agents SDK provides model-callable skill mounting and deferred tool search without model-callable event inspection.These surfaces load artifacts, memory, skills, capabilities, or tools; context assembly and event inspection remain partly or wholly developer-mediated.
  • A.7. smolagents: smolagents uniquely combines strong live-object and code-action support with model-authored loops, but its state is untyped and its harness APIs are limited.The default local executor exposes live Python objects and persistent code execution; managed agents can be called inside generated code, while context and event controls remain developer-side.
  • A.8. Claude Agent SDK; A.9. OpenAI Codex: Claude Agent SDK and OpenAI Codex support strong model-side orchestration through workflow or delegation tools, while code-cell capabilities are restricted, gated, or absent by default.Claude workflows use JavaScript orchestration with agent, pipeline, and parallel calls; Codex’s code mode is under development and off by default, while default delegation does not let the model author loops.

B. Appendix: A stress test up close

The appendix examines four complete runs of the hardest sentiment_batch stress test, scoring 31/50 overall, and shows how identical harness context supports divergent model-authored executions. The traces expose typed agent state, tool-use rules, fan-out instructions, and live access to all 50 inputs despite truncated rendering.

  • Stress test: Four complete sentiment_batch runs comprise the hardest capability stress test, which scored 31/50 overall.The listings reproduce the harness-generated run traces, including ellipses and truncation markers.
  • Trace format: The harness presents titled blocks that distinguish cached system content, user-role task and execution messages, dynamic context, and model output.Colored left rules mark these roles amber, blue, and green, respectively.
  • Shared harness context: All four runs received byteidentical context containing the framework prompt, CodeAct instructions, execution context, and the agent’s typed doc(self) rendering.The shared prompt also includes fan-out guidance and instructions to return computed values by variable.
  • State and truncation: The model sees the true input length, len=50, and 25 rendered texts, while the texts variable retains all 50 inputs for direct indexing or iteration.The four runs diverge at the first model-authored cell.
  • Programmable execution loop: The strategy requires a tool call each turn and directs execute_python for batches or computation, return_result for final submission, and parallel PredictStrategy calls for per-item LLM work.Computed values must be passed directly from within execute_python rather than retyped in a separate return_result call.

B.1. Nemotron 3 Ultra — passed

Nemotron 3 Ultra passed by producing the intended solution in a single model-authored cell. The solution defined a subagent, fanned it out over a live variable, and returned the live result in 9.6 seconds end to end.

  • B.1. Nemotron 3 Ultra — passed: 9.6 seconds end to end, the model-authored cell defined a subagent, fanned it out over the live variable, and returned the live result.The passage identifies this as the intended solution.
  • B.1. Nemotron 3 Ultra — passed: The model-authored subagent used a typed classify_text method whose docstring specified positive, negative, or neutral sentiment outputs.The method is annotated as text: str -> str, and its docstring defines the sentiment categories.
  • B.1. Nemotron 3 Ultra — passed: The implementation processed all texts in parallel with asyncio.gather and returned the collected results.The code invokes classify_text for each text, gathers the results, prints them, and returns them.

B.2. Claude Opus 4.8 — failed · B.3. GPT-5.5 — passed · B.4. GPT-5.4 Mini — failed

The three model trials exposed distinct failure modes in a 50-item sentiment-classification task: Claude Opus 4.8 lost one result during transcription, GPT-5.5 passed with explicit bookkeeping, and GPT-5.4 Mini applied keyword rules instead of semantic judgment.

  • B.2. Claude Opus 4.8 — failed: B.2 Claude Opus 4.8 initially classified all 50 sentiment items correctly through the live fan-out.The model’s first cell executed the same fan-out correctly, and the execution output showed all 50 classifications correct.
  • B.2. Claude Opus 4.8 — failed: B.2 Claude Opus 4.8 then transcribed the printed output into return_result instead of returning the live results variable.The transcription dropped item 43, “Typical response time.”
  • B.2. Claude Opus 4.8 — failed: B.2 Claude Opus 4.8 failed because the returned list contained 49 items instead of the expected 50.The live results variable still held all 50 labels, despite the model stating that all classifications looked correct.
  • B.3. GPT-5.5 — passed: B.3 GPT-5.5 passed by defeating the preview and printing all 50 input items with explicit indices.The first cell used no subagents and exposed the complete input list for subsequent bookkeeping.
  • B.3. GPT-5.5 — passed: B.3 GPT-5.5 labeled the items by hand with explicit per-item bookkeeping.Its second cell again used transcription, but associated each sentiment label with an item index and rationale.
  • B.4. GPT-5.4 Mini — failed: B.4 GPT-5.4 Mini iterated the live variable correctly but replaced semantic classification with keyword rules fitted to the visible preview.The keyword-rule classifier was applied blindly to all 50 texts, including 25 it never inspected.
  • B.4. GPT-5.4 Mini — failed: B.4 GPT-5.4 Mini failed because its keyword-based labels did not match the required classifications.The model’s implementation returned labels correctly from the live variable, but its classification method violated the strategy instructions.

B.5. What the four runs show … D.2. Containment and red-team audit

The four runs show that failures stem from ignored instructions rather than insufficiently sophisticated harnesses, while NOOA’s memory and containment designs provide explicit, testable mechanisms for live state, extensibility, and isolation. The appendix examples preserve established methodologies while moving their apparatus into framework primitives or agent-executed code.

  • B.5. What the four runs show: Sophisticated harness use did not ensure success: Opus’s fan-out failed variable-return discipline, while GPT-5.5’s manual labeling passed careful bookkeeping.Both failures ignored explicit strategy-prompt instructions despite safe interface paths already being available.
  • C.1. Design decisions: MemoryManager.install(agent) additively equips an unmodified agent with storage, retrieval, and hooks through event subscriptions, call middleware, and context blocks.Uninstalling restores the agent exactly.
  • C.1. Design decisions: NOOA memories use strict name-based pass-by-reference resolution against live agent state, returning either a live value or an explicitly dangling snapshot.Prospective todo memories have lifecycle state, survive pruning while open, and can surface each turn.
  • C.2. Memory across today’s harnesses: Current harness memory systems cluster into always-in-context markdown, similarity-retrieved vector stores, and structured self-edited context.These approaches trade transparency and versionability against token cost, write-time verification, opacity, or background consolidation.
  • C.2. Memory across today’s harnesses: During 2025–2026, CLI harnesses converged on a hybrid of human instruction files and model-written auto-memory layers, differing in readability and retrieval bounds.The supplied passage identifies these as the main dimensions of variation.
  • D.1. From DreamTeam to one agent and one skill: The NOOA DreamTeam example preserves latent encoding, executable dynamics, retrodiction-based refinement, model search, and level-boundary reflection with carry-forward.Roles, inter-agent protocols, evaluation engines, and background search workers are absorbed by framework primitives or performed by the agent in its REPL.
  • D.2. Containment and red-team audit: The ARC-AGI-3 threat model forbids internet access, generating-source or identity access, and access to other runs, games, or prior solutions.Defenses layer in-process AST and module controls with an opt-in OS sandbox whose hard layers remain external to the agent.
  • D.2. Containment and red-team audit: 18 red-team passes over a 25-game fleet found no leakage: zero network invocations, zero source bytes returned, isolated stores, and zero real identifiers across 13,335 logs.Cross-game reads failed with EACCES, and outputs exposed only opaque aliases.

D.3. World-model usage evidence and failure modes

Across 25 games, persisted world-model code supported increasingly deep uses—from perception and encoding to prediction, search, and retrodiction—with deeper use tied to action efficiency. Failures arose when improvised in-cell searches lacked the bounds and budgets present in durable planners, motivating workspace discipline and hard cell timeouts.

  • World-model usage: 22 of 25 games persisted executable model code, totaling 37 modules and approximately 4.4k lines; six added per-level modules as mechanics accumulated.The observed progression included hazards, tokens, doors, and pressure plates.
  • World-model usage: Five games ran full predict–search–retrodiction loops, seven planned or predicted, and ten used models only for perception or encoding.Model depth tracked game demands rather than raw level count.
  • World-model usage: Deeper world-model use paid off through action efficiency, including near-cap per-level scores and long verified batches.One representative closed loop stored a 42-action plan and replayed twenty real frames through encoding to check it mid-execution.
  • Failure modes: The two games that hung used ad-hoc in-cell searches without max_depth, visited sets, or node budgets, including one branching over all 3,456 click targets per node.In that case, the persisted predict method went uncalled.
  • Failure modes: Durable curated artifacts were better engineered than improvised cell code, supporting memory-and-workspace discipline and hard per-cell OS-sandbox timeouts.These controls are presented as safeguards against unbounded in-cell searches.

D.4. Memory-system usage during play

During play, memory channels are selective and differentiated: importance rises from writing to injection to deliberate recall, while episodes surface through recency and facts through deliberate searches. Greater memory use per decision is positively associated with performance, especially deliberate recall, alongside substantial archival forgetting and compact stores.

  • Channel selection: Mean importance rises written → injected → deliberate (6.1 → 7.2 → 7.5), while high-verbal records comprise 61% of writes, 87% of injections, and 91% of deliberate reads.The ACT-R importance term biases both read channels toward records the agent marked important.
  • Read behavior: Episodes account for 10% of writes, 24% of injections, and 13% of deliberate reads, while info records comprise 82% of tool-read occurrences with a 99–100% hit rate.Recency surfaces the latest level attempts unprompted, whereas deliberate recall targets facts.
  • Store composition: Reflection records are 22% of rows but approximately 1% of both read channels, 45% of all records are archived by decay-based forgetting, and store sizes range 23/129/255.Intent and scratch types went unused, while todo appeared in 18 records.
  • Memory and performance: Deliberate recalls per decision correlate with levels completed at Spearman ρ= +0.52, and writes per decision correlate at ρ= +0.36.Winning games check memory 1.63 times and write 1.87 memories per decision, versus 1.21 and 1.46 for remaining games; every winning game makes at least one deliberate recall per decision.

D.5. Reproduction

The reproduction analysis uses guarded, cache-aware GPT-5.5 and GPT-5.6-sol fleets, with baseline and markdown-file ablation references, across 25 ARC-AGI-3 games. Memory engagement correlates positively with performance, while winning games consistently perform deliberate recalls.

  • Reproduction: The reproduction compares guarded, cache-aware GPT-5.5 and GPT-5.6-sol fleets with baseline and markdown-file ablation runs, each covering 25 games.The runs regenerate from per-game event logs using performance_2h.py.
  • Memory engagement: 25 games show that greater deliberate recalls and memories written per decision correlate positively with ARC-AGI-3 performance.Every winning game makes at least one deliberate recall per decision.
  • Memory-system use: Memory-system use differs across writing, spontaneous-injection, and deliberate-read channels, with both read channels concentrating on high verbal-importance levels.The concentration strengthens from written to injected to deliberately recalled memories.
Loading 2607.20709v1…