Shared Selective Persistent Memory for Agentic LLM Systems

Authors: Sanjana Pedada, Aditya Dhavala, Neelraj Patil (Apple Inc.)
Venue: arXiv 2607.09493v1
Year: 2026
Pages: 11
Auto-discovered: 2026-07-13 via daily paper analysis cron

Shared Selective Persistent Memory for Agentic LLM Systems

Title: Shared Selective Persistent Memory for Agentic LLM Systems
Authors: Sanjana Pedada, Aditya Dhavala, Neelraj Patil (Apple Inc.)
Venue: arXiv
Year: 2025
Pages: 11
Code URL: Not explicitly provided in the paper


研究摘要 (Research Summary)

Agentic LLM systems—those capable of autonomously invoking tools, writing code, and executing multi-step reasoning to accomplish user goals—have achieved remarkable success in recent years. Systems like GitHub Copilot, Claude Code, and ChatGPT Code Interpreter demonstrate that large language models can transcend mere text generation and become active agents capable of manipulating real-world artifacts. Yet beneath these impressive capabilities lies a persistent and often overlooked limitation: every session begins from zero. When a conversation ends, the accumulated context—domain constraints, data schemas, tool configurations, prompt refinements, and output format preferences—is discarded entirely. This is not merely an inconvenience; it represents a fundamental inefficiency in how agentic systems manage knowledge, forcing users to repeatedly re-specify what the system should already know.

This paper introduces shared selective persistent memory, a memory architecture that fundamentally reimagines how agentic systems retain and reuse knowledge across sessions. Rather than naively persisting entire conversation histories (which, as the authors demonstrate, actively degrades performance), the proposed architecture identifies four orthogonal categories of reusable context—task specifications, data schemas, tool configurations, and output constraints—and persists them independently of the session-specific reasoning traces. The key insight is that what makes a session productive is not the messy, idiosyncratic reasoning process but rather the declarative configuration that governs how the agent approaches its domain. This distinction mirrors an important observation from cognitive science: declarative memory (knowing what) and procedural memory (knowing how) serve different functions, and conflating them yields suboptimal results.

The paper's contributions extend across architecture, implementation, and evaluation. Theoretically, it provides a principled decomposition of agentic context into persistent versus ephemeral components, grounded in the well-documented "lost in the middle" phenomenon where irrelevant context degrades LLM output quality. Architecturally, it proposes a workspace model with role-based access control, enabling collaborative reuse of accumulated context without redundant specification. The zero-token data refresh mechanism is particularly elegant: by enforcing a strict data-injection contract where generated artifacts consume data exclusively from runtime injection points, the system enables recurring data updates with zero LLM re-invocation, achieving a 14-fold reduction in task time for recurring updates. The complementary summary-driven generation reduces data representation tokens by 97-fold compared to raw data injection, providing correct code generation without the overhead of reading raw data at generation time.

The empirical results are striking and counterintuitive. Across three enterprise deployment scenarios and four public datasets, shared selective memory achieves a 96% task completion rate compared to 79% without memory and 71% with full history persistence—meaning that injecting the complete prior session transcript actually performs worse than starting from scratch. This finding challenges the prevailing assumption that more context is always better and establishes that selective forgetting is not merely a token-efficiency optimization but a quality improvement strategy. The replication on public datasets confirms generalizability, with zero-token refresh succeeding in 12 out of 12 trials. Notably, the failures of full-history persistence are dominated by "trace anchoring"—the phenomenon where the agent becomes fixated on previously explored solution paths rather than generating fresh approaches for the current task. This is a subtle but profound observation: the very traces that help the agent succeed in one session become harmful biases in the next.

The practical impact of this work is significant for enterprise workflows where users repeatedly perform structurally similar tasks. An analyst generating a weekly supply chain dashboard no longer needs to re-specify 8-12 formatting constraints each session (typically 4-5 turns). A director can publish a workspace as a versioned template, allowing colleagues to load it with their own schema-compatible data and render it immediately under role-based access control. A team can iteratively build a workspace across sessions, with each member adding components while draft isolation protects the published version. Session time drops from approximately 20 minutes to approximately 5 minutes. These gains are not merely incremental improvements but represent a qualitative shift in how agentic systems can be deployed: from ephemeral, single-user sessions to persistent, collaborative, and reusable workspaces.


理论框架 (Theoretical Framework)

