PaperlayerView exact revision on arXiv

Source-linked AI summary

Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability

Sizhe Zhou, Sheldon Yu, Hui Wei, Junda Wu, Siru Ouyang, Yizhu Jiao, Shijia Pan, Julian McAuley, Yu Zhang, Tong Yu, Jiawei Han

arXiv:2607.26637v1cs.CLcs.AI

TL;DR

Filesystem-based memory is increasingly used by LLM agents, but whether agents can organize growing stores and whether organization improves outcomes remain underexplored. This paper systematically evaluates filesystem memory across conversational and procedural tasks, finding that organization conditionally reduces search cost but does not itself improve answer quality.

  • Problem

    Research has largely overlooked whether agents can keep filesystem memory organized as it grows and whether that organization provides measurable value.

  • Method

    The paper evaluates three agent roles around one filesystem across conversational and procedural tasks while varying memory shape, scale, tool harness, and agent capability.

  • Results

    Organization’s payoff is conditional: it improves search economy for large material, but no shape consistently wins answer quality and no measured agent turns organization into better answers.

  • Takeaways & Limitations

    Filesystem memory should treat organization as conditional rather than an end in itself, with outcomes also shaped by the consuming agent, memory form, and available tools.

  • Takeaways & Limitations

    Fixed-size benchmarks cannot determine whether the large-stream cost premium is repaid during retrieval over larger stores or longer-horizon accumulation.

Abstract

from arXiv · show

Deployed LLM agents increasingly keep their long-term memory as a filesystem: a directory tree of markdown files that the agent itself reads, writes, and reorganizes through generic file tools. Yet research has largely passed over this medium: prior systems design bespoke memory representations and study retrieval over them, leaving the default's two working assumptions untested: that an agent can keep a growing store organized as memories accumulate, conflict, and go stale, and that this organization pays. We present the first systematic exploration of filesystem-based memory for LLM agents. We formalize the setting as three roles around one memory filesystem: a management agent integrates and organizes incoming content, a search agent answers queries with cited sources, and an execution agent supplies task trajectories that are distilled into skills, unifying declarative memory and skills in a single store. Across long-conversation benchmarks and embodied tasks, we vary memory shape (agent-organized hierarchy, verbatim dump, chunk retrieval), stream scale, tool harness (sandboxed shell, memory-tool-style functions, varied search tooling), and the strengths of the management and search agents, tracking answer quality, cost, and store health as memory grows. What organization reliably buys is search economy: organized stores roughly halve retrieval cost where material is large. Today's agents, however, fall short of the default's promise: in our growth study, organization erodes for all but the strongest management agent, and no agent we measure converts organization itself into better answers. And the model is not the only lever over a store's shape: changing the tool set alone reshapes the store as strongly as swapping the model. The study turns the filesystem default from an assumption into a design space for agent memory.

1 INTRODUCTION

This paper systematically studies filesystem-based memory as a unified store managed, searched, and consumed by LLM agents. It finds that growing stores can remain useful and healthy, but organization’s quality and payoff depend on management capability, material, consuming agent, and tools.

  • Formalization and unification: The framework assigns management, search, and execution agents distinct roles around one filesystem, unifying declarative memory and skills under minimal contracts.The management agent organizes incoming content, the search agent answers with cited sources, and the execution agent supplies and consumes skills.
  • RQ1 (organization): Management agents grow subject-based trees, but organization reflects model signature more than scale and can silently condense content without preservation rules.As material increases, stores consolidate rather than shard, with hierarchy relocating among folders, files, and in-file headings.
  • RQ2 (value of shape): Organization’s clearest payoff is lower search cost, while no memory shape wins correctness everywhere.On skills, the best shape depends on the execution agent: verbatim logs suit strong agents, whereas distilled guidance suits weak agents.
  • RQ3 (backbone model capability): Management strength primarily changes organizational style, whereas search-agent strength directly improves conversation answer quality.A stronger management backbone can recover about half the loss from inconsistently recording changed preferences as dated updates, but the same upgrade has no effect elsewhere.
  • RQ4 (sustainability under scaling): Within measured horizons, stores remain useful and healthy as they grow, but organizational adherence tracks management capability and organization itself does not improve answers.Conversational stores edit an initially established file set without deleting, while skill stores preserve early memories and stronger management maintains files in place.
  • RQ5 (harness): Changing the tool set reshapes the memory store itself, making the harness a lever over organization rather than a neutral wrapper.The direction and payoff vary by setting: sharding and tying occur in long dialogue, while consolidation and gains occur on skills.

