ConceptioArchivearXiv CS
arXiv CSopen access

Shared Selective Persistent Memory for Agentic LLM Systems

Unknown · 2026 · arxiv_cs
arXiv CS · Papers · License: Open Access · 2026
Open Source ↗Direct PDF ↓
artificialintelligenceknowledgerepresentationreasoning
artificial intelligence, reasoning, knowledge representation

Shared Selective Persistent Memory for Agentic LLM Systems Sanjana Pedada Apple Inc. [email protected]

Aditya Dhavala Apple Inc. [email protected]

arXiv:2607.09493v1 [cs.AI] 10 Jul 2026

Abstract

Neelraj Patil Apple Inc. [email protected]

invocation token cost by 97× versus raw data injection. A replication on four public datasets confirms generalizability, with zero-token refresh succeeding in 12/12 trials. Notably, naive full-history persistence actively degrades task completion by biasing the agent with stale reasoning traces, while selective memory outperforms both extremes.

Agentic LLM systems that generate code through multi-turn tool use face a fundamental context problem: each session starts from zero, discarding the configuration choices, domain constraints, data schemas, and tooluse patterns that made previous sessions productive. Naively persisting entire conversation histories is both token-inefficient and counterproductive—irrelevant context degrades generation quality. We introduce shared selective persistent memory, a memory architecture for agentic systems that identifies and retains four categories of reusable context—task specifications, data schemas, tool configurations, and output constraints—while discarding session-specific reasoning traces. Crucially, this memory is shared: workspaces encapsulating selective memory can be transferred across users with role-based access control, enabling collaborative reuse of accumulated context without redundant specification. We implement this architecture in a deployed collaborative workspace platform where LLM agents produce, edit, and maintain git-versioned artifacts—including interactive dashboards, structured reports, and datadriven documents—from heterogeneous data sources accessed via multiple connector types (CSV upload, SQL, REST APIs, and MCP servers). Git-backed versioning with draft isolation enables users to explore modifications risk-free and restore to any prior state without re-invoking the model. A complementary zero-token data refresh mechanism decouples generated programs from runtime data, enabling artifact reuse without re-invocation. Across three enterprise deployment scenarios, shared selective persistent memory achieves 96% task completion (vs. 79% without memory and 71% with full history). A complementary zero-token data refresh mechanism eliminates LLM re-invocation entirely for recurring data updates (14× task time reduction), while summary-driven generation reduces per-

1

Introduction

Agentic LLM systems—those that autonomously invoke tools, write files, and execute code to accomplish user goals—have demonstrated impressive capabilities in code generation (GitHub, 2021; Anthropic, 2025b), data analysis (OpenAI, 2023b), and multi-step reasoning (Wu et al., 2023). Yet a fundamental limitation persists across all current agentic frameworks: sessions are stateless. When a conversation ends, the accumulated context— domain constraints, data schemas, tool configurations, prompt refinements, and output format preferences—is discarded entirely. This is wasteful. In enterprise workflows, users repeatedly perform structurally similar tasks: generating weekly dashboards from updated data exports, producing reports with consistent formatting, querying the same internal tools with the same authentication patterns, drafting documents from evolving data sources, and maintaining versioned artifacts across teams. Each session forces the user to re-specify what the system should already know. The problem is not that LLMs lack memory, but that existing systems provide no mechanism to selectively persist the context that matters while discarding the session-specific reasoning that does not. The naive solution—persisting entire conversation histories—is counterproductive. Prior work on long-context LLMs (Liu et al., 2024) demonstrates that irrelevant context degrades output quality (the “lost in the middle” phenomenon). For agentic sys1

1. A shared selective persistent memory architecture that identifies four categories of reusable agentic context, persists them independently of session traces, and includes a zero-token data refresh mechanism that decouples generated programs from runtime data (Section 3).

tems, the problem is compounded: a prior session’s tool-use trace (file reads, shell commands, error recovery) is not just irrelevant but actively harmful when injected into a new session, as it biases the agent toward previously explored solution paths rather than the current task. We propose shared selective persistent memory, a memory architecture for agentic LLM systems built on a key observation: the reusable knowledge from an agentic session can be decomposed into four orthogonal categories, each of which is compact, stable across sessions, and beneficial when persisted:

