Skip to content

CodeMem: Architecting Reproducible Agents via Dynamic MCP and Procedural Memory

🕒 Published (v1): 2025-12-17 11:28 UTC · Source: Arxiv · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

CodeMem is an agent architecture that achieves reproducible, deterministic task execution by combining dynamic just-in-time MCP tool discovery with a persistent procedural memory bank of versioned Python functions. Rather than re-generating code stochastically each run, the agent crystallizes validated logic into reusable "skills" that execute deterministically thereafter. This directly addresses the probabilistic instability and context-drift failures of vanilla CodeAct agents.

Problem

Vanilla CodeAct agents (which use Python as their action space) remain probabilistically unstable: for identical tasks across sessions, they may generate different code paths, re-derive solved logic from scratch (incurring redundant tokens/latency), lose user-provided corrections after context close, and suffer context drift in long multi-step workflows as intermediate outputs crowd out high-level goals. Existing procedural memory approaches (prompt rewriting, weight editing) are either unreliable or impractical.

Method

CodeMem augments a CodeAct agent with four core tools: - search_functions / load_functions: Dynamic MCP — tools are discovered from a registry and injected into context just-in-time (O(1) cost vs. O(N) for static injection). - write_todos: External state anchor tracking task steps as Pending → In Progress → Completed, preventing goal drift during long-horizon tasks. - execute_code: Runs Python in a sandboxed environment; all data movement, loops, and conditionals execute in the sandbox heap rather than the LLM context, keeping context cost at O(1) relative to data size. - register_skill: Once sandbox execution succeeds and the user confirms constraints, the validated async def agent_main(...) function is frozen into a persistent library. Future invocations skip plan/write/debug phases and run directly to Texecute.

Skill formation occurs via two pathways: Exploration-Driven (agent performs hierarchical task decomposition via trial-and-error) or Instruction-Driven (user provides full algorithm; agent issues a "handshake" confirmation before crystallizing).

Key Contributions

  • Procedural memory implemented as versioned, deterministic Python code rather than prompt mutations or weight updates.
  • Dynamic MCP discovery layer decoupling tool existence from tool definition, enabling infinite-scale tool libraries without context bloat.
  • write_todos as external working memory for state recovery after sandbox crashes or context truncation.
  • Formal context-cost analysis showing CodeMem reduces N-step context from O(N × (prompt + history + tool_output)) to O(prompt + code_block + final_result).
  • Evaluation harness using LLM-as-a-judge (Gemini 2.5 Flash) with full trajectory access (tool calls, raw code, stdout/stderr, side effects) across 25 multi-step tasks.

Results

  • Gemini 3 Full: 96% minimum correctness, 7.00 avg. assistant calls, 100.48s P50 latency, 2.02M tokens.
  • Claude 4.5 Sonnet: 79% minimum correctness, 6.96 avg. calls, 71.38s latency, 2.61M tokens.
  • GPT-5 Chat: 68% minimum correctness, 2.80 avg. calls, 14.75s latency, 0.49M tokens — low latency attributed to premature loop exit rather than genuine efficiency.
  • Referenced CodeAct vs. ReAct baselines (from Wang et al.): code-driven agents achieved 20% higher success rate and 30% fewer turns on M3ToolEval.
  • Case-study execution: processed 7 emails, filtered 3, uploaded 4 files in 14 seconds in a single sandbox pass.

Limitations

  • Evaluation dataset is small (25 tasks) and self-curated by the authors, limiting generalizability.
  • The judge model (Gemini 2.5 Flash) is one of the evaluated models' family, raising potential evaluator bias.
  • Skill registration requires a successful sandbox execution plus user confirmation — exploration-driven pathway is still susceptible to goal drift before crystallization.
  • No ablation separating the contribution of Dynamic MCP vs. procedural memory bank vs. write_todos; all components are evaluated together.
  • Security and sandboxing of arbitrary agent-generated code is delegated to Anthropic's sandbox with no independent analysis.
  • Skill versioning and conflict resolution (when a new run produces different logic for an existing skill) are not addressed.

Relevance to Harnesses / Meta-Harnesses

CodeMem is directly relevant as an architectural pattern for self-modifying harnesses: the register_skill mechanism is a runtime meta-harness operation where the agent extends its own executable capability library without human code changes. The Dynamic MCP discovery layer exemplifies the tool-registry pattern central to scalable harness design — harnesses that load only the tools relevant to the current task rather than injecting all definitions statically. The write_todos state anchor maps closely to task-graph persistence used in multi-agent harnesses to survive context resets and sandbox failures. For builders of orchestration harnesses, the context-cost analysis (O(1) vs. O(N) scaling) and the trial-then-freeze lifecycle provide concrete design principles for when to generate vs. reuse agent logic.