2 FORMALIZING FILESYSTEM-BASED AGENT MEMORY

The paper formalizes filesystem-based agent memory as a shared hierarchy of described markdown files accessed through tool harnesses by management, search, and execution agents. The same store supports conversational and procedural memory, differing in chunk and query types.

  • 2.1 THE MEMORY STORE: A memory store M is a finite set of files organized in a rooted path hierarchy, with paths, descriptions, contents, and markdown taxonomy extending into nested headings.Folders are shared path prefixes and carry no content; file names and headings jointly form one navigable labeled tree.
  • 2.1 THE MEMORY STORE: Each markdown file requires structured frontmatter containing its name and one-line description, while optional fields provide free-form metadata.Descriptions matter because listings and ranked search expose them before an agent opens a file.
  • 2.1 THE MEMORY STORE: Well-organized stores satisfy five principles: sibling distinction, sibling relatedness, parent-child coverage, tree-wide proximity, and structural economy.These principles require labels to distinguish siblings, related items to share neighborhoods, descendants to narrow scope, related content to remain nearby, and depth to improve routing.
  • 2.2 TOOL HARNESS AND AGENT ROLES: Every access passes through a finite tool harness H whose operations return observations and may mutate the store, spanning shell, memory-tool-style functions, and search-augmented tools.The harnesses differ in granularity and power; read operations leave the store unchanged.
  • 2.2 TOOL HARNESS AND AGENT ROLES: The management agent integrates incoming chunks into a store trajectory, with authority to create, rewrite, merge, split, move, or delete files as organization and maintenance.How this mandate is exercised as stream length T grows is a central object of study.
  • 2.2 TOOL HARNESS AND AGENT ROLES: The search agent returns cited answers from a fixed store, while the execution agent retrieves skill files, attempts tasks, and supplies trajectories and success signals as outcomes.Search is read-only in intent, and execution probes how store quality translates into task outcomes.
  • 2.3 TWO INSTANTIATIONS, ONE STORE: Conversational and procedural memory share the same store class, role contracts, and harnesses, differing only in whether chunks are dialogue slices or rendered trajectories and queries are questions or tasks.One system therefore serves both declarative and procedural memory.

3 EXPERIMENTAL SETUP

The experiments evaluate filesystem-based memory across conversational and embodied benchmarks, varying memory variants, model strength, tool harness, and stream scale under controlled protocols. Outcomes include answer quality, citation support, task success, cost, effort, and store health.

  • Benchmarks: LoCoMo uses a held-out test conversation with 158 questions spanning multi-hop, temporal reasoning, open-domain, and single-hop categories.The adversarial category is excluded; four questions contradicting the transcript are cataloged separately, and excluding them changes no conclusion.
  • Memory variants: Six memory variants range from Closed-book, with no store or retrieval, to agent-curated filesystem memory and chunk retrieval.Every non-Closed-book variant builds a store from the same conversation, while filesystem variants are searched under the paper’s formal contract.
  • Models and judge: The management and search roles primarily use gpt-5.4-mini at high reasoning effort, while grading uses a fixed gpt-5.4-mini judge at low effort and temperature 0.Builder and searcher strength ladders additionally vary gpt-5.4-nano and gpt-5.4, holding the remaining setup fixed.
  • Search agent prompts: All variants use a shared search-prompt family requiring answers to rely on and cite the store, preventing the prompt from becoming a confound.Prompts are adapted only when the store form requires it, such as raw-session reading notes for flat stores.
  • Tool sets: Management writes with six generic file operations plus line-level regex search, while search reads through filesystem-native, read-only tools exposing names, layout, and text.The deliberately different harnesses test deployed-style management and filesystem-native search behavior.
  • Metrics and skill setting: Quality covers correctness and citation support on conversational benchmarks, exact-match correctness on PersonaMem, and environment-reported task success on ALFWorld.Cost and effort are counted per model call, while ALFWorld evaluates 140 held-out household tasks across six goal families under three-chain and full-chain protocols.