2. A collaborative workspace platform with git-versioned artifacts, draft isolation, multiconnector data integration (CSV, SQL, REST, MCP), and AI-assisted editing and querying modes (Section 4). 3. Deployment case studies across three enterprise scenarios demonstrating that shared selective memory reduces redundant specification, enables workspace reuse, and supports zero-token data refresh (Section 6).

1. Task specifications — custom system prompts that encode domain rules, output format constraints, and generation preferences (e.g., “always use green for ≥95% attainment”).

1.1

2. Data schemas — column names, types, statistical summaries, and relationships across data sources, precomputed from raw data.

Motivating Use Cases

We ground our architecture in three enterprise scenarios. (1) Recurring refresh: An analyst generates a supply chain dashboard weekly; 8–12 formatting constraints must be re-specified each session (4–5 turns). With selective memory, specifications persist and zero-token data swap enables one-click refresh regardless of source type. (2) Cross-team sharing: A director publishes a revenue workspace as a versioned template; a counterpart loads it, connects schema-compatible data, and the artifact renders immediately under role-based access control. (3) Iterative construction: A team builds a workspace across sessions, each adding components. Selective memory carries forward accumulated specifications; draft isolation protects the published version, and git-backed revert enables the team to restore any prior artifact state without reinvoking the model. Session time drops from ∼20 to ∼5 minutes.

3. Tool configurations — which external tools are available, their parameter schemas, invocation patterns, and authentication requirements. 4. Output constraints — structural contracts between the generated artifact and its runtime environment (e.g., “data is injected at runtime, never hardcoded”). Crucially, what we discard is equally important: the multi-turn reasoning trace, tool invocation logs, intermediate file states, and error-recovery paths from prior sessions. These are useful within a session but harmful across sessions. We validate this architecture in a deployed enterprise collaborative workspace platform, where LLM agents produce, edit, and maintain gitversioned artifacts—including interactive dashboards, structured reports, and data-driven documents—from heterogeneous data sources accessed via multiple connector types (CSV upload, SQL databases, REST APIs, and MCP servers). Git-backed versioning with draft isolation allows users to explore refinements risk-free and restore to any prior artifact state without re-invoking the model. A complementary zero-token data refresh mechanism enforces strict separation between the LLM-generated program and runtime-bound data, enabling data refresh with zero LLM tokens. Our contributions are:

2

Related Work

Memory in LLM Systems. Context window extension (Press et al., 2022; Chen et al., 2023) increases the token budget without addressing what to persist. RAG (Lewis et al., 2020) retrieves at the document level, not the structured configuration level agentic systems require. Conversation summarization (Xu et al., 2023) compresses prior turns but retains session-specific reasoning traces. MemGPT (Packer et al., 2023) provides an OSinspired memory hierarchy focused on conversational continuity. Generative Agents (Park et al., 2

Selective Memory (per workspace)

2023) maintain memory streams optimized for narrative coherence. Reflexion (Shinn et al., 2023) persists failure summaries for within-task trial-anderror learning. Our approach identifies four structured categories to persist across sessions and explicitly discards reasoning traces.

User A

Agentic LLM Frameworks. ReAct (Yao et al., 2023) established interleaved reasoning and tooluse actions, building on chain-of-thought prompting (Wei et al., 2022). LangChain (Chase, 2022), AutoGen (Wu et al., 2023), and CrewAI (CrewAI, 2024) provide multi-agent orchestration. LATS (Zhou et al., 2023) unifies reasoning, acting, and planning via tree search. Voyager (Wang et al., 2023) introduces a persistent skill library for embodied agents—the closest prior work, though it persists executable skills rather than declarative configuration. None of these frameworks persist task specifications, tool configurations, or output constraints across sessions.

Workspace 1

Moutput

Mtask

Mdata

share

collab

share

User B

Workspace 2

collab

User N

Workspace N

artifact Agentic Engine calls

data

fetch

Tool Integration

Data Layer

MCP | SQL | REST | CSV

Connectors | Persistence

Figure 1: System architecture. Multiple users each own independent workspaces that can be shared for collaboration with role-based access control. Each workspace persists four categories of selective memory (top). The agentic engine composes workspace memory into session prompts; the zero-token data architecture decouples generated artifacts from runtime data. Data is accessed via heterogeneous connectors (CSV, SQL, REST, MCP).