The intellectual lineage of this work draws from several converging streams of research in artificial intelligence and cognitive science. At its foundation lies the observation that context window extension alone does not solve the problem of what to persist. While Press et al. (2022) and Chen et al. (2023) demonstrated that longer contexts enable larger prompt windows, their work does not address the qualitative question of which information should be retained across sessions. This distinction is crucial: the memory architecture proposed in this paper is not about capacity but about structure—about identifying which information is reusable and which is not.

Retrieval-augmented generation (RAG), as introduced by Lewis et al. (2020), provides a natural point of comparison. RAG systems retrieve relevant documents at the document level, augmenting the LLM's prompt with external knowledge. However, the granularity of document-level retrieval does not match the needs of agentic systems, which require structured configuration at the level of parameter schemas, tool invocation patterns, and output constraints. The paper's proposal operates at a finer semantic granularity: it is not retrieving documents but configuring the agent with domain-specific rules, data schemas, tool configurations, and output contracts. This represents a shift from retrieval-augmented generation to configuration-augmented generation—a subtle but significant reconceptualization of how external knowledge enters the generation process.

The concept of selective forgetting draws directly from the "lost in the middle" phenomenon documented by Liu et al. (2024), who demonstrated that language models struggle to utilize information in the middle of long contexts. This finding was initially interpreted as a positional bias, but the authors of this paper extend it to a more general principle: not all context is equally valuable, and actively discarding low-relevance information can improve performance. In the context of agentic systems, a prior session's tool-use trace is not merely irrelevant but actively harmful, as it biases the agent toward previously explored solution paths rather than generating fresh ones for the current task. This insight transforms the "lost in the middle" problem from a passive limitation into an active design principle: we should not merely manage context length but actively curate context quality.

The four-category decomposition of reusable knowledge is the core theoretical contribution of this paper. The authors define four orthogonal memory categories, each serving a distinct function in the agentic generation pipeline. Task specifications (Mtask) encode domain rules, output preferences, and quality constraints as custom system prompt extensions. These are user-authored and refined over multiple sessions, capturing the declarative knowledge that governs how artifacts should be generated within a domain. Data schemas (Mdata) provide precomputed summaries of associated data sources—column names, types, statistical distributions, unique value catalogs, and sample rows—enabling the LLM to generate correct data-processing code without reading raw data. Tool configurations (Mtools) capture the set of available external tools, their parameter schemas, invocation patterns, and authentication requirements, which are stable but expensive to discover across sessions. Output constraints (Moutput) represent structural contracts between the generated artifact and its runtime environment, most critically the data-injection contract that enables zero-token refresh.

The mathematical formulation of memory composition is elegantly simple yet conceptually rich. When a new session begins, the system prompt is composed from persistent memory as:

s=sbaseMtaskMtoolsMoutput

where sbase is the default system prompt and denotes structured concatenation with section headers. The data schema is injected into the user message alongside the query:

q=qMdata

This composition is performed at the application layer before the LLM is invoked, ensuring the model receives a fully contextualized prompt without any awareness of the persistence mechanism. The workspace encapsulates the full selective memory state as:

W=(Mtask,Mdata,Mtools,Moutput,a,V)

where a is the most recent generated artifact and V is its version history. This formulation makes explicit that the workspace stores structured configuration, generated code, and version metadata, but never conversational transcripts, reasoning traces, or tool invocation logs. The distinction is between a curated artifact store and a chat history—a distinction that has profound implications for how we think about memory in agentic systems.

Equally important is what the authors call selective forgetting: the explicit discarding of session-specific information. Given a session trace T=(t1,t2,...,tn), the system discards intermediate temporary files, unapproved changes, reasoning traces, tool invocation logs, error recovery paths, and raw data. This selective forgetting is motivated by the observation that a prior session's tool trace is not just irrelevant but potentially misleading—it biases the agent toward repeating a previous solution path rather than generating fresh for the current query. This is a subtle but profound insight: the very information that helps the agent succeed in one session becomes a harmful anchor in the next. The cognitive science parallel is compelling: this is the procedural/declarative memory distinction applied to machine learning, where persisting the "what" (specifications, schemas) while discarding the "how" (execution traces) yields better results than persisting everything or nothing.