4 RESULTS AND ANALYSIS

Filesystem memory organization changes store shape and reduces retrieval cost on large material, but its effect on answer quality is inconsistent. Management-agent capability decisively shapes organization, yet stronger organization does not reliably produce better answers.

  • Store organization: Organization relocates or consolidates hierarchy differently by setting: conversational stores shift structure into headings, while skill stores compact across all levels.The conversational 128k mini store has 2 files and 210 headings; gpt-5.4’s skill store has 16 files and 43 sections.
  • Store organization: Management-agent capability, not scale alone, primarily determines store shape, producing non-monotonic conversational fragmentation but monotonic procedural consolidation.At 128k, conversational stores contain 122, 2, and 105 files across agents; skill stores contain 114, 45, and 16.
  • Answer quality: No memory shape wins correctness everywhere: Foldered sessions ties or leads on LoCoMo, REALTALK, and PersonaMem 128k, while Agent-curated fails on PersonaMem 32k.Foldered sessions scores 86.1, 77.6, and 76.2 respectively; Agent-curated scores 37.5 there against 78.1 for the Verbatim dump.
  • Retrieval economy: Structure cuts retrieval cost most on large, dense material: PersonaMem 32k costs 1.4 cents versus 4.0 for the Verbatim dump, and 128k costs 1.6 versus 3.9.Reorganized and curated stores use more calls but retrieve fewer tokens per targeted read, lowering total search cost.
  • Answer quality: Preserving detail usually helps conversational and long PersonaMem 128k streams, whereas condensation helps PersonaMem 32k, where a tighter store is easier to search.Preserving every fact scores 82.9 versus 79.1 on LoCoMo, 77.6 versus 41.2 on REALTALK, and 59.5 versus 54.8 on 128k; condensation scores 68.8 versus 56.2 on 32k.
  • Answer quality: Skill-memory performance reverses with execution-agent strength: the Episode log leads under the stronger executor, while Curated skills+mem (GS) leads by ten points under the weaker one.The stronger-execution scores are 87.1% versus 82.1%; the weaker-execution scores are 76.4 versus 66.4%.

5 CONCLUSION · APPENDIX · A PROMPTS