Tool-Augmented LLMs. Toolformer (Schick et al., 2023) demonstrated autonomous tool learning; Gorilla (Patil et al., 2023) improved API call accuracy; MCP (Anthropic, 2024) standardizes tool discovery. The OpenAI Assistants API (OpenAI, 2023a) provides thread-level persistence but retains full conversation threads rather than selectively extracting reusable configuration. LLM-powered code generation tools (GitHub, 2021; Anthropic, 2025b; Cursor, 2024) and code interpreters (OpenAI, 2023b) are single-user and ephemeral. Traditional BI platforms provide persistent dashboards but require domain-specific query languages rather than natural language.

3

Mtools

3.1

Problem Formulation

Consider an agentic LLM system that, given a user query q and system prompt s, produces an artifact a through a sequence of tool-use steps T = (t1 , t2 , . . . , tn ). In current systems, the complete session state S = (s, q, T, a) is discarded after the session ends. When the user returns for a related task q ′ , they must re-specify all implicit knowledge: the domain constraints encoded in s, the data schema assumptions in q, the tool configurations invoked during T , and the output format contracts in a. We observe that this re-specification is both the primary source of user friction and the primary source of wasted tokens.

Shared Selective Persistent Memory

Figure 1 presents the end-to-end architecture. 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, with external data accessed via a multi-connector integration layer (CSV, SQL, REST, MCP). Generated artifacts consume data exclusively through a runtime injection contract (Section 3.5), and the workspace captures only the four structured memory categories— never the session trace.

3.2

Memory Decomposition

We decompose the reusable knowledge from a session into four categories: Task Specifications (Mtask ). Custom instructions that extend the base system prompt. These encode domain rules (“use gate-based color coding: Supply blue, Orders orange, Process purple”), output preferences (“always include an executive summary card”), and quality constraints (“guard against NaN in all numeric operations”). Task spec3

• Reasoning traces: The LLM’s intermediate chain-of-thought and planning steps, which reflect session-specific problem decomposition.

ifications are authored by users and refined over multiple sessions. Data Schemas (Mdata ). Precomputed summaries of associated data sources: column names and types, statistical distributions for numeric columns, unique value catalogs for categorical columns, row counts, and sample rows. These are generated automatically from uploaded data via statistical profiling (we use pandas.describe() with extensions for categorical analysis; for large datasets, profiling operates on columnar statistics in constant memory regardless of row count). Data schemas provide the LLM with sufficient information to generate correct data-processing code without reading raw data—reducing prompt tokens while improving generation accuracy through structured metadata.

• Tool invocation logs: The specific file reads, writes, and shell commands executed during generation, which reflect one solution path among many. • Error recovery paths: Failed tool calls, retries, and workarounds, which are artifacts of a specific session’s execution. • Raw data: The complete source data, which is replaced by compact schema summaries. This selective forgetting is motivated by the “lost in the middle” finding (Liu et al., 2024): injecting irrelevant context into LLM prompts degrades performance. 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.

Tool Configurations (Mtools ). The set of available external tools and data connectors with their parameter schemas, invocation patterns (REST endpoint, MCP server, SQL connection, sub-agent delegation), and authentication requirements. In enterprise settings, tool availability, connector configurations, and auth context are stable across sessions but expensive to discover and configure from scratch.

3.4

When a new session begins, the system prompt is composed from persistent memory: s′ = sbase ⊕ Mtask ⊕ Mtools ⊕ Moutput ,

(1)

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

Output Constraints (Moutput ). Structural contracts between the generated artifact and its runtime environment. The critical constraint is the data-injection contract: generated scripts must consume data exclusively from a well-defined runtime injection point, never from hardcoded values. This constraint enables zero-token data refresh (Section 3.5). 3.3

Memory Composition at Session Start

q ′ = q ⊕ Mdata .

(2)

This composition is performed at the application layer before the LLM is invoked. The LLM receives a fully contextualized prompt without any awareness of the persistence mechanism.

Selective Forgetting

Equally important is what we do not persist. Given a session trace T = (t1 , t2 , . . . , tn ), we discard:

3.5

Zero-Token Data Refresh

A complementary mechanism to selective memory is the data-injection contract: generated artifacts must consume data exclusively from a 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. When new data arrives (from any connector type), the system checks schema compatibility: the

• Intermediate temporary files: Working files created during generation (partial drafts, intermediate versions, scratch computations) that are artifacts of one execution path. • Unapproved changes: Modifications the user explored but did not explicitly save. The undo stack (Section 5) allows users to try refinements risk-free; only changes the user accepts are persisted. 4

5

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).

4

Implementation

We implement shared selective persistent memory in a deployed collaborative workspace platform consisting of a FastAPI backend, an agentic LLM engine, a multi-connector data layer, and a conversational frontend.

Collaborative Memory Sharing

Agentic Loop. Each user turn initializes a fresh session with the composed system prompt (Equation 1) and data summary (Equation 2). The agent uses Claude Opus 4 (Anthropic, 2025c) via the Claude Agent SDK (Anthropic, 2025a) with autonomous tool use (file I/O, code search, shell execution), 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.

A workspace W encapsulates the full selective memory state: W = (Mtask , Mdata , Mtools , Moutput , a, V ), (3) where a is the most recent generated artifact and V is its version history. The workspace stores structured configuration, generated code, and version metadata, never conversational transcripts, reasoning traces, or tool invocation logs. A saved workspace is a curated artifact store, not a chat history. The sharing workflow exploits the zero-token data architecture:

Data Integration. A unified connector interface abstracts four source types—CSV upload, SQL databases, REST APIs, and MCP servers (JSONRPC with mTLS)—into a normalized tabular representation. Rather than injecting raw data into the LLM prompt, the system precomputes a compact statistical profile (column types, distributions, categorical catalogs, sample rows) that captures the information needed for correct code generation in ∼500 tokens—a 100× reduction over raw injection for typical enterprise datasets.

1. Load: A colleague loads the shared workspace, restoring all selective memory into their session. Draft isolation ensures their edits do not affect the published artifact. 2. Swap: 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—zero tokens.

Persistence and Versioning. Workspace metadata—the four memory categories, access control lists, and data source configurations—is persisted to MongoDB. Generated artifacts and their version history are managed through git, providing full version control with diff, branch, and rollback capabilities. No conversation history or reasoning traces are stored in either layer. 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.

3. Refine: They ask refinement questions within the established context (e.g., “add a trend chart”). The LLM benefits from the persisted task specifications and tool configurations without re-specification. 4. Query: 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.

Save and Revert. An in-session undo stack (up to 10 snapshots) enables risk-free exploration— users can revert to any prior version without reinvoking the model. Only explicitly saved changes persist, reinforcing selective forgetting.

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.

6

Evaluation

We evaluate shared selective persistent memory through four studies: a controlled ablation compar5

ing memory conditions, a public dataset replication for reproducibility, a token efficiency analysis, and a user study. 6.1

Metric Input tokens (K) Output tokens (K) User turns Completion (%) Time (sec)

Experimental Setup

All experiments use the deployed system described in Section 5. The agentic engine uses Claude Opus 4 (Anthropic, 2025c) for primary artifact generation and Claude Sonnet 4 for lightweight subtasks (schema validation, tool dispatch). We evaluate on a corpus 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.

Full Hist.

Selective

2.1 8.2 4.3 79 285

18.7 9.6 3.1 71 310

3.4 4.1 1.4 96 68

Table 1: Ablation results across 24 recurring artifact generation tasks (means). Shared selective memory achieves the highest completion rate with the fewest tokens and turns. Full history increases input tokens 9× over no-memory but decreases completion rate.

gap (100% vs. 70% / 60%); cross-team adaptation (UC2, n = 8) achieved 100% vs. 88% / 75%; iterative construction (UC3, n = 6) showed equal completion (83%) but selective memory halved the turns (2.8 vs. 6.2). Output tokens drop 50% (4.1K vs. 8.2K) and wall-clock time drops from 285s to 68s. For the 18/24 tasks with compatible schemas, zero-token refresh succeeded with zero LLM invocation.

