CodeMem: Architecting Reproducible Agents via Dynamic MCP and Procedural Memory

1 Introduction

• CodeMem uses a sandbox to write, validate, and save successful workflow logic into persistent procedural memory.The architecture shifts complex logic from volatile context windows into deterministic code.Source: §1 · p. 1
• The paper positions executable workflows as a way to address probabilistic instability in repetitive agent tasks.Its stated contribution is an architecture for reusable workflows with deterministic execution.Source: §1 · p. 1
• The paper evaluates CodeMem through a real-world case study and quantitative experiments after presenting its architecture and underlying bottlenecks.The paper roadmap identifies procedural-memory construction, architecture, case study, and experiments as the main later components.Source: §1 · p. 1

2.1 Procedural Memory in Theory

• Procedural memory remains a bottleneck even though working and semantic memory are better supported, motivating approaches based on code, model weights, or instructions.The paper identifies three possible capture mechanisms but notes that practical implementations are still missing.Source: §2.1 · p. 2

2.2 Implementing Procedural Memory via Meta Prompting

• Prompt modification is the more common practical approach, but stochastic models may not reliably follow updated procedures, especially when instructions are long.The LangGraph example uses user feedback and prompt rewriting to improve a Tweet generator, while the paper characterizes this approach as brittle.Source: §2.1 · p. 2, §2.2 · p. 2
• CodeMem treats procedural memory as frozen code, enabling deterministic execution without relying on instruction-following behavior.This contrasts with procedural updates represented primarily through graph topology or system-instruction changes.Source: §2.2 · p. 2

2.3 Progressive Disclosure for Tool Calling

• Dynamic ReAct and progressive disclosure reduce tool-context overhead by loading relevant tools and schemas on demand rather than injecting every definition.The paper describes this as shifting tool access from an O(N) context cost to an O(1) search operation.Source: §2.3 · p. 2
• Instruction tuning can update procedural behavior by generating refined instructions from conversation history and existing instructions, as illustrated by the LangGraph Tweet generator [11].The figure describes meta-prompting rather than code modification.Source: Figure 1 · p. 3
• A tool registry expands CodeAct’s action space beyond first-party Python libraries by making additional capabilities discoverable.The registry is presented as a key ingredient for an effectively infinite action space.Source: §2.3 · p. 3

3.1 The Performance Gap: CodeAct vs. ReAct

• 20% higher success rate was achieved by code-driven agents than ReAct agents on M3ToolEval.The comparison concerns code-driven versus standard text- or JSON-based tool invocation.Source: §3.1 · p. 3
• 30% fewer turns were required by code agents for equivalent tasks because executable blocks compose multiple actions in one step.ReAct instead requires a full language-model inference cycle for each individual action.Source: §3.1 · p. 3

3.2 Decoupling Reasoning from Computation

• CodeMem routes tool access through Dynamic MCP while offloading loops and data processing to a Python sandbox, leaving the LLM as a semantic router.The CPU performs syntactic execution, separating reasoning from computation.Source: §3.2 · p. 3

3.3 Contextual Complexity Analysis

• Standard tool calling makes context grow with each intermediate step, whereas CodeMem keeps prompt, code-block, and final-result context while transformations remain in sandbox memory.The described CodeMem formulation supports processing such as looping through 10,000 database rows without consuming equivalent token budget.Source: §3.3 · p. 4
• Table 1 compares JSON tool calling with CodeMem execution in the contextual-complexity analysis.The supplied table passage identifies the comparison scope but does not provide cell values or a supported winner.Source: Table 1 · p. 4

4.1 Probabilistic Instability

• Different code paths for identical requests cause trajectory divergence, so previously validated logic is not reliably reproduced.The same task may use different libraries across sessions, such as pandas one day and openpyxl the next.Source: §4.1 · p. 4

4.2 Redundant Computation and Latency

• Repeated tasks incur planning, code-writing, debugging, and execution costs because solutions are re-derived from scratch.Procedural memory can reduce recurring-task cost to approximately execution time.Source: §4.2 · p. 4

4.3 Inability to Retain Feedback

• Without cross-session memory, user corrections such as filtering by received rather than sent date are lost after the context window closes.The agent therefore requires repeated supervision for the same errors.Source: §4.3 · p. 4

4.4 Context Drift

• As long tasks accumulate code outputs and error logs, context drift can cause the agent to forget the original objective or loop on minor errors.A scraper may succeed while the required summarization is omitted.Source: §4.4 · p. 5

5 The Solution: CodeMem Architecture

• CodeMem reframes the LLM from a perpetual improviser into an architect of reusable skills through Dynamic MCP discovery and a Procedural Memory Bank.The architecture is designed to overcome reliability, persistence, latency, and context-drift bottlenecks.Source: §5 · p. 5

5.1 The Core Toolset

• The core toolset discovers and loads tool schemas just in time, tracks long-horizon dependencies, executes chained Python logic in a sandbox, and registers validated functions.These tools are search_functions, load_functions, write_todos, execute_code, and register_skill.Source: §5.1 · p. 5

5.2 Solving Instability

• CodeMem trials code in the sandbox, saves it only after user requirements and constraints are satisfied, then reuses the validated logic deterministically.This lifecycle turns ephemeral generated code into persistent procedural memory.Source: §5.2 · p. 5