The conclusion presents filesystem memory as a conditional design space: organization improves search economy for large material, but does not universally improve answer quality or reliably maintain store health. The appendix documents the prompts, tool profiles, and restructuring procedures that instantiate the study’s management, search, reorganization, and skill-setting roles.

  • 5 CONCLUSION: Organization’s value depends on material and consumer: structure buys search economy for large content, while no single memory shape consistently wins answer quality.The conclusion frames organization as conditional rather than universally beneficial, with outcomes also depending on the agent consuming the memory.
  • 5 CONCLUSION: No measured agent converted organization itself into better answers; outcomes instead moved with writer capability, memory form, and tool configuration.The conclusion cautions against treating organization as an end in itself and identifies the levers associated with changed outcomes.
  • A PROMPTS: The appendix reproduces the experiment prompts for management, source attribution, search, closed-book answering, reorganization, skill setting, and answer judging.These prompts correspond to prompts 1–11 and the reorganizer and skill-setting prompts identified in the appendix.
  • A PROMPTS: Prompt text is reproduced exactly as sent, except reasoning-only think-tag scaffolding is stripped; tool schemas are supplied separately through named tool profiles and API function calling.The appendix distinguishes prompt text from separately delivered tool interfaces.
  • A.1 MANAGEMENT AGENT (BUILDER) PROMPT: The Agent-curated store is built incrementally from empty by a management agent using seven write tools: view, create, str replace, insert, delete, rename, and grep.Every curated-store cell in Section 4 used the management prompt with this seven-tool write set, plus a benchmark-specific source-attribution extension.
  • A.2 REORGANIZER PROMPT (REORGANIZED STORE): The reorganized substrate is rewritten in place by a separate reorganizer that reuses the management prompt’s taxonomy, cross-reference, and frontmatter guidance for up to five passes.This restructuring stage differs from incremental chunk-by-chunk management, and the prompt variants produce the two versions of Table 1.
  • A.5 SKILL-SETTING PROMPTS: Skill-setting notes are placed according to scope: broadly applicable notes stay at the top level, while step-specific notes such as `bastingmistakes.md` belong inside that step’s folder.The note shapes and placements are designed so children forming a sequence read in order.

B EXAMPLE MEMORY FILESYSTEMS

The example filesystems show distinct organizational strategies across conversational and embodied-task memories. Curated stores consolidate content into routed structures, while verbatim session stores preserve contents and the strongest skill store uses filenames as routing.

  • Conversational stores: At LoCoMo, the agent-curated store consolidates a two-speaker conversation into three files under people/, with 116 sections and 151 cross-references.The files comprise one per speaker and a shared thread, with shared content linked rather than duplicated.
  • Conversational stores: At PersonaMem 128k, the curated store uses one deep hub and one spin-off: 195 sections across eight top-level domains, nesting up to four levels, plus 7 cross-references.The hub carries nearly the whole record, while a 15-section dating file sits beside it.
  • Conversational stores: The foldered PersonaMem 128k store groups 20 byte-identical session files into 10 topical directories, leaves none at the root, and produces skewed group sizes.Several directories contain only a single session, and the grouping is topical rather than temporal.
  • Skill store: After the 140-task full chain, the gpt-5.4 management agent produces a flat 16-file, 101KB skill store: 5 skills and 11 notes, with filenames carrying routing.The largest skill is a 25k-character general procedure covering both placement families; the notes capture preconditions, search strategy, and environment quirks.

C EXPERIMENTAL DETAILS · C.1 CONFIGURATION

The experiments use a common configuration centered on gpt-5.4-mini across search, management, and judging roles, with controlled stream units, generation caps, and context-compaction rules. Reported results come from test splits, with truncation effectively absent except for one benign event.

  • C.1 CONFIGURATION: Every main-grid role uses gpt-5.4-mini, including search, store-building management, and judging.The scale, harness, and model-strength studies reuse this configuration and report only their deltas.
  • C.1 CONFIGURATION: Reported numbers come from test splits, while calibration and pilots use validation splits.A mid-run API failure aborts the whole experimental cell.
  • C.1 CONFIGURATION: Stream chunks contain at most eight consecutive dialogue turns and close early at 3,000 characters.The management agent processes one chunk per build episode, and Chunk retrieval indexes those same chunks; other stores retain whole sessions.
  • C.1 CONFIGURATION: Agent inputs and outputs are not truncated during normal operation; caps only prevent runaway generations.Search agents and the judge use an 8192-token cap, while curation uses 32768 and store-restructuring passes use 100k.
  • C.1 CONFIGURATION: Truncation is zero across a 2,885-turn validation scan and every reported cell except one benign foldered-store search event.This establishes that the reported configurations generally preserve complete file views and generations.
  • C.1 CONFIGURATION: Contexts exceeding 96k prompt tokens are compacted into a running summary plus the three most recent turns.The same compaction rule applies to every cell, and compaction events are logged.