Task definition. 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 the three use case families described in Section 1.1: 10 tasks model recurring artifact refresh (Use Case 1), 8 tasks model cross-team workspace adaptation (Use Case 2), and 6 tasks model iterative artifact construction (Use Case 3). We define two task types: initial generation (first artifact from a new data source) and recurring generation (same task structure, new data). 6.2

No Mem.

Significance and Failures. Fisher’s exact test: selective vs. no-memory p = 0.046; selective vs. full history p = 0.008. The single selectivememory failure involved cross-file join semantics missed by the schema summary. No-memory failures (5/24) were format non-compliance; fullhistory failures (7/24) were dominated by trace anchoring.

Experiment 1: Memory Condition Ablation

6.3 Experiment 2: Public Dataset Replication To validate generalizability and enable reproducibility, we replicate 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).

We compare 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). Protocol. Each artifact was evaluated by two blinded raters on four pass/fail criteria: render correctness, data fidelity (spot-checked against source), format compliance, and completeness. A task passed only if both raters scored pass on all four (κ = 0.91).

Protocol. For each dataset, we run three conditions (no memory, full history, shared selective memory) with 3 runs each (36 total trials). Artifact completion is validated by automated checks: presence of scripts, use of the data-injection contract, absence of hardcoded data, and dataset-specific content verification. Token counts are estimated via the cl100k_base tokenizer.

Results (Table 1). Selective memory achieves 96% completion / 1.4 turns, vs. 79% / 4.3 for nomemory and 71% / 3.1 for full history. Full history is worse than no-memory despite 9× more input tokens—consistent with the “lost in the middle” effect (Liu et al., 2024). By use case: recurring refresh (UC1, n = 10) showed the largest

Results (Table 2). Shared selective memory achieved 100% task completion with zero LLM tokens across all 12 selective-memory trials—the 6

Input tokens (K) Output tokens (K) Completion (%) Time (sec) Tool calls

No Mem.

Full Hist.

Selective

2.6 6.8 83 84 4.2

15.4 7.9 75 112 5.1

0.0 0.0 100 0 0.0

10,000 Raw injection 1571

245

Table 2: Public dataset ablation (means across 4 datasets, 3 runs each). Shared selective memory achieves 100% completion with zero LLM tokens via zero-token data refresh. Full history degrades completion by 8pp vs. no memory, consistent with enterprise results. Data size

Raw

Trunc.

Summary

Small (<1K rows) Medium (1–10K) Large (>10K)

3.2K 28.5K 142.3K

1.8K 1.9K 2.0K

0.4K 0.5K 0.6K

Mean (enterprise) Mean (public)

48.7K 473.0K

1.9K 1.5K

0.5K 0.5K

100

44.9

31.7

10 0.9

1

0.5 0.3

0.3

Superstore Adult Inc. NYC 311World GDP

Figure 2: Token reduction by strategy on public datasets (log scale). Raw injection scales with data size (32K– 1.6M tokens); summary-driven generation is consistently <1K.

Table 3: Data representation tokens by strategy. Summary-driven generation achieves 97× reduction on enterprise data and 946× on public datasets, with consistent sub-1K summaries regardless of dataset size.

Mechanism

Measured Effect

Selective forgetting

+25% completion rate vs. full history 12/12 on public data; 0 LLM tokens 97–946× token reduction vs. raw injection 3× fewer turns; 50% fewer output tokens Risk-free exploration; restore to any prior state One workspace scales to N users

Zero-token refresh Summary-driven gen. Specification memory

zero-token data refresh succeeded for every dataset, as the V2 data (same schema, different values) was schema-compatible with the original artifact. Nomemory 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 33% slower than no memory (112s vs. 84s). Token efficiency results on these public datasets are reported jointly in Experiment 3.1 6.4

Summary-driven

1,000 Tokens (K)

Metric

Git versioning & revert Context transfer

Table 4: Summary of efficiency gains across all four evaluation studies.

exceeds 1700×. Truncation achieves lower token counts but sacrifices tail distributions and rare categories, leading to errors in 5 of 24 enterprise tasks. 6.5

Experiment 4: User Study

A user study (N = 12; 6 engineers, 6 analysts) across four counterbalanced tasks showed recurring generation was 14× faster with shared selective memory (12s vs. 165s), refinement 2.5× faster, and constrained generation 3× 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.