The zero-token data refresh mechanism is another theoretical contribution that extends the framework beyond simple context management. By enforcing a strict data-injection contract—generated artifacts must consume data exclusively from a runtime injection point, never from hardcoded values—the system decouples the generated program from its runtime data. When new data arrives (from any connector type), the system checks schema compatibility: the original column set must be a subset of the new source's columns. If compatible, data refreshes with zero tokens; if the schema has diverged, the user is prompted to regenerate. This enables additive schema evolution (new columns are permitted; missing columns trigger regeneration) and represents a principled approach to data-program separation that is particularly powerful in enterprise settings where data updates are frequent but schema changes are less so.

The assumptions of the theoretical framework are worth examining. The decomposition assumes that reusable knowledge can be cleanly separated into four categories, which, while validated across the artifact types evaluated (dashboards, reports, documents), may not generalize to all agentic domains. The framework also assumes that the data-injection contract can be enforced at generation time, which requires the LLM to understand and adhere to the contract—a constraint that may be more reliably met with stronger models but could be challenging with weaker ones. The role-based access control model assumes that workspace-level sharing is the appropriate granularity, which may not capture the nuanced sharing requirements of complex enterprise workflows. These assumptions define the boundaries of the framework's applicability and suggest directions for future theoretical work.


技术架构 (Technical Architecture)

The shared selective persistent memory architecture is implemented as a deployed collaborative workspace platform consisting of a FastAPI backend, an agentic LLM engine, a multi-connector data layer, and a conversational frontend. The system is designed around a workspace model where each workspace encapsulates the full selective memory state, enabling both individual persistence and collaborative sharing. The architecture operates as a closed loop: users interact with a conversational frontend, each session is contextualized by selective persistent memory drawn from the workspace store, the agentic engine generates and edits versioned artifacts through autonomous tool use, and external data is accessed via a multi-connector integration layer. The data flows through the system with a clear separation between the LLM-generated program and the runtime-bound data, enabling the zero-token refresh mechanism that is central to the system's efficiency.

The data flow begins when a user initiates a new session. The system retrieves the workspace's selective memory—task specifications, data schemas, tool configurations, and output constraints—and composes them into a fully contextualized prompt. The LLM receives this prompt without any awareness of the persistence mechanism, generating an artifact that consumes data exclusively from the runtime injection point. When the user saves changes, only the selective memory categories are persisted to the workspace; the session trace is discarded. The generated artifact is stored in a git repository with version control, draft isolation, and revert capabilities. This flow ensures that the system maintains a clean separation between the persistent declarative knowledge (the workspace memory) and the ephemeral procedural knowledge (the session trace), with the data-injection contract bridging the two by allowing the artifact to adapt to new data without re-generation.

The agentic engine is the heart of the generation pipeline. Each user turn initializes a fresh session with the composed system prompt and data summary. The agent uses Claude Opus 4 via the Claude Agent SDK with autonomous tool use, scoped to the user's session workspace. Two interaction modes are supported: edit mode for artifact generation and modification, and query mode for read-only questions over existing artifacts. The engine operates within a carefully defined sandbox: file system access is scoped to per-user session directories, and generated artifacts are served in sandboxed browser contexts. This isolation ensures that the autonomous tool use does not leak across workspaces or sessions, maintaining the integrity of the selective memory model.

The data integration layer is a unified connector interface that abstracts four source types—CSV upload, SQL databases, REST APIs, and MCP servers (JSON-RPC with mTLS)—into a normalized tabular representation. Rather than injecting raw data into the LLM prompt, the system precomputes a compact statistical profile that captures the information needed for correct code generation in approximately 500 tokens—a 100-fold reduction over raw injection for typical enterprise datasets. This summary-driven approach is not merely a token-efficiency optimization but a correctness strategy: by providing structured metadata (column types, distributions, categorical catalogs, sample rows) rather than raw data, the system helps the LLM generate more accurate code by grounding generation in statistical understanding rather than data surface patterns. The profiling operates on columnar statistics in constant memory regardless of row count, making it scalable to large datasets.

The persistence and versioning layer manages two distinct stores: workspace metadata (the four memory categories, access control lists, and data source configurations) is persisted to MongoDB, while generated artifacts and their version history are managed through git, providing full version control with diff, branch, and rollback capabilities. Notably, no conversation history or reasoning traces are stored in either layer. This design choice is deliberate: the workspace is a curated artifact store, not a chat history. Users edit within isolated draft sessions; in-progress modifications do not affect the published artifact until explicitly committed via a publish operation that creates a new git-versioned snapshot. An in-session undo stack (up to 10 snapshots) enables risk-free exploration—users can revert to any prior version without re-invoking the model. This git-backed versioning with draft isolation provides user agency over the memory lifecycle, enabling exploration and restoration without the cost of re-invoking the LLM.