C.2 BENCHMARK DATA PROVENANCE … C.5 COST ACCOUNTING

The evaluation fixes specific benchmark slices, search prompts, and tool schemas across memory variants, while accounting for token-level costs and intrinsic compute bounds. Together, these sections define the provenance, interfaces, and measurement conventions underlying the experiments.

  • C.2 BENCHMARK DATA PROVENANCE: LoCoMo evaluation uses held-out conversation conv-50, retaining 158 non-adversarial questions from 204 total.
  • C.2 BENCHMARK DATA PROVENANCE: REALTALK uses one 85-question conversation whose stream produces 93 build chunks under Table 11 chunking, pinned at commit b903e06a.
  • C.2 BENCHMARK DATA PROVENANCE: PersonaMem covers three terminal-checkpoint 32k-tier conversations totaling 32 questions and one 128k conversation with a 42-question battery over six categories.The 128k sample contains a 784-message prefix spanning 20 sessions and about 113k tokens.
  • C.3 FIXED SEARCH PROMPTS: Each memory variant uses one fixed quality-matched search-agent prompt, with Reorganized and Agent-curated stores sharing the hierarchical-store prompt.
  • C.4 TOOL DESCRIPTIONS AND SCHEMAS: Tools are delivered through function calling: management uses a seven-tool write set, search uses four read-only tools, Center+BM25 adds ranked whole-file search, and Shell replaces both sets with bash.The tool configurations operate over the same memory store, while Table 12 records parameters and descriptions as delivered.
  • C.4 TOOL DESCRIPTIONS AND SCHEMAS: The memory-tool interface supports structured file insertion, deletion, renaming, table-of-contents inspection, section reads, and recursive BM25 whole-file search.Insertion rejects YAML-frontmatter edits, deletion is recursive but cannot remove /memories, and renaming creates missing parent directories automatically.
  • C.5 COST ACCOUNTING: Token usage is logged per model call as uncached input, provider-cached input, and output, with reasoning tokens counted within output.Dollar and cent figures are single-run measurements affected by episode length and provider cache behavior, using deployed gpt-5.4-mini list rates.
  • C.5 COST ACCOUNTING: Efficiency share is defined as (no-cache − measured)/(no-cache − perfect), contrasting repeated full-prefix prefilling with billed usage and the transcript’s intrinsic floor.The perfect floor pre-fills each transcript token once and decodes each output once, because the final prompt contains the full conversation.

C.6 SKILL-SETTING CONFIGURATION

The skill-setting experiments use ALFWorld’s 140-task valid-seen pool under reset-chain and family-interleaved full-chain configurations. A validated instruction-corrected Curated skills+mem variant was not run, leaving its effect an open limitation.

  • Experimental configuration: The skill setting uses 140 ALFWorld valid-seen tasks across six goal families, evaluated as either three independent reset chains or one fixed-order family-interleaved full chain.The full-chain order was derived once from a fixed seed and verified position-for-position across all full-chain cells.
  • Experimental configuration: The validated instruction-corrected Curated skills+mem variant was deliberately not run, so its effect on that condition’s standing remains an open limitation.The limitation concerns whether the corrected management-agent instruction would change the reported matrix result.

D ADDITIONAL RESULTS · D.1 WHY THE AGENT-CURATED STORE FAILS ON PERSONAMEM 32K