Experiment 3: Token Efficiency

We measure the token cost of data representation comparing three strategies: (1) raw data injected verbatim, (2) truncated data (first 50 rows), and (3) summary-driven (statistical profile from summarize_data()). Results (Table 3). Summary-driven generation consumes a mean of 0.5K tokens compared to 48.7K for raw injection on enterprise data (97× reduction) and 473K on public datasets (946× reduction). The savings scale with data size: for the UCI Adult dataset (32K rows), the reduction

6.6

Summary of Findings

The key finding is that full history persistence is counterproductive: it degrades both completion rate and generation time relative to no memory. Selective memory outperforms both extremes by persisting high-relevance context and discarding

1

Datasets: UCI ML Repository (Adult), NYC Open Data (311), Frictionless Data (GDP).

7

low-relevance traces.

7

session LLM interactions into persistent, collaborative, and reusable workspaces. Our results suggest that context management, not model capability, is the primary lever for improving agentic LLM efficiency in enterprise settings.

Discussion and Conclusion

The ablation results reveal that full history persistence is not merely unhelpful but counterproductive—reducing task completion by 8 percentage points relative to no memory. This parallels the distinction between declarative and procedural memory in cognitive science: persisting the “what” (specifications, schemas) while discarding the “how” (execution traces) yields better results than persisting everything or nothing. The benefit is strongest for recurring refresh tasks (zero-token data swap) and cross-team adaptation (persisted specifications prevent redundant prompt engineering), while iterative construction tasks see substantial turn reduction even when completion rates are comparable. The memory decomposition—task specifications, data schemas, tool configurations, output constraints—is not specific to any single artifact type; it applies equally to dashboards, reports, documents, and any workspace where an LLM agent produces artifacts from structured data. Quantitatively, shared selective memory achieves 96% task completion (vs. 79% without memory and 71% with full history). The complementary zero-token data refresh mechanism— which decouples generated artifacts from runtime data—eliminates LLM re-invocation entirely for recurring data updates, reducing task time by 14× (since no model call is required). Summary-driven generation achieves 97× token reduction versus raw data injection when the model is invoked, by providing pre-computed statistical summaries rather than raw tabular data. These latter two gains are architectural—they reduce how often and how expensively the LLM is called—rather than improvements to model reasoning itself. A replication on four public datasets confirms generalizability, and a user study (N = 12) validates improved usability ratings and reduced task completion times. Git-backed versioning and revert mechanisms provide user agency over the memory lifecycle—enabling risk-free exploration and restoration to any prior artifact state without re-invoking the model. Combined with a multi-connector integration layer (CSV, SQL, REST, MCP), git-based artifact versioning with draft isolation, and collaborative workspace mechanisms with role-based access control, shared selective memory transforms single-

Limitations 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. While the multi-connector layer supports CSV, SQL, REST, and MCP sources, 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. Our four-criterion rubric captures functional correctness and format compliance but does not assess subjective qualities such as visual aesthetics or information hierarchy. Our user study (N = 12) is sufficient for identifying trends but underpowered for statistical significance testing on individual Likert items; a larger study is warranted. Collaboration is workspace-level; finergrained sharing of individual memory components (e.g., sharing tool configurations without task specifications) is not yet supported. Future Work. Four directions are promising: (1) learned memory selection—training a classifier to automatically identify reusable context from session traces, moving beyond manual decomposition; (2) memory composition—merging selective memory from multiple workspaces to create richer contexts, enabling cross-domain knowledge transfer; (3) memory decay—aging out specifications that have not been validated against recent sessions, preventing stale context accumulation, as motivated by participant feedback in our user study; and (4) agent-level persistent memory—extending memory beyond workspace configuration to the agent’s own reasoning capabilities. Agent Memory. The current architecture persists workspace context (what to build, with what data, under what constraints) but discards agent context 8