The collaborative sharing workflow exploits the zero-token data architecture in a four-step process. First, a colleague loads the shared workspace, restoring all selective memory into their session. Draft isolation ensures their edits do not affect the published artifact. Second, they connect their own data source (e.g., their region's SQL database, a different REST endpoint, or an uploaded CSV). If schema-compatible, the artifact renders with new data using zero tokens. Third, they ask refinement questions within the established context, benefiting from the persisted task specifications and tool configurations without re-specification. Fourth, viewers without edit access can use the AI query mode to ask questions about the artifact and its underlying data, receiving answers contextualized by the workspace's selective memory. Access is managed through OIDC-based identity with three roles: owners have full control over the workspace and its memory; stewards can edit artifacts and modify task specifications; viewers can load, query, and extend with their own data but cannot modify the base workspace. This role-based access control ensures that the collaborative benefits of shared memory do not compromise the integrity of the workspace's selective memory.

The key innovation in the architecture is the strict separation between the LLM-generated program and the runtime-bound data, enforced by the data-injection contract. Generated scripts must consume data exclusively from a well-defined runtime injection point, never from hardcoded values. The LLM generates programs that parse, aggregate, and render dynamically—including insight text (summaries, outliers, rankings)—so that when the underlying data changes, the artifact re-renders correctly without any LLM re-invocation. This is a fundamental architectural shift from the traditional model where the LLM is invoked for every data change. Instead, the LLM is invoked once to generate the program, and subsequent data changes are handled by the runtime without model invocation. The schema compatibility check is the gatekeeper: the original column set must be a subset of the new source's columns, enabling additive schema evolution while protecting against incompatible changes that would break the generated artifact.

The implementation demonstrates careful engineering choices that reflect the system's enterprise deployment. The use of FastAPI for the backend provides a modern, high-performance Python framework that is well-suited to serving the LLM agentic engine. The choice of MongoDB for workspace metadata persistence balances the need for flexible document storage with the structured nature of the four memory categories. Git for artifact versioning is a natural choice that provides enterprise-grade version control without custom implementation. The multi-connector layer's support for MCP servers is forward-looking, as MCP (Model Context Protocol) is emerging as a standard for tool discovery in agentic systems. The use of Claude Opus 4 for primary generation and Claude Sonnet 4 for lightweight subtasks (schema validation, tool dispatch) demonstrates a practical tiering strategy that balances capability with cost.


实验评估 (Experimental Evaluation)

The experimental evaluation is designed as a systematic investigation into the core claims of the paper: that selective memory outperforms both no-memory and full-history baselines, that the zero-token data refresh mechanism is effective, and that the architecture generalizes across different datasets and use cases. The evaluation comprises four studies: a controlled ablation comparing memory conditions, a public dataset replication for reproducibility, a token efficiency analysis, and a user study. Together, these experiments build a compelling case for the architecture's effectiveness.

All experiments use the deployed system described in the implementation section, with the agentic engine using Claude Opus 4 for primary artifact generation and Claude Sonnet 4 for lightweight subtasks. The evaluation corpus consists of 24 real enterprise data files spanning supply chain operations, sales reporting, and process metrics, with sizes ranging from 200 rows / 8 columns to 45K rows / 42 columns. Data is ingested via CSV upload and SQL connectors. Each experimental task requires generating an interactive artifact from a structured data source with specific formatting requirements (color thresholds, layout preferences, summary cards). Tasks are drawn from three use case families: recurring artifact refresh (10 tasks), cross-team workspace adaptation (8 tasks), and iterative artifact construction (6 tasks). Two task types are defined: initial generation (first artifact from a new data source) and recurring generation (same task structure, new data). Each artifact is evaluated by two blinded raters on four pass/fail criteria: render correctness, data fidelity (spot-checked against source), format compliance, and completeness. A task passes only if both raters score pass on all four, with inter-rater agreement (κ) of 0.91 indicating high reliability.

The first experiment is the critical memory condition ablation, comparing three conditions across 24 recurring generation tasks: no memory (default prompt, full re-specification), full history (complete prior session transcript injected), and shared selective memory (four structured categories plus artifact, traces discarded). The results are striking and counterintuitive. Selective memory achieves 96% completion with 1.4 user turns, compared to 79% completion with 4.3 turns for no-memory and 71% completion with 3.1 turns for full history. Full history is worse than no-memory despite 9 times more input tokens—consistent with the "lost in the middle" effect. The table below summarizes these results:

Metric No Memory Full History Selective Memory
Input tokens (K) 2.1 18.7 3.4
Output tokens (K) 8.2 9.6 4.1
User turns 4.3 3.1 1.4
Completion (%) 79 71 96
Time (sec) 285 310 68

The magnitude of the differences is remarkable. Selective memory achieves a 4-fold reduction in wall-clock time compared to no-memory and a 4.5-fold reduction compared to full history. The token efficiency is equally impressive: selective memory uses 3.4K input tokens compared to 18.7K for full history, while output tokens drop by 50% (4.1K vs. 8.2K). The fact that full history not only fails to improve but actually degrades performance is a profound finding that challenges the prevailing assumption that more context is always better. The authors attribute this to "trace anchoring"—the phenomenon where the agent becomes fixated on previously explored solution paths, leading to stale and inappropriate tool-use patterns. Fisher's exact test shows selective vs. no-memory p=0.046 and selective vs. full history p=0.008, indicating statistical significance despite the relatively small sample size. The single selective-memory failure involved cross-file join semantics missed by the schema summary, pointing to a specific area for improvement. No-memory failures (5 of 24) were dominated by format non-compliance, while full-history failures (7 of 24) were dominated by trace anchoring, confirming the theoretical prediction that full history introduces harmful biases.

The second experiment validates generalizability and reproducibility by replicating the ablation and token efficiency experiments on four publicly available datasets spanning diverse domains: Superstore Sales (1K rows, 10 cols, retail), UCI Adult Income (32K rows, 15 cols, census), NYC 311 Service Requests (2K rows, 5 cols, government), and World Bank GDP (14K rows, 4 cols, economics). For each dataset, three conditions are run with three runs each (36 total trials). The results confirm the enterprise findings: shared selective memory achieves 100% task completion with zero LLM tokens across all 12 selective-memory trials—the zero-token data refresh succeeded for every dataset, as the V2 data (same schema, different values) was schema-compatible with the original artifact. No-memory completion was 83%, with failures on the UCI Adult dataset (complex categorical distributions led to incorrect binning) and NYC 311 (the agent missed a requested temporal breakdown). Full history degraded to 75%—consistent with enterprise results—with trace anchoring causing stale tool-use patterns on 3 of 12 trials. Full history was also 33% slower than no memory (112s vs. 84s), confirming that the performance degradation is not merely a completion rate issue but also a latency issue. The table below summarizes these results:

Metric No Memory Full History Selective Memory
Input tokens (K) 2.6 15.4 0.0
Output tokens (K) 6.8 7.9 0.0
Completion (%) 83 75 100
Time (sec) 84 112 0
Tool calls 4.2 5.1 0.0

The third experiment quantifies token efficiency by comparing three data representation strategies: raw data injected verbatim, truncated data (first 50 rows), and summary-driven (statistical profile from summarize_data()). The results demonstrate that summary-driven generation achieves a 97-fold token reduction on enterprise data (0.5K vs. 48.7K) and a 946-fold reduction on public datasets (0.5K vs. 473K). The savings scale with data size: for the UCI Adult dataset (32K rows), the reduction exceeds 1700-fold. Truncation achieves lower token counts but sacrifices tail distributions and rare categories, leading to errors in 5 of 24 enterprise tasks. The consistency of the sub-1K summary size regardless of dataset size is a key finding: the summary-driven approach is not merely a compression technique but a principled information extraction strategy that preserves the statistical information needed for correct code generation while discarding the redundant data values. The table below shows the data representation tokens by strategy:

Data Size Raw Truncated Summary
Small (<1K rows) 3.2K 1.8K 0.4K
Medium (1–10K) 28.5K 1.9K 0.5K
Large (>10K) 142.3K 2.0K 0.6K
Mean (enterprise) 48.7K 1.9K 0.5K
Mean (public) 473.0K 1.5K 0.5K

The fourth experiment is a user study with 12 participants (6 engineers, 6 analysts) across four counterbalanced tasks. Recurring generation was 14 times faster with shared selective memory (12s vs. 165s), refinement was 2.5 times faster, and constrained generation was 3 times faster. All Likert dimensions favored selective memory, with the largest gap on "would use again" (6.5 vs. 4.2 / 7). Participants used revert 1.8 times per session on average, validating the utility of the git-backed versioning with draft isolation. The user study, while limited by its small sample size, provides important qualitative validation that the quantitative improvements translate into real user experience benefits.

The overall summary of findings across all four experiments is compelling. Selective forgetting improves completion rate by 25 percentage points versus full history. Zero-token refresh succeeds on 12 of 12 public data trials with zero LLM tokens. Summary-driven generation achieves 97 to 946-fold token reduction versus raw injection. Specification memory reduces turns by 3-fold and output tokens by 50%. Git versioning and revert enable risk-free exploration and restore to any prior state. Context transfer allows one workspace to scale to any number of users. These gains are not incremental improvements but represent a qualitative shift in how agentic systems can be deployed in enterprise settings.


案例研究 (Case Studies)

The paper provides a detailed appendix example that illustrates how a composed system prompt is constructed from selective memory at session start. This example is worth examining closely because it reveals the practical mechanics of the memory architecture and demonstrates how the four categories interact to produce a fully contextualized generation context.

Consider a user requesting: "Generate a supply chain operations dashboard." The base system prompt (sbase) contains domain-agnostic generation instructions—data architecture rules, output size constraints, and code patterns. It includes critical constraints such as: "Data is provided via a runtime injection point—parse dynamically, never hardcode" and "ALL aggregation, filtering, totals computed from parsed data at runtime" and "Guard against NaN/undefined in all numeric operations: always coerce with fallback to 0." These base instructions establish the fundamental data-injection contract and runtime safety requirements that apply across all artifacts in the workspace.

The task specifications (Mtask) are appended as user-authored "Additional Instructions." These include domain-specific rules like: "Always use gate-based color coding: Supply=#3B82F6, Orders=#F97316, Process=#8B5CF6, Exec=#10B981" and "Include executive summary cards with KPIs" and "Use dark theme (#1a1a2e background)" and "Format percentages to 1 decimal place" and "Show attainment >= 95% in green, < 80% red." These specifications encode the visual and formatting conventions that the user has refined over multiple sessions, ensuring consistency across artifacts without requiring re-specification each time.

The tool configurations (Mtools) are appended with per-tool invocation templates. For example, the "File a Bug" tool is described with its parameter schema (title, component, description) and invocation pattern (curl POST to /api/tools/execute with JSON payload). The "Search Knowledge Base" tool is similarly documented with its parameters (query, limit) and invocation pattern. These configurations enable the LLM to correctly invoke external tools without needing to discover their schemas each session, reducing both token consumption and error rates.

The data schema (Mdata) is injected into the user message alongside the query. For a 450-row, 28-column weekly operations CSV, the schema includes: column names (LOB, Gate, ExecToGo, Shipped, Target, Attainment, Region, Week, etc.); numeric column summaries (count, mean, std, min, max for 12 numeric columns); categorical column unique values (LOB: Product A, Product B, Product C, Services, Product D; Gate: Supply, Orders, Process, Exec; Region: Americas, EMEA, APAC, Japan); and sample rows. This compact representation captures all the information needed for correct code generation in approximately 500 tokens, compared to the tens of thousands of tokens that would be required for raw data injection.

The output constraints (Moutput) are embedded in the base system prompt and include the critical data-injection contract: "Generated scripts must consume data exclusively from the runtime injection point. Never embed data values in source." Additional constraints include output size limits ("Keep output under 50KB") and rendering patterns ("Use JS functions to render tables and charts—never write repetitive markup for each row"). These constraints ensure that the generated artifact is both correct and maintainable, with the data-injection contract enabling the zero-token refresh mechanism.

This example reveals several important insights about the method's strengths and potential weaknesses. The composition is clean and modular, with each category serving a distinct and well-defined purpose. The separation between system prompt (task specifications, tool configurations, output constraints) and user message (data schema, query) follows best practices for LLM prompt engineering, ensuring that the model's system instructions are clearly separated from the user's input. The data schema is remarkably compact, yet it contains sufficient information for correct code generation. However, the example also hints at a potential limitation: the cross-file join semantics that caused the single selective-memory failure in the ablation study would not be visible in this single-table schema, suggesting that more complex multi-table relationships may require richer schema representations than the current statistical summary approach provides.

The user study's use of revert 1.8 times per session on average is another illuminating case. It demonstrates that the git-backed versioning with draft isolation is not merely a technical feature but an actively used user affordance. Participants are exploring refinements risk-free, trying variations, and reverting when they don't work—behavior that is enabled by the system's architecture but would be prohibitively expensive if each revert required re-invoking the LLM. This case study of user behavior validates the design choice to invest in versioning infrastructure rather than relying solely on LLM re-generation for exploration.


综合价值与局限 (Synthesis — Value and Limitations)

The theoretical significance of this work lies in its principled reconceptualization of memory in agentic systems. Rather than treating memory as a passive accumulation of context that grows with each session, the authors propose an active curation model that identifies and retains only the information that is both reusable and beneficial across sessions. This is a shift from "more context is better" to "better context is better"—a subtle but profound change that aligns with the growing recognition in the field that LLM performance is not merely a function of model capability but of context quality. The four-category decomposition provides a new conceptual tool for thinking about what constitutes "reusable knowledge" in agentic systems, and the distinction between workspace memory (user-authored, shared, declarative) and agent memory (learned, private, procedural) opens up a new dimension of analysis for memory architectures.

The practical impact is substantial for enterprise settings where users repeatedly perform structurally similar tasks. The 14-fold reduction in task time for recurring updates, the 97-fold reduction in data representation tokens, and the 4-fold reduction in user turns represent not merely incremental improvements but a qualitative change in how agentic systems can be deployed. The collaborative workspace model enables a new mode of interaction: knowledge workers can create, share, and adapt workspaces without the friction of redundant specification. The role-based access control ensures that this sharing is governed by appropriate permissions, while the git-backed versioning provides the audit trail and recovery capabilities that enterprise users require.

The paper's strengths are numerous. The empirical design is rigorous, with a controlled ablation, public dataset replication, token efficiency analysis, and user study providing converging evidence for the core claims. The finding that full history persistence is actively counterproductive is a genuine surprise that challenges prevailing assumptions and provides a strong empirical foundation for the selective memory approach. The implementation is well-described, with sufficient detail to enable replication and adaptation. The writing is clear and well-structured, with a compelling narrative arc that moves from problem identification to solution design to empirical validation.

The limitations are also worth considering honestly. The current memory decomposition is manually designed; while it generalizes across the artifact types evaluated (dashboards, reports, documents), automatically identifying which context elements are reusable across sessions and artifact types remains an open problem. The zero-token data architecture is limited to structured tabular data with stable schemas; extending to streaming data, unstructured documents, or real-time API responses would require richer schema compatibility checking. The multi-connector layer supports CSV, SQL, REST, and MCP sources, but each connector type introduces its own failure modes (connection timeouts, authentication expiry, schema drift) that are handled independently rather than through a unified retry strategy. The four-criterion rubric captures functional correctness and format compliance but does not assess subjective qualities such as visual aesthetics or information hierarchy. The user study (N = 12) is sufficient for identifying trends but underpowered for statistical significance testing on individual Likert items. Collaboration is workspace-level; finer-grained sharing of individual memory components (e.g., sharing tool configurations without task specifications) is not yet supported.

These limitations suggest that the paper is best understood as a foundational contribution that establishes a paradigm rather than a complete solution. The architecture is sound, the empirical results are compelling, and the implementation is practical, but there is significant room for extension and refinement. The honest discussion of limitations in the paper itself is commendable and provides a clear roadmap for future work.

The broader implications of this work connect to several trends in the field. The shift from ephemeral, single-user sessions to persistent, collaborative workspaces parallels the evolution of software development from individual scripts to version-controlled repositories. The emphasis on context quality over context quantity aligns with the growing recognition that LLM performance is as much a function of prompt engineering and context management as of model capability. The zero-token data refresh mechanism represents a new paradigm for data-driven applications where the model is invoked once to generate the program and subsequent data changes are handled by the runtime. This decoupling of generation from execution is a significant architectural advance that could influence the design of future agentic systems.


延伸阅读与思考 (Further Reading and Reflection)

This work builds upon several important prior contributions that together form the intellectual foundation for selective persistent memory. The "lost in the middle" finding by Liu et al. (2024) is the most direct predecessor, establishing that irrelevant context degrades LLM performance. Retrieval-augmented generation (Lewis et al., 2020) provides the conceptual framework for augmenting LLM prompts with external knowledge, though the paper's approach operates at a finer configuration-level granularity. Voyager (Wang et al., 2023) is the closest prior work in the agentic domain, introducing a persistent skill library for embodied agents, but it persists executable skills rather than declarative configuration. MemGPT (Packer et al., 2023) provides an OS-inspired memory hierarchy focused on conversational continuity, while Generative Agents (Park et al., 2023) maintain memory streams optimized for narrative coherence. Neither addresses the specific problem of selective context persistence across agentic sessions. The ReAct framework (Yao et al., 2023) established the interleaved reasoning and tool-use paradigm that this paper builds upon, and the chain-of-thought prompting work (Wei et al., 2022) provides the foundational insight that structured reasoning traces improve generation quality—though the paper turns this insight on its head by arguing that such traces should be discarded across sessions.

Alternative approaches to the same problem exist at several levels. Long-context LLMs (Press et al., 2022; Chen et al., 2023) increase the token budget without addressing what to persist, making them complementary rather than competing approaches. Conversation summarization (Xu et al., 2023) compresses prior turns but retains session-specific reasoning traces, falling into the same trap that this paper identifies. The OpenAI Assistants API (OpenAI, 2023a) provides thread-level persistence but retains full conversation threads rather than selectively extracting reusable configuration. Traditional BI platforms provide persistent dashboards but require domain-specific query languages rather than natural language, and they do not offer the agentic generation capabilities that make this paper's approach distinctive. LLM-powered code generation tools (GitHub, 2021; Anthropic, 2025b; Cursor, 2024) are single-user and ephemeral, lacking the collaborative and persistent features that this paper introduces.

The future directions identified by the authors are promising. Learned memory selection—training a classifier to automatically identify reusable context from session traces—would move beyond the manual decomposition that is the current limitation. Memory composition, merging selective memory from multiple workspaces to create richer contexts, would enable cross-domain knowledge transfer. Memory decay, aging out specifications that have not been validated against recent sessions, would prevent stale context accumulation. Agent-level persistent memory, extending memory beyond workspace configuration to the agent's own reasoning capabilities, would capture tool-use patterns, error recovery heuristics, and user preference models. Each of these directions represents a substantial research program that could build upon the foundation established by this paper.

The deepest unsolved challenges in this area relate to the dynamic nature of context. How do we automatically identify which elements of a session are reusable? How do we merge selective memory from different workspaces without introducing conflicts? How do we prevent stale context from accumulating while preserving valuable institutional knowledge? How do we extend the data-injection contract to unstructured data, streaming sources, and real-time APIs? These questions are not merely technical but touch on fundamental questions about how knowledge is organized, shared, and maintained in collaborative systems.

The most surprising and thought-provoking aspect of this work is the counterintuitive finding that full history persistence is worse than no memory at all. This challenges a deeply held assumption in the field that more context is always better, and it establishes that the quality of context matters more than the quantity. The cognitive science parallel—declarative vs. procedural memory—is a powerful framing that suggests the paper's insights may generalize beyond agentic systems to other domains where context management is important. What I would want to explore further is the automatic learning of memory categories: can we train a model to identify which context elements are reusable, rather than relying on the manually designed four-category decomposition? This would be a significant step toward truly autonomous agentic systems that manage their own memory without human-designed rules.

Another direction worth exploring is the extension of the zero-token data refresh mechanism to non-tabular data. The current architecture is limited to structured data with stable schemas, but many real-world applications involve unstructured documents, images, and real-time streams. Extending the data-injection contract to these domains would require richer schema compatibility checking and more flexible runtime injection mechanisms, but the potential payoff is substantial: a general framework for decoupling generation from data would enable a new class of adaptive applications that can respond to changing data without re-generation.

Finally, the collaborative aspects of this architecture raise interesting questions about the social dynamics of knowledge sharing. The workspace model with role-based access control enables collaborative reuse of accumulated context, but the granularity of sharing (workspace-level) may not capture the nuanced sharing requirements of complex enterprise workflows. Finer-grained sharing of individual memory components would enable more flexible collaboration models, but it would also introduce new challenges in managing conflicts and ensuring consistency. The trade-off between collaboration flexibility and system integrity is a rich area for future research.

This paper makes a compelling case that context management, not model capability, is the primary lever for improving agentic LLM efficiency in enterprise settings. By providing a principled framework for selective memory, the authors have opened a new research direction that is likely to influence the design of future agentic systems. The work is both theoretically sound and practically impactful, and it establishes a foundation upon which significant future advances can be built.

Powered by Forestry.md