On PersonaMem 32k, the agent-curated store performs far worse than the verbatim dump despite greater curation effort. The failure reflects representation and inconsistent temporal reconciliation, not coverage, reliability, or retrieval grounding.

  • D.1 WHY THE AGENT-CURATED STORE FAILS ON PERSONAMEM 32K: 37.5% correctness makes the agent-curated store weakest on PersonaMem 32k, versus 78.1% for the verbatim dump on identical questions.Agent curation also requires the highest number of curation tool calls across every benchmark.
  • D.1 WHY THE AGENT-CURATED STORE FAILS ON PERSONAMEM 32K: The failure is representational rather than coverage- or reliability-related: cells have no API errors, failed episodes, or truncation.Searches use at most 12 of 40 tool rounds.
  • D.1 WHY THE AGENT-CURATED STORE FAILS ON PERSONAMEM 32K: 0.94 to 0.98 grounding and 0.97 to 1.0 attribution scores show that the search agent’s grounding and attribution remain near-perfect.The questions target a preference’s latest state while introducing earlier or static-profile distractors.
  • D.1 WHY THE AGENT-CURATED STORE FAILS ON PERSONAMEM 32K: Curation leaves superseded preferences beside updates as present-tense traits, obscuring which preference is current.One file retains a preference for face-to-face music sharing while later recording enjoyment of joining a forum.
  • D.1 WHY THE AGENT-CURATED STORE FAILS ON PERSONAMEM 32K: Curation rewrites first-person affect into neutral feature lists, removing emphasis needed to answer questions about the persona’s experience.An emphatic statement that an app became a game-changer becomes a bulleted capability.
  • D.1 WHY THE AGENT-CURATED STORE FAILS ON PERSONAMEM 32K: The management agent’s instruction supports timestamped reconciliation, preserving the current value and superseded value as dated history, but applies it inconsistently.Some updates are reconciled while others remain live traits, suggesting a backbone-model limitation rather than an inherent limitation of the representation.

D.2 LOCOMO GOLD-DEFECT CATALOG AND FILTERED SCORES

An audit found four materially defective questions among 158 LoCoMo golds, but evaluation retained the standard data for comparability. Removing them raises nearly all variants’ scores by about a point without changing orderings.

  • Gold-defect audit: Four of 158 evaluated LoCoMo golds are materially defective, representing 2.5% of the set.The study audits every gold against the conversation transcript but retains standard data for comparability.
  • Filtered scores: Removing the four defective questions leaves model orderings unchanged.Filtered correctness uses the same per-question judge outcomes as the standard evaluation.
  • Filtered scores: Every variant except the closed-book baseline rises by roughly a point after filtering.Each affected variant scored below its own average on the defective set, receiving only two correct judgments out of four.
  • Gold-defect audit: On question 138, memory-equipped variants answered faithfully from the record but were marked wrong, whereas closed-book guessing matched the gold.This illustrates how a defective gold can penalize evidence-grounded answers.

D.3 HARNESS AXIS: BUILD-SIDE EFFORT (RQ5)

On the build side, effort tracks the store being built more than the tool set. In clean reruns, management effort was similar for comparable LoCoMo stores, while the single-file PersonaMem build was cheapest per chunk.

  • Harness axis: build-side effort: Build-side effort tracks the store being built more than the tool set.This pattern is reported alongside per-query search cost and store shape by harness.
  • Harness axis: build-side effort: 15.1 rounds and 25.4 tool calls per chunk produced the 29-file LoCoMo store, versus 14.8 rounds and 20.0 tool calls for the shell’s 39-file store.The clean rerun compares Center+BM25 management with shell management.
  • Harness axis: build-side effort: 9.6 rounds per chunk made the single-file Center+BM25 PersonaMem build cheaper than the shell’s 11.6 rounds.Center’s dollar figures are reported only as the main-comparison reference because they came from a separate run.

D.4 HIERARCHY METRICS: DEFINITIONS AND FULL PANEL

The hierarchy metrics evaluate filesystem stores through combined-tree shape, content-unit structure, and deterministic lexical similarity. The full panel extends these shape measures with taxonomy-contract adherence metrics for sibling labels, cohesion, and misplacement.

  • Panel A: Shape: The shape panel measures each store’s combined tree from root through folders, files, and markdown headings, with skipped heading levels adding one depth.Content units are leaves: sections without subsections or files without headings.
  • Semantic metric definitions: Content units shorter than 40 characters are excluded from semantic metrics, which use deterministic lexical TF-IDF cosine similarity without learned components.The metrics therefore assess lexical structure rather than a learned semantic representation.
  • Taxonomy-contract adherence: The full hierarchy panel adds taxonomy-contract measures for sibling-label distance, sibling-content cohesion, cross-group centroid misplacement, and the previously defined B4 metric.Sibling-label distance reports mean separation and the worst confusable pair; dashes indicate undefined values when there are too few units or groups.