(how it solved similar problems, which tool sequences were effective, what error patterns it encountered). A complementary agent memory layer could retain: • Tool-use patterns: Frequently successful tool sequences for common task types (e.g., “for schema changes, always Read → Grep → Edit” vs. trial-and-error). • Error recovery heuristics: When a tool invocation fails with a specific error class, the agent currently re-derives the fix from scratch each session; persisting resolution patterns would reduce repeated reasoning. • User preference models: Implicit style preferences inferred from accepted vs. reverted edits— without explicit specification in Mtask . • Cross-session planning: For multi-session tasks, persisting a high-level plan across sessions rather than re-deriving intent from artifacts alone. Unlike workspace memory (which is user-authored and shared), agent memory would be learned, private to the agent instance, and subject to validation—a correct tool-use pattern from one data domain may not transfer to another. Designing appropriate generalization boundaries, staleness detection, and conflict resolution between agent memory and explicit workspace specifications remains an open challenge. Additionally, extending the connector framework to support real-time data streams and eventdriven refresh would broaden applicability beyond batch-oriented workflows.

instructions; file system access is scoped to peruser session directories and generated artifacts are served in sandboxed browser contexts. Extensions of this architecture to domains involving personal data, user-level personalization, or sensitive content should incorporate appropriate privacy safeguards, data retention policies, and access controls beyond the workspace-level mechanisms described here.

Acknowledgements We used Claude (Anthropic) as an AI writing assistant during manuscript preparation, including drafting, editing, and LaTeX formatting. All intellectual contributions—system design, architecture decisions, implementation, experimental design, and analysis—are the authors’ own. The authors reviewed and take full responsibility for all content.

References Anthropic. 2024. Model context protocol specification. https://modelcontextprotocol.io. Anthropic. 2025a. Claude agent https://docs.anthropic.com/en/docs/ agents-and-tools/claude-agent-sdk.

SDK.

Anthropic. 2025b. Claude code: An agentic coding tool. https://docs.anthropic.com/en/docs/ claude-code. Anthropic. 2025c. The claude model family: Claude opus 4 and claude sonnet 4. https://www. anthropic.com/claude. Harrison Chase. 2022. LangChain: Building applications with LLMs through composability. https: //github.com/langchain-ai/langchain.

Ethical Considerations

Shouyuan Chen, Sherman Wong, Liangjian Chen, and Yuandong Tian. 2023. Extending context window of large language models via positional interpolation. arXiv preprint arXiv:2306.15595.

The system does not store or process personally identifiable information (PII). All persistent memory operates at the workspace level—task specifications, data schemas, tool configurations, and output constraints—none of which contain user-level personal data. The data sources used in our evaluation consist entirely of aggregated operational metrics. Personalization is scoped to workspace configuration, not to individual user profiles or behavioral tracking. The multi-connector architecture introduces additional security considerations: SQL connectors require credential management, REST connectors handle API tokens, and MCP connectors use mTLS authentication—all scoped to per-workspace configuration with no cross-workspace credential leakage. The system generates executable code from natural language

CrewAI. 2024. CrewAI: Framework for orchestrating role-playing AI agents. https://github.com/ crewAIInc/crewAI. Cursor. 2024. Cursor: The ai code editor. https:// cursor.sh. GitHub. 2021. Github copilot: Your ai pair programmer. https://github.com/features/copilot. Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, and 1 others. 2020. Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems, 33:9459–9474.

9

Nelson F Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. 2024. Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12:157–173.

Frank F Xu, Uri Alon, Graham Neubig, and Vincent Josua Hellendoorn. 2023. Beyond summarization: Designing AI support for real-world LLM interactions. arXiv preprint arXiv:2310.10893.

OpenAI. 2023a. Assistants API. https://platform. openai.com/docs/assistants. OpenAI. 2023b. Chatgpt code interpreter. https:// openai.com/blog/chatgpt-plugins.

Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing reasoning and acting in language models. International Conference on Learning Representations. Andy Zhou, Kai Yan, Michal Shlapentokh-Rothman, Haohan Wang, and Yu-Xiong Wang. 2023. Language agent tree search unifies reasoning acting and planning in language models. arXiv preprint arXiv:2310.04406.

Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G Patil, Ion Stoica, and Joseph E Gonzalez. 2023. MemGPT: Towards LLMs as operating systems. arXiv preprint arXiv:2310.08560. Joon Sung Park, Joseph C O’Brien, Carrie J Cai, Meredith Ringel Morris, Percy Liang, and Michael S Bernstein. 2023. Generative agents: Interactive simulacra of human behavior. Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology.

A

Memory Composition Example