5.3 Solving Latency and Cost

• Stored skills bypass planning, rewriting, and debugging for recurrent tasks, reducing latency and token costs associated with regeneration.Users can load stored skills into both the execution environment and the LLM’s context.Source: §5.3 · pp. 5–6

5.4 Solving Context Drift

• write_todos anchors long tasks with Pending, In Progress, and Completed states, allowing detailed subtask work without losing the overall plan.The resulting crystallized code is intended to remain complete and modular.Source: §5.4 · p. 6, Figure 2 · p. 6

6.1 The Challenge: High-Fidelity Data Orchestration

• The Outlook–OneDrive request combines a 15-day window, PDF/XLSX filtering, domain exclusion, and conditional company-name extraction.These four constraints make it a high-fidelity orchestration task.Source: §6.1 · p. 7

6.1.1 The ReAct Failure Mode: Context Collapse

• ReAct’s iterative handling of 50-plus emails and raw 5MB attachments can fill the context window, erase processing history, and trigger repeated fetching.The described failure mode is context collapse followed by a failure loop until the token budget is exhausted.Source: §6.1.1 · p. 7

6.2 The CodeMem Solution: Sandbox Orchestration

• CodeMem keeps data movement in the pipeline rather than the LLM’s context, using discovery, script generation, and sandbox execution as separate phases.The agent authors a Python script that handles the workflow logic in silico.Source: §6.2 · p. 7
• A single execution pass taking 14 seconds filtered 3 items and uploaded 4 files; its final artifact, the agent_main function, was saved to the user’s library for zero-shot reuse.Source: §6.2 · p. 7

• O(1) context complexity keeps data-size growth out of the LLM context by transferring binary contents within sandbox memory.The LLM sees references such as attachment['content'] rather than the underlying file contents.Source: §6.3 · p. 7
• Deterministic control flow syntactically enforces the requirement to ignore emails from @agentr.dev at every iteration.The generated script uses an if statement rather than relying on repeated model attention.Source: §6.3 · pp. 7–8
• The orchestration script computes a date cutoff and filters attachment-bearing emails before iterating through them.Source: §6.3 · p. 8
• The workflow separates data streaming from context loading and uses helper-based metadata extraction before uploading files to OneDrive.Source: §6.3 · p. 8

6.4.1 Pathway 1: Exploration-Driven (The Scientist)

• Exploration-driven formation requires hierarchical task analysis, as the agent decomposes an abstract goal into executable steps through trial and error.Source: §6.4.1 · p. 8
• Exploration is cognitively demanding because the agent must discover available tools, API limitations, and compensating Python-side logic.Source: §6.4.1 · p. 8
• Exploration follows an iterative, cyclic execution profile in which failed capabilities prompt strategy changes such as switching from markitdown to pandas.Source: §6.4.1 · p. 8
• Without a clear map, exploration risks goal drift while the agent fixes low-level syntax errors.Source: §6.4.1 · p. 8

6.4.2 Pathway 2: Instruction-Driven (The Architect)

• Instruction-driven formation makes the user the Architect and the agent the Builder, translating specified constraints directly into control flow.Source: §6.4.2 · p. 8
• Dense instructions trigger a confirmation handshake before code generation, allowing the agent to verify state-management requirements and naming choices.Source: §6.4.2 · pp. 8–9
• The confirmation step ensures procedural memory aligns with user intent before its logic is crystallized into the codebase.Source: §6.4.2 · p. 9

• write_todos externalizes complex workflows as a checklist spanning tool loading, email filtering, metadata extraction, folder creation, and upload.Source: §6.5 · p. 9
• When the sandbox crashes or logs truncate context, the agent reads pending todos to identify the unfinished step and generate a targeted fix.Source: §6.5 · p. 9
• This external anchor lets the agent resume exactly where it stopped without re-deriving the plan from chat history.Source: §6.5 · p. 9

7.1 Dataset Composition

• The dataset contains 25 multi-step tasks spanning Difficulty 1 retrieval through Difficulty 5 multi-tool orchestration.Source: §7.1 · p. 9
• Tasks cover personal productivity, data analysis, and system operations, requiring 2 to 8 distinct tools for verifiable outcomes.Source: §7.1 · p. 9

7.2 Evaluation Methodology

• Correctness was measured with Gemini 2.5 Flash as an LLM judge.Source: §7.2 · p. 9
• The judge inspected tool selections, arguments, sandbox code, execution outputs, and side effects rather than relying only on final text.Source: §7.2 · pp. 9–10

7.3 CodeMem Performance Analysis

• Gemini 3 Full achieved a minimum correctness of 96% with an average of 7.00 assistant calls, the highest stability reported in Table 2.Source: §7.3 · p. 10, Table 2 · p. 10
• GPT-5 Chat used 14.75s, 0.49M tokens, and 2.80 average calls, but frequently exited before iterating on edge cases.Source: §7.3 · p. 10

• Table 3 presents a comparison of architectural components.Source: Table 3 · p. 10
• The comparison is organized around problems addressed by the architecture.Source: Table 3 · p. 10
• The table’s stated scope is architectural components paired with problems solved.Source: Table 3 · p. 10