D.5 SKILL SETTING: SUCCESS BY GOAL FAMILY

Success is near-ceiling on simple placement across variants, while harder ALFWorld goal families determine the matrix. At the gpt-4.1 tier, Episode log leads on clean and cool, whereas Curated skills+mem (GS) dominates heat.

  • Goal-family results: Simple placement scores 94.3 to 100 across every variant at both tiers, leaving harder goal families to determine the matrix.The micro column reproduces Table 5 exactly.
  • Goal-family results: At gpt-4.1, Episode log leads clean at 85.2 and cool at 84.0.These results come from the archived per-task trajectories.
  • Goal-family results: At gpt-4.1, Curated skills+mem (GS) leads heat at 87.5, versus 37.5 for Episode log.Curated skills+mem (GS) trades its heat advantage for lower performance in clean and cool.

D.6 SKILL SETTING: DEPLOYMENT COST BY ROLE AND ABSOLUTE COMPUTE · D.7 GROWTH ATLAS

The skill-setting appendix decomposes deployment cost by role, execution-task conventions, and cache-adjusted compute, while the growth atlas grounds hierarchy tracking in reconstructed store states validated against task snapshots. Together, the passages show that memory can reduce execution burden and that provider caching is essential for interpreting compute costs.

  • D.6 SKILL SETTING: DEPLOYMENT COST BY ROLE AND ABSOLUTE COMPUTE: Table 16 separates three-chain cost across management, search, and execution agents, with the dollar total as the valid cross-role aggregate.The roles use different backbones and token counts, so token totals are not directly comparable across roles.
  • D.6 SKILL SETTING: DEPLOYMENT COST BY ROLE AND ABSOLUTE COMPUTE: 17.1 rounds versus 25.9: at gpt-4.1, the Episode log shortens execution episodes most relative to the no-store row.The passage states that every memory variant shortens episodes at gpt-4.1.
  • D.6 SKILL SETTING: DEPLOYMENT COST BY ROLE AND ABSOLUTE COMPUTE: 23.6 rounds versus 32.0: at the mini tier, Curated skills+mem (GS) cuts every reported column by the widest margin.The cited comparison includes uncached input of 13.5k tokens, though the supplied passage truncates the remaining columns.
  • D.6 SKILL SETTING: DEPLOYMENT COST BY ROLE AND ABSOLUTE COMPUTE: 16 to 23 times: the naive no-cache sum overstates intrinsic execution cost in the reported cells.This is why the study does not compare variants using raw prompt-token sums.
  • D.6 SKILL SETTING: DEPLOYMENT COST BY ROLE AND ABSOLUTE COMPUTE: 94.4 to 96.3 percent: the appending episode design realizes nearly all achievable caching savings in every reported cell.Measured compute remains within 1.7 to 2.05 times the passage’s truncated comparison baseline.
  • D.7 GROWTH ATLAS: 560 states, zero mismatches: Figure 9 validates per-step store reconstructions against per-task snapshots for content-level hierarchy tracking.The same records include task outcomes, per-role token usage, and store snapshots; the growth figures derive from these records.

E USE OF AI ASSISTANTS FOR ILLUSTRATIVE FIGURES

AI assistants contributed only to the schematic illustrations in Figures 1 and 2, while all plot and table data came from measured experiments.

  • AI assistants were used to draw the schematic illustrations for Figures 1 and 2.
  • The AI-assisted contribution applied only to illustration assets.
  • Every plot and table in the paper presents measured experimental results, not AI-generated output.
Loading 2607.26637v1…