The following illustrates how a composed system prompt is constructed from selective memory at session start. The base system prompt (sbase ) contains domain-agnostic generation instructions—data architecture rules, output size constraints, and code patterns. Task specifications (Mtask ) are appended as user-authored “Additional Instructions.” Tool configurations (Mtools ) are appended with per-tool invocation templates. The data schema (Mdata ) is injected into the user message alongside the query.

Shishir G Patil, Tianjun Zhang, Xin Wang, and Joseph E Gonzalez. 2023. Gorilla: Large language model connected with massive APIs. arXiv preprint arXiv:2305.15334. Ofir Press, Noah A Smith, and Mike Lewis. 2022. Train short, test long: Attention with linear biases enables input length generalization. International Conference on Learning Representations.

# Composed system prompt (s') ## Base system prompt (~500 tokens) # s_base You are an expert at creating interactive dashboards and data-driven artifacts from structured data sources. CRITICAL: Data Architecture - Zero-Token Refresh - Data is provided via a runtime injection point -- parse dynamically, never hardcode - ALL aggregation, filtering, totals computed from parsed data at runtime - Insight text must be generated dynamically (e.g., top performers, outliers) - Guard against NaN/undefined in all numeric operations: always coerce with fallback to 0 - Data may come from CSV, SQL, REST, or MCP connectors -- treat all sources uniformly

Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. Toolformer: Language models can teach themselves to use tools. Advances in Neural Information Processing Systems, 36. Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language agents with verbal reinforcement learning. Advances in Neural Information Processing Systems, 36.

## Additional Instructions # M_task Always use gate-based color coding: Supply=#3B82F6, Orders=#F97316, Process=#8B5CF6, Exec=#10B981 Include executive summary cards with KPIs. Use dark theme (#1a1a2e background). Format percentages to 1 decimal place. Show attainment >= 95% in green, < 80% red.

Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. 2023. Voyager: An open-ended embodied agent with large language models. arXiv preprint arXiv:2305.16291.

## Available External Tools # M_tools You can call external tools via the Bash tool.

Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc V Le, and Denny Zhou. 2022. Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems, 35:24824– 24837.

### File a Bug Description: File a bug report in the issue tracker Parameters: - title: Bug title (required) - component: Component name (required) - description: Bug description (required) To call: curl -s -X POST http://localhost:<port>/ api/tools/execute -H "Content-Type: application/json" -d '{"tool":"file_bug", "params":{"title":"..."}}'

Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Wang, Ce Zhang, and 1 others. 2023. AutoGen: Enabling next-gen LLM applications via multi-agent conversation. arXiv preprint arXiv:2308.08155.

### Search Knowledge Base

10

Description: Search documentation Parameters: - query: Search text (required) - limit: Max results (default 10) To call: curl -s -X POST http://localhost:<port>/ api/tools/execute -H "Content-Type: application/json" -d '{"tool":"search_kb", "params":{"query":"..."}}' ## Output Constraints # M_output Generated scripts must consume data exclusively from the runtime injection point. Never embed data values in source. Keep output under 50KB. Use JS functions to render tables and charts -- never write repetitive markup for each row. # User message (q') [User query: "Generate a supply chain operations dashboard"] ## Data: weekly_ops.csv # M_data (450 rows, 28 columns) Columns: LOB, Gate, ExecToGo, Shipped, Target, Attainment, Region, Week, ... Numeric columns summary (12 total): ExecToGo Shipped Target Attainment count 450.0 450.0 450.0 450.0 mean 2341.2 8923.4 9100.0 93.7 std 812.5 3201.1 2800.0 12.4 min 120.0 450.0 500.0 42.0 max 5600.0 18200.0 18000.0 112.0 Categorical columns (unique values): - LOB: Product A, Product B, Product C, Services, Product D - Gate: Supply, Orders, Process, Exec - Region: Americas, EMEA, APAC, Japan Sample rows (first 3): LOB=Product A, Gate=Supply, ExecToGo=3200, Shipped=12400, Target=13000, Attain=95.4% LOB=Product C, Gate=Orders, ExecToGo=1800, Shipped=6200, Target=7000, Attain=88.6% ...

11

Record · ID 361498 · SHA-256 abe64ca1d54ce70b
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.