: A Hierarchical Memory Driven Agent Framework for Personalized Slide Generation with Multi-turn Local Revision

Source: converted from arXiv LaTeX source source/main.tex.

-1.55em 0.35em

Abstract

Personalized presentation generation requires more than conditioning on a current prompt or template: agents must preserve stable user preferences across tasks, retain newly introduced preferences and constraints during multi-turn revision, and carry out local edits reliably. We propose MemSlides, a hierarchical memory framework for personalized presentation agents that separates long-term memory from working memory and further divides long-term memory into user profile memory and tool memory. User profile memory stores intent-conditioned profiles for round-0 personalization, working memory carries active preferences and session constraints across revision rounds, and tool memory stores reusable execution experience for reliable localized editing. MemSlides pairs this memory design with scoped slide-local revision, so targeted updates act on the smallest affected region instead of repeatedly regenerating the full deck. In controlled experiments, user profile memory improves persona-alignment judgments on a multi-persona, multi-intent profile bank, tool-memory injection improves closed-loop modify behavior in diagnostic matched-pair settings, and qualitative cases illustrate working memory's ability to carryover preferences. Taken together, these results suggest that effective personalization in presentation authoring depends on separating persistent user profiles, session-level working memory, and reusable execution experience across generation and localized revision.

Introduction

Automatic presentation generation aims to turn

user requests into structured slide decks, and has gained increasing attention because slides are widely used, yet creating high-quality presentations remains time-consuming and cognitively demanding [sun2021d2s,maheshwari2024presentations,mondal2024personaaware,zeng2025slidetailor]. Recent agentic systems further advance this task by

producing complete decks through multi-modal or tool-based workflows [ge2025autopresent,zheng2025pptagent,xu2025pregenie,xie2025slidebot,liang2025slidegen,zheng2026deeppresenter,ozden2026arcdeck]. Although these systems can now produce complete and visually polished decks, they still lack persistent personalization, which is essential for generating ready-to-use slide decks because users vary in domain, purpose, style, and presentation habits. For example, users may prefer different layouts, templates, and styles when creating slides for different purposes, such as academic presentations versus business presentations.

An effective personalized slide generation framework should build and maintain user profiles that capture users' long-term preferences in organizing, styling, and revising presentations across different intents, rather than requiring users to repeatedly specify their preferences in every interaction.

Prior work has progressively expanded the capability of presentation-generation systems sun2021d2s,mondal2024personaaware, bandyopadhyay2024enhancing,maheshwari2024presentations,ge2025autopresent, xu2025pregenie,xie2025slidebot,liang2025slidegen,ozden2026arcdeck. PPTAgent moves beyond text-to-slides by coupling generation with presentation-specific evaluation [zheng2025pptagent], and DeepPresenter introduces environment-grounded reflection for agentic presentation generation [zheng2026deeppresenter]. These systems improve general generation and agentic refinement, but do not explicitly model user-specific personalization. SlideTailor addresses personalization by conditioning scientific slide generation on reference slides and task-time templates [zeng2025slidetailor], but its personalization remains tied to provided examples or template conditions rather than to an accumulated user profile. These observations therefore expose a central gap: slide generation agents still lack a user-facing multi-turn dialogue process that converts revision requests into reusable preference memory and preserves local revision constraints across later turns.

Figure fig:pptagent_memory_workflow: Overview of . The framework comprises long-term memory and working memory. Long-term memory stores user profile memory and tool memory for persistent personalization and reusable execution experience, while working memory carries the current session state for personalized generation and localized revision. In round $t$ , $s_t$ is the current session state, $f_t$ is the user feedback, and $s_t+1$ is the updated state after Modify Exec, the memory-guided revision executor.

This gap has two roots. First, personalization in presentation authoring is often revealed through revision rather than fully specified before generation, yet existing slide generation agents still handle edits by re-contextualizing or re-generating large parts of the deck. As a result, small changes must compete with deck state and feedback history for limited context, making multi-turn local modification fragile. Second, current systems mainly improve presentation-agent workflows, tools, and evaluators, but still treat personalization as an implicit byproduct of prompting rather than a direct service enabled by memory design. In a similar spirit to agent memory work [zhong2023memorybank,packer2023memgpt,wu2025memoryage], personalization of slide generation can be largely enhanced by incorporating memory as an explicit framework rather than an undifferentiated dialogue buffer.

To address these problems, in this paper, we present MemSlides that introduces scoped slide locality as its revision strategy for multi-turn slide editing. Rather than re-reading or re-writing the whole deck for each feedback turn, projects the request onto the smallest affected slide region and operates on a bounded repair surface. It reads only a structured snapshot of that local surface, including its local layout structure, available selectors, and exposed style rules, and writes back only patches scoped to explicit selectors or to those style rules. In this way, both reading and writing stay local by construction, reducing context pressure and unintended drift while preserving already aligned content across turns.

Building on this modification strategy, is further integrated with a hierarchy memory framework for personalized presentation generation. The framework has two levels: long-term memory and working memory. Working memory maintains the current session state and temporary feedback across revision rounds, so later local edits can preserve active temporary memory from the same deck. Long-term memory persists across jobs and is further divided into user profile memory and tool memory. User profile memory is user-specific and intent-aware: for each user and each intent, preferences are organized by various dimensions including theme, content, visual, layout, template, and general, and are routed into working memory when each job starts. Tool memory captures reusable execution experience for later edits. This hierarchy memory framework enables generating and revising presentations according to both persistent user preferences and the active intent of the current session. The overview of is shown in Figure fig:pptagent_memory_workflow.

In experiments, we evaluate across multiple dimensions including slide deck quality, instruction satisfaction, and preference alignment. We develop persona-alignment judgments as metrics to evaluate personalization alignment.

Qualitative comparisons further illustrate the effectiveness of MemSlides in aligning with users' preferences.

Our contributions are threefold: 0pt 2pt 0pt 1pt 0pt itemize We introduce , a personalized presentation agent that supports multi-turn localized revision. By maintaining session state and applying targeted slide-level updates instead of repeated full-deck regeneration, provides the interaction substrate needed for learning user preferences from revision feedback. We further develop a hierarchical memory framework for consisting of a long-term memory and a working memory. The long-term memory contains user profile memory and tool memory, allowing stable user preferences and reusable execution experience to persist across jobs, while working memory tracks session-specific constraints. We construct a multi-persona, multi-intent user profile bank for personalized presentation generation evaluation. Experiments show that user profile memory improves round-0 persona alignment, tool memory enhances localized modify reliability in diagnostic matched-pair comparisons, and working memory supports session-level preference carryover. itemize

Related Work

Slide generation.

Presentation generation has progressed from document compression and structured summarization to LLM-based systems that emphasize audience adaptation, editability, task-time preference inference, and visual refinement [sun2021d2s,mondal2024personaaware,zheng2025pptagent,zeng2025slidetailor,zheng2026deeppresenter]. Presentation authoring also draws on controllable layout and design generation, including code-like layout representations, in-context layout prompting, layered or diffusion-based layout modeling, and visual preference modeling [tang2023layoutnuwa,lin2023layoutprompter,inoue2023layoutdm,zhang2023layoutdiffusion,peng2025designpref]. These works improve slide quality, editability, task-level controllability, and visual composition. Our focus is complementary: how user-specific preference and execution memory should persist across slide-generation and revision sessions rather than being supplied only as current-task inputs.

Memory and tool-using agents.

Retrieval-augmented and external-memory language models show that stored context can support generation [lewis2020rag,guu2020realm,khandelwal2019knnlm,borgeaud2021retro,izacard2022atlas,wang2023longmem].

These studies focus on persistent memory, reflection, structured updates, and long-term/short-term memory management [zhong2023memorybank,packer2023memgpt,park2023generativeagents,xu2025amem,chhikara2025mem0,wang2025mirix,kang2025memoryos,wu2025memoryage,yu2026agemem]. Tool-using and reflective agents further establish patterns for interleaving reasoning with actions, using APIs or modular tools, coordinating execution, and learning from feedback [yao2023react,shinn2023reflexion,schick2023toolformer,patil2023gorilla,qin2023toolllm,li2023apibank,karpas2022mrkl,wu2023autogen,wang2023voyager,madaan2023selfrefine,nakano2021webgpt,ahn2022saycan,wang2022selfconsistency,yao2023treeofthoughts,hu2026agentictooluse]. In contrast, targets personalized presentation authoring, where memory must distinguish user preference from execution experience and preserve the intended local edit scope during multi-turn revision.

Personalized generation and evaluation.

Personalized generation has evolved from explicit persona conditioning to profile- and history-aware generation [li2016persona,wu2021splitmemory,salemi2023lamp,mysore2023pearl,jiang2025personamem]. Recent surveys and alignment work characterize personalization as an agentic, retrieval-aware, and preference-sensitive problem [zhang2024personalizationllm,li2025personalizationragagent]. In visual domains, personalized visualization recommendation and DesignPref show that persistent expressive or design preferences can be learned from user history [qian2022personalizedvis,peng2025designpref]. In PPT generation, Persona-Aware-D2S and SlideTailor personalize slides through audience specifications, examples, or templates provided for the current task, whereas we study preferences accumulated across tasks and retained during multi-turn revision. Our evaluation follows rubric-based and pairwise LLM-as-judge protocols in a controlled memory/no-memory setting [liu2023geval,zheng2023llmasjudge,kim2023prometheus,zhu2023judgelm,li2024arenahard].

MemSlides

Problem Formulation

We formulate personalized presentation generation as a stateful, multi-turn authoring problem rather than a one-shot source-to-slides conversion task [sun2021d2s,zheng2025pptagent,zeng2025slidetailor,zheng2026deeppresenter]. Given source material $x$ , a user profile memory $P_u$ , and an optional task-time template $\tau$ , the system first produces an initial deck:

$$ S_0 = G_{\mathrm{init}}(x, P_u, \tau). $$

We refer to this initial generation stage as round-0. After receiving user feedback $f_t$ at revision round $t$ , the system updates a session state $z_t$ and edits the current deck accordingly:

$$ z_t = U(z_{t-1}, f_t; S_{t-1}), \qquad S_t = G_{\mathrm{edit}}(S_{t-1}, x, P_u, \tau, z_t), \quad t \ge 1. $$

Here, $z_t$ stores feedback-derived constraints and edit intentions that are active within the current authoring session. The objective is not only to improve the first draft, but also to move the deck toward the user's intended presentation while preserving slides that are already well aligned.

This formulation separates three personalization signals with different lifetimes. The user profile memory $P_u$ captures recurring cross-job preferences, such as preferred themes, visual styles, layout habits, content density, and general design conventions. The task-time template $\tau$ , when provided, serves as a deck-local design constraint for the current job. The session state $z_t$ captures temporary, turn-specific requirements, such as changing the color of new slide titles or compressing text after a particular section. When these signals conflict, explicit session feedback takes precedence for the current deck, followed by the task-time template and then the user profile memory.

The temporal structure also determines the operational scope of revision. We define a job as one complete deck-authoring session, a round (turn) as one user-triggered revision within that job, and an operation as a concrete edit or tool call. Revision requests may be local to a single slide, propagate across multiple slides, or modify the deck structure itself. Therefore, repeatedly regenerating the full deck is undesirable: it can overwrite already aligned content, introduce unnecessary drift, and increase context pressure. A stateful revision system should instead select the minimal effective scope for each request while carrying forward relevant session constraints.

Figure fig:localized_tool_pipeline: Localized modify execution in . Working memory supplies active temporary preferences, carryover instructions, current edit state, and buffered tool-memory signals to the Plan--Act--Guard pipeline. Plan builds an execution contract, Act applies the minimal effective edit, and Guard verifies coverage before finalizing the localized update.

Multi-Turn Localized Modify Execution

Plan. converts each revision request into an explicit execution contract rather than leaving scope control implicit in the prompt. The contract records the inferred scope, target slide paths, active rule identifiers, selector hints, and whether target coverage is required. Local requests bind to the resolved slide; deck-level rules expand coverage to all slides; and hybrid requests preserve both the global rule and the local exception. Future-only rules created by an insertion request are not incorrectly forced onto existing slides, which avoids turning a structural edit into an unnecessary deck-wide rewrite.

Act. The executor chooses editing tools according to this contract and the available slide structure. If target slides share an explicit selector, it prefers a batch CSS update; if the change targets common semantics such as titles, body text, or footers across structurally different slides, it uses semantic batch styling; if a single existing slide needs content or local structure changes, it reads a layout-first repair surface and applies non-empty patch operations to snapshot targets or exposed rules. Page insertion and deletion remain explicit page-level operations, while whole-slide rewriting is restricted to new slides or controlled recovery after a corrupted or uninspectable state.

Guard. The protocol treats completion as a checked state, not merely as the model deciding to stop. Patch calls are bound to the snapshot content hash; stale snapshots trigger rebinding hints rather than immediate full rewrite; and every patch must specify concrete operations derived from repair candidates, rules, or targets. When coverage is required, premature finalize calls are blocked until all target slides are modified or explicitly confirmed compliant. These guards make localized revision a constrained execution process: the agent can update the intended deck region while reducing repeated re-contextualization, uncontrolled scope expansion, and drift in already aligned slides.

Working memory is the session-scoped state layer that makes Plan--Act--Guard multi-turn rather than single-shot. It stores active temporary preferences from earlier feedback, carryover instructions that remain valid for the current deck, and edit-state records such as resolved targets, coverage status, and snapshot rebinding hints. It also buffers round-level tool-memory signals before transferable experiences are consolidated into long-term tool memory. Plan reads this state to construct the execution contract, Act uses it to restrict edits to the intended region, and Guard updates it after verification or rebinding.

As illustrated in Figure fig:localized_tool_pipeline, localized modification gives the agent an editable substrate, but personalization still requires separating signals by lifetime and use. Rather than using one homogeneous buffer [lewis2020rag,guu2020realm,khandelwal2019knnlm,borgeaud2021retro,izacard2022atlas,wang2023longmem], instantiates hierarchy memory through two modules: user profile memory decides what the deck should reflect, and tool memory supports how edits are executed, following agent-memory work on persistent and session state [zhong2023memorybank,packer2023memgpt,park2023generativeagents,xu2025amem,chhikara2025mem0,wang2025mirix,kang2025memoryos,wu2025memoryage,yu2026agemem].

User Profile Memory for Personalization

User profile memory governs personalization in . Instead of using personalization as a static prompt prefix, we represent it as a persistent user profile plus active temporary memory for the current session:

$$ \label{eq:preference_memory_state} \mathcal{M}^{\mathrm{pref}}_t = \big(P_u, A_t\big), $$

where $P_u$ is user $u$ 's long-term profile and $A_t$ is the active temporary memory at revision round $t$ . Stored profile items are organized by intent and presentation dimensions, while only the reconciled subset enters $A_t$ . This separation is the lifecycle shown in Figure fig:preference_memory_lifecycle: user profile memory provides cross-job personalization priors, routing turns the intent-matched and request-compatible items into active temporary memory for the current deck, and job-end consolidation writes back only stable interaction signals. The figure therefore explains why profile memory is not injected as a static prompt block: it is selected, reconciled with the current request, used during round-0 and later revisions, and then updated after the round.

Figure fig:preference_memory_lifecycle: User profile memory lifecycle in . Long term memory stores intent-conditioned user profile memory accumulated across jobs. At job start, user profile memory items are routed into active temporary memory by comparing them with the current user request: compatible preferences coexist, explicit conflicts are superseded, and only the active subset guides generation. At job end, stable interaction signals are consolidated back into the user profile memory.

Before round-0 generation, selects the profile bucket for the current intent $i_0$ , extracts constraints from the request $q_0$ , and routes compatible items into working memory:

$$ \label{eq:profile_routing} \begin{aligned} \tilde P_u = \mathcal{S}!\left(P_u, i_0\right), \qquad C_0 = \mathcal{E}!\left(q_0\right), \qquad A_0 = \mathcal{R}!\left(\tilde P_u, C_0\right). \end{aligned} $$

Here, $\mathcal{S}$ retrieves the intent-matched profile bucket, $\mathcal{E}$ extracts request constraints, and $\mathcal{R}$ reconciles them. Explicit request conflicts supersede the corresponding profile item for the current deck; compatible preferences coexist as active memory.

During revision, active temporary memory evolves with feedback:

$$ \label{eq:working_memory_update} A_t = \mathcal{U}!\left(A_{t-1}, r_t\right), $$

where $r_t$ is the revision request at round $t$ . The update operator $\mathcal{U}$ appends newly exposed preferences, supersedes true conflicts, and keeps non-conflicting items active for later rounds.

At job end, long-term user profile memory is updated by consolidation rather than by directly promoting every temporary item:

$$ \label{eq:profile_consolidation} P_u^{+} = \mathcal{C}!\left(P_u, H\right), $$

where $H$ denotes the user messages in the current job and $\mathcal{C}$ is intent-aware profile consolidation.

This prevents transient requests from being stored as persistent preferences, while allowing stable, transferable signals to improve future personalization.

Tool Memory for Reliable Editing

Tool memory addresses the execution side of personalized editing. Even when the target preference is correct, the agent may repeat ineffective trials or re-trigger known tool misuse. Prior tool-using and reflective agents motivate interleaving reasoning, tool calls, and feedback [yao2023react,shinn2023reflexion,schick2023toolformer,qin2023toolllm,madaan2023selfrefine].

In our setting, the remembered execution unit is tied to slide-edit scope and verification rather than to raw interaction history.

In , tool memory is organized two execution flows that match the temporal granularity of localized editing (Figure fig:tool_memory_lifecycle). Round-scope task experience is available when a modify job starts and is buffered in working memory across later modify rounds; after each round, agent lessons, tool-error summaries, and automatically extracted patterns can update this pool. Operation-scope tool-chain experience is finer grained: raw reasoning--tool--observation chains are segmented into reusable chain fragments, indexed by operation context, and retrieved before similar future tool calls.

Figure fig:tool_memory_lifecycle: Tool memory flow in . Round-scope task experience is available at job start, enters working memory during modify rounds, and is updated through agent lessons, tool-error summaries, and automatically extracted patterns before memory consolidation. Operation-scope tool-chain experience records raw reasoning--tool--observation chains as compact fragments that are retrieved and injected before similar future tool calls.

We represent this execution support at revision round $t$ and operation $k$ as

$$ \label{eq:tool_memory_state} \mathcal{M}^{\mathrm{tool}}{t,k} = \big(E_t^{\mathrm{round}}, E\big), $$}^{\mathrm{op}

where $E_t^{\mathrm{round}}$ denotes round-scope execution experience and $E_{t,k}^{\mathrm{op}}$ denotes operation-scope tool chain experience for the $k$ -th operation. Tool memory does not define what the deck should look like; it helps the agent execute that objective with fewer repeated errors, less backtracking, and more reliable local verification. Transferable experiences are consolidated into long-term tool memory at job end.

Experiments

-1.2ex We evaluate whether improves personalized presentation generation and multi-turn localized revision. The main text reports personalization results on a controlled multi-persona, multi-intent user profile bank, a DeepPresenter-style general-quality check on the same decks, and a diagnostic matched-pair modify evaluation for localized revision. Protocol details, baseline conditions, and profile-bank construction are provided in Appendices app:evaluation_protocol_details, app:baseline_provenance, app:profile_bank_construction, and app:deeppresenter_quality_eval, with protocol, profile-bank, and compute summaries in Appendix Tables tab:appendix_eval_protocol_summary, tab:appendix_profile_library_catalog, and tab:appendix_compute_accounting; table captions define the reported metrics.

Main Results

Personalization

tables/profile_memory_v6_bestof_main_table

User profile memory improves round-0 persona alignment across multiple dimensions. Under the persona-alignment judgments, Ours achieves all-column wins over both baselines on GLM-5 and Gemini 3.1 Pro. With GPT-5, it remains ahead of SlideTailor on Content, Structure, and Specificity, and ahead of DeepPresenter on Content, Visual, and Specificity, while DeepPresenter has slightly higher Structure (Table tab:profile_memory_v6_bestof_main; Appendix Table tab:profile_memory_v6_bestof_gpt_appendix gives per-persona GPT-5 details).

tables/profile_memory_v6_ppteval_main_table

tables/tool_memory_main_table

On the same generated decks, the DeepPresenter-style quality metrics in Table tab:profile_memory_v6_ppteval_main check whether persona gains remain compatible with ordinary presentation quality. The results show that improves personalization alignment while maintaining competitive PPT generation quality.

Localized Revision

In this diagnostic matched-pair modify setting, tool-memory injection is associated with stronger closed-loop completion and post-edit verification while reducing time to the first correct edit and core tool time (Table tab:tool_memory_table1_redesign). Since each matched pair changes only tool-memory injection, these process gains support the combined tool-memory pathway for reliable multi-turn modification, while the W-L-T-NA counts expose pair-level heterogeneity; Appendix Tables tab:tool_memory_table1_pair_detail and tab:tool_memory_paired_robustness provide pair-level details and the paired robustness check.

The same locality-sensitive setting is illustrated qualitatively in Figure fig:localized_modify_example, which contrasts a broader edit footprint with a targeted patch on the requested element; Appendix Figure fig:appendix_tool_memory_localized_editing shows a complementary process trajectory.

Figure fig:localized_modify_example: Qualitative illustration of localized modify execution. Given the same local edit request, DeepPresenter can satisfy the target change while altering non-target regions of the slide. instead applies a targeted patch to the requested element, preserving already aligned slide content.

Analysis and Discussion

User profile memory yields broad, not marginal, alignment gains.* Table tab:profile_memory_v6_bestof_main shows a consistent but not uniform pattern across model families. With GLM-5 and Gemini 3.1 Pro, leads both baselines on all four persona-alignment dimensions. With GPT-5, the gains are strongest on Content and Specificity, while the two baselines retain isolated advantages on Structure and Visual. Averaged across model families, improves over DeepPresenter by 1.37 points on Content, 0.53 on Structure, 1.66 on Visual, and 1.19 on Specificity, and improves over SlideTailor by 2.73, 2.95, 2.79, and 3.08 points on the same dimensions.

The gains are planning-level persona gains.* The strongest evidence is the joint movement of Structure and Specificity. Structure excludes template retrieval accuracy, while Specificity uses distractor personas; moreover, judges do not see the original prompt or parsed intent. Thus the improvement cannot be read as merely better template matching or generic visual polish. It indicates that routed long-term profiles help decide page roles, ordering, layout fit, evidence emphasis, and persona-distinct framing before round-0 generation.

Persona gains remain compatible with general deck quality.* Table tab:profile_memory_v6_ppteval_main shows that Ours obtains the best Avg. on GPT-5 and remains competitive on GLM-5, while Gemini 3.1 Pro shows the best Style and Diversity but lower Constraint. These results do not claim uniform dominance on every quality metric; they show that the persona-alignment improvements in Table tab:profile_memory_v6_bestof_main are not simply a trade-off against ordinary presentation quality.

Figure fig:six_round_profile_consolidation: Qualitative cross-job profile consolidation. Across six repeated jobs, local feedback cues become reusable profile preferences and later reappear as default slide-organization patterns, including evidence-boundary guardrails, owner/timeline closure tables, module input--output responsibility schemas, and implementation checklists. The figure is diagnostic case evidence rather than a separate quantitative metric.

Localized revision should be judged by locality as well as success.* Figure fig:localized_modify_example shows the qualitative difference behind the modify setting: a system may satisfy the requested change while still touching non-target regions, whereas keeps the patch closer to the requested element. This is why the localized-revision metrics are paired with process constraints such as closed-loop completion, verification, and core-tool-time efficiency.

Scope of profile and working-memory evidence.* The round-0 persona-alignment table is the main quantitative evidence for user profile memory. Figure fig:six_round_profile_consolidation provides qualitative cross-job profile-consolidation evidence, showing how repeated local cues become reusable organization preferences in later jobs. Appendix Figure fig:appendix_working_memory_carryover provides complementary within-session evidence for delayed carryover of active temporary memory, and Appendix Figure fig:appendix_template_generation_showcase shows template-guided generation examples.

Tool memory improves overall reliability and search efficiency, but not by winning every pair.* In the diagnostic matched-pair modify setting, tool-memory injection raises overall Closed-Loop Completion from 0.815 to 0.963 (W-L-T-NA 3-1-5-0) and Strict Verify from 0.310 to 0.534 (8-1-0-0). It also reduces Time to First Correct Edit from 609.5s to 242.5s (6-2-0-1) and lowers the geometric mean Core Tool Time Ratio to 0.327 $\times$ (8-1-0-0), indicating less non-inspection tool work. The pair-level counts are important: one Gemini hard-modify pair loses on Closed-Loop Completion, two pairs lose on first-edit latency, and one GPT-5 pair uses more core tool time. Together with the pair-level detail in Appendix app:tool_memory_pair_details, these process metrics are consistent with a more constrained localized editing pattern rather than repeated full-deck regeneration or broad exploratory edits.

Conclusion

We introduced , a hierarchical memory framework for personalized presentation generation. By separating user profile memory, active temporary memory, and tool memory, supports round-0 persona alignment and multi-turn localized revision. Controlled experiments show improved persona alignment and diagnostic gains in local modify reliability.

Limitations

Our evidence is scoped to controlled persona-alignment judgments, diagnostic matched-pair modify settings, and qualitative working-memory cases. The profile bank and edit requests are proxies rather than real-user deployment studies. Future work should add broader human studies, randomized edit sets, and stronger memory consent, deletion, and sensitive-preference safeguards.

Appendix

The appendix provides protocol details, supplemental quantitative tables, and qualitative examples that clarify how different memory signals appear in generated presentations. The qualitative figures are intended as diagnostic illustrations, while the aggregate claims remain tied to the quantitative tables in the main text and appendix.

Evaluation Protocol Details

Section 4 defines the evaluated claims and reports the main metrics. This appendix subsection records the protocol controls used to keep those metrics attributable to the corresponding memory condition, rather than to prompt leakage, arm ordering, or unmatched source materials.

Blind profile-memory judging.

The profile-memory evaluation uses complete round-0 decks as the judging unit. Before judging, every candidate deck is rendered into page-aligned images and assigned an anonymous arm label. The judge receives only the target persona summary, the aligned deck images, and the dimension rubric; the original user prompt, parsed intent, system identity, and memory condition are hidden. This separation is important because the profile claim concerns whether persistent memory changes the produced deck, not whether a judge can recover instructions that were explicitly written in the current prompt. Each persona-alignment dimension receives three blind votes. We aggregate the votes under anonymous arm labels and map arms back to systems only after aggregation.

Persona-alignment judgment operationalization.

The persona-alignment judgments report four 0--10 dimensions. Content measures whether content selection, evidence type, emphasis, and wording match the target persona. Structure measures whether page order and page-type/layout fit reflect persona-conditioned deck organization; it excludes template matching because this dimension targets deck organization rather than template retrieval accuracy. Visual measures information density, whitespace, chart/card/diagram style, visual hierarchy, and overall visual tone. Specificity uses distractor personas to test whether the deck remains identifiable as the target persona rather than a generic professional presentation.

Matched tool-memory pairs.

The tool-memory protocol evaluates localized multi-turn modification as paired agent executions. Within each pair, the source deck, model family, persona, and modify request are fixed; the compared condition is whether tool memory is injected into the run. The reported process metrics are computed from recorded execution traces: edit completion, verification after change, finalization, time to first correct edit, and core tool time. Inspection and markdown-conversion calls are excluded from core tool time because they reflect observation and format transfer rather than edit execution. The modify scenarios are selected before inspecting pair outcomes and are intended as a diagnostic controlled setting, not as a distribution-level estimate over all possible user revisions.

Tool-metric operationalization.

Table tab:tool_memory_table1_redesign uses two higher-is-better metrics and two lower-is-better efficiency metrics. Closed-Loop Completion measures whether a modify run reaches a successful local edit, verifies the edited result, and finalizes the revised deck. Strict Verify After Change measures whether successful slide-changing edits are followed by local verification within a short tool-call window, so it rewards edit-and-check behavior rather than late or unrelated inspection. Time to First Correct Edit is the wall-clock interval from modify-task start to the first slide-changing edit that satisfies the requested change. Core Tool Time Ratio is the geometric mean of memory/no-injection core-tool time ratios after excluding inspection and markdown-conversion tools, with the no-injection arm normalized to 1.0. These definitions make the table about the editing trajectory itself: whether the agent reaches the requested local change, checks it promptly, and does so with less non-inspection tool work.

Reproducibility information.

The paper reports the evaluated systems, model families, judge rubrics, evaluation configurations, matched-pair definitions, and trace-derived metrics needed to inspect the reported protocol. The source code is publicly available, and selected evaluation artifacts will be released when documentation and licensing checks are finalized. Table tab:appendix_eval_protocol_summary summarizes the main protocol controls for the profile-memory and tool-memory evaluations.

Table tab:appendix_eval_protocol_summary: Protocol controls used to isolate memory effects in Section 4.

\begin{table}[!htbp]
\centering
\small
\setlength{\tabcolsep}{5pt}
\caption{Protocol controls used to isolate memory effects in Section~4.}
\label{tab:appendix_eval_protocol_summary}
\begin{tabular}{lll}
\toprule
Control & Profile-memory evaluation & Tool-memory evaluation \\
\midrule
Evaluation unit & Complete round-0 deck & Paired modify execution \\
Matched factors & Source, model family, task prompt & Source deck, model, persona, request \\
Varied condition & Profile-memory injection & Tool-memory injection \\
Hidden signals & Prompt, intent, system, memory label & Memory-condition label \\
Aggregation & Three blind votes per dimension & Pair-level trace metrics \\
Evidence scope & Main persona-alignment result & Diagnostic selected-pair setting \\
\bottomrule
\end{tabular}
    \end{table}

Baseline Conditions and Prompt/Profile Separation

The persona-alignment judgment comparison is designed to isolate persistent profile memory from prompt-level task conditioning. The memory-injected condition and its matched control use the same source material, model family, target persona, task prompt, and generation pipeline. The control condition keeps the authoring task unchanged but withholds long-term profile memory, session preference memory, and reusable tool experience from the generation context. The memory-injected condition receives the same task information plus the routed profile entry for the target persona-intent pair.

This separation matters because the task prompt already contains the source-specific request and role intent. Profile memory is therefore evaluated as an additional persistent signal: structured preferences accumulated across controlled authoring jobs, not a replacement for the user request. SlideTailor is included as an external reference/template-conditioned personalization baseline; it is evaluated from its generated presentations under the same judging protocol, but it is not treated as an internal memory ablation.

The judge-side protocol further prevents prompt or template leakage from dominating the score. The persona-alignment judge receives the target persona summary and rendered deck images, but not the original prompt, parsed task intent, system identity, or memory condition. The Structure metric deliberately excludes template matching, so the main profile table evaluates persona-conditioned organization and layout fit rather than template retrieval accuracy.

Compute Resources and Runtime Accounting

All reported experiments are inference-time agent evaluations; no model training or fine-tuning is performed. Runs were orchestrated from a local Linux workstation using Python 3.11.14. The machine has 48 Intel Xeon Silver 4214R CPU threads and 503 GiB of system memory; although the machine also has NVIDIA A40 GPUs, the reported experiments are primarily API-bound rather than GPU-bound. The local machine is used for agent orchestration, document conversion, slide rendering, image inspection, and tool-mediated HTML/PPT editing; LLM generation and judging are performed through external model APIs.

For runtime accounting, each run records model-response usage, local tool-call outcomes, tool active time, and first-to-last-event wall-clock span. Because different LLM providers expose token accounting fields with slightly different schemas, we use these records as reproducibility accounting rather than as a normalized price estimate. Table tab:appendix_compute_accounting reports the resulting accounting summary. The prompt and completion token columns sum provider-reported token usage; tool-call columns count successful and failed local tool invocations; tool active time sums local tool execution duration; and wall-clock span measures the elapsed time from the first recorded event to the last recorded event within each run.

The accounting rows are evidence scopes rather than additional experimental conditions. The profile-memory row summarizes the generation and analysis runs used for profile-memory experiments, so it should not be read as the number of decks used in Table tab:profile_memory_v6_bestof_main. The tool-memory row corresponds to the diagnostic matched-pair setting reported in Tables tab:tool_memory_table1_redesign and tab:tool_memory_table1_pair_detail, counting both the memory-injected and no-injection arms for the nine matched pairs. The working-memory row covers the four runs used to construct the two qualitative carryover cases in Figure fig:appendix_working_memory_carryover. The table is intended to document API budget and local orchestration/runtime footprint, not to serve as a method-performance result or a GPU-compute claim.

tables/compute_runtime_accounting_table

For the diagnostic matched-pair tool-memory setting, the recorded process metrics also record the core tool-time used in Table tab:tool_memory_table1_redesign: 110.5 seconds for memory-injected runs and 354.8 seconds for no-injection runs, after excluding inspection and markdown-conversion tools. Under the same exclusion, the matched runs contain 779 core tool calls for memory-injected runs and 878 for no-injection runs.

Profile-Bank Construction

The profile bank is built as a controlled multi-persona, multi-intent testbed for long-term personalization. We define ten occupation-style persona profiles, each associated with three role-intent buckets, resulting in 30 persona-intent profile entries. The personas cover postsecondary teacher, software developer, management analyst, marketing manager, graphic designer, training and development specialist, financial manager, operations manager, medical and health services manager, and legislator. Each entry is used as the read/write unit for long-term profile memory during generation. Table tab:appendix_profile_library_catalog lists all 30 entries in the completed profile bank. The third column reports shortened English summaries of stored profile_json fields: layout.slide_structure, visual.chart_type_priority, and, where useful, content.notes.

tables/profile_library_catalog_table

Library construction has two stages. First, each persona-intent entry receives controlled authoring interactions over the same source material but with different role-intent prompts, producing initial profile evidence for that entry. Second, because some accumulated entries remain sparse in structured fields, we apply a seeded completion step. This step uses stable persona prompts, an occupation-grounded role-preference registry, and existing profile signals to fill missing theme, visual, layout, content, and general fields. It follows only-fill-empty and intent-preservation rules: existing intent-specific signals are preserved when they already contain usable information, and generic task constraints such as page count or attachment-use instructions are filtered out.

The seeded completion is treated as profile-bank construction, not as additional interaction evidence. It updates only the structured profile entry and does not create synthetic interaction episodes, tool experiences, or template-usage records. Each filled field is accompanied by provenance tags that identify whether it came from the seed prompt, role-preference registry, current profile signal, or suite intent definition. At runtime, the generation condition reads the completed profile entry matching the current persona and role intent, while the no-injection baseline uses the same source task without profile memory. The evaluation is defined by semantic persona and role-intent conditions rather than by implementation-specific profile identifiers.

DeepPresenter-Style Quality Evaluation

We evaluate the generated decks with the general-quality metric family reported by DeepPresenter [zheng2026deeppresenter]. This protocol is not a persona-specific alignment judge and does not replace Table tab:profile_memory_v6_bestof_main in the main text. Instead, it asks whether user-profile-memory injection preserves or improves standard presentation-quality dimensions while improving persona alignment.

The metrics are reproduced as follows. Constraint, Content, and Style are reported on a 1--5 scale. Content and Style are computed with the released PPTEval-style prompt implementation used for presentation quality evaluation [zheng2025pptagent]. Content evaluates slide-level content clarity and image-text complementarity, while Style evaluates slide-level visual appeal and style coherence. Constraint is reimplemented from the DeepPresenter paper definition for this task suite: it checks hard task constraints and instruction-level requirements that can be verified from the generated deck and source material. For SlideTailor, we report a language-adjusted Constraint score because its current generation setup does not target the requested output language; the language item is excluded while the remaining hard and semantic checks are retained. Diversity follows the DeepPresenter diversity definition, using deck-level visual embeddings from DINOv2 [oquab2023dinov2] and the normalized Vendi score [friedman2023vendi]; it is a suite-level metric. Avg. is the arithmetic mean of Constraint, Content, and Style, and Diversity is not included in Avg. All values are re-evaluated on the generated presentations used in this work.

Table tab:profile_memory_v6_ppteval_main in the main text reports these general-quality results; bold marks the best score in each metric column over the full table. Across the three model families, user-profile-memory injection keeps Ours competitive on the general-quality metrics while the persona-alignment table shows stronger personalization gains. The most stable pattern is on Content: Ours is above SlideTailor for all three model families and is close to or above the DeepPresenter no-injection baseline. Ours also achieves the highest Avg. on GPT-5 and GLM-5, while Gemini 3.1 Pro has a lower Avg. because of the Constraint score. On the visual side, Ours obtains the best Style and Diversity scores for Gemini 3.1 Pro and remains close to the strongest systems in the other model families. Taken together, the table suggests that user-profile-memory injection is compatible with competitive general-quality behavior, but not uniformly dominant on every metric or every model.

This quality check matters because it shows that the main persona-alignment gains do not come from a trivial trade-off that damages ordinary presentation quality. The evaluation uses the DeepPresenter quality family as an external consistency check, with Content and Style from the released PPTEval-style prompts, Constraint reimplemented from the DeepPresenter-style definition for this task suite, and Diversity computed from deck-level DINOv2 embeddings with a normalized Vendi score. It therefore supports a narrow and reviewer-safe conclusion: MemSlides improves persona-focused generation while remaining competitive on standard quality metrics, even though the gains are not monotonic across every model-metric pair.

Additional Persona-Alignment Judgment Results

The GPT-5 profile-memory details indicate that the main persona-alignment trend is not driven by a single persona. Table tab:profile_memory_v6_bestof_gpt_appendix reports ten-persona results under the persona-alignment judgments. On average, profile-memory injection improves Overall alignment by 2.42 points, with gains of 3.30 on Content, 2.30 on Structure, 3.17 on Visual, and 2.43 on Specificity. The gains are strongest when the target persona changes evidence selection, narrative organization, or visual treatment substantially; they are smaller when the no-injection baseline already happens to match the target persona reasonably well.

tables/profile_memory_v6_bestof_gpt_appendix_table

Template-Guided Generation Examples

Figure fig:appendix_template_generation_showcase provides qualitative examples of template-guided generation under different user roles. Each example pairs a selected template slide with a generated slide for the same source paper. The examples show templates acting as concrete task-time design constraints over layout, palette, typography, and visual organization, while persona-conditioned generation adapts the slide content and emphasis.

Figure fig:appendix_template_generation_showcase: Template-guided generation examples: selected template slides (top) and matched persona/template generations (bottom).

Tool-Memory Pair-Level Details

The pair-level tool-memory results make the diagnostic matched-pair setting transparent. Table tab:tool_memory_table1_pair_detail reports the tool-memory and no-injection values for each matched pair, together with the pair verdict from the tool-memory perspective. The Gemini 3.1 Pro rows use a fixed graphic-designer hard-modify family, so the setting exposes hard cases rather than selecting pairs by favorable outcomes. The improvements are not from a single model: most pairs either improve or tie on closed-loop completion, and most improve Strict Verify. First Correct Edit time and Core Tool Time Ratio also usually decrease, although not monotonically in every pair. This supports the diagnostic conclusion that tool memory is associated with more reliable localized editing behavior, while retaining the caveat that the table summarizes a diagnostic matched-pair setting.

tables/tool_memory_pair_detail_table

Figure fig:appendix_tool_memory_localized_editing illustrates the localized edit trajectory behind these process metrics.

Figure fig:appendix_tool_memory_localized_editing: Illustrative qualitative trajectory for localized modify behavior. The example contrasts broad or incomplete editing behavior with a more constrained trajectory that inspects the target slide, applies a local patch, verifies the local change, and finalizes the revision. This figure is a process illustration for the diagnostic tool-memory setting rather than a separate quantitative result.

Paired robustness check.

Table tab:tool_memory_paired_robustness provides a non-parametric robustness check over the same nine matched pairs. For each metric, we compute pair-level wins and losses from Table tab:tool_memory_table1_pair_detail and apply an exact one-sided sign test after excluding ties and unavailable pairs. The strongest paired evidence appears on Strict Verify and Core Tool Time Ratio, while Closed-Loop Completion and First Correct Edit remain directionally favorable. Because the underlying setting is a diagnostic matched-pair protocol, these checks are intended to characterize robustness within this controlled protocol rather than to claim significance over the full distribution of possible modify requests.

The W-L-T-NA column should be read as win--loss--tie--not-available counts from the tool-memory perspective. A win means that the memory-injected run is better than its no-injection counterpart under the metric direction: higher is better for Closed-Loop Completion and Strict Verify, while lower is better for First Correct Edit time and Core Tool Time Ratio. A tie means the two arms have the same value. NA means that one arm lacks a comparable value for that metric; for example, First Correct Edit is unavailable when a run never produces a verifiable first correct slide edit, so no latency comparison can be made. The sign test therefore uses only win/loss pairs and asks whether the number of wins is larger than would be expected under a 50--50 no-effect baseline.

tables/tool_memory_paired_robustness_table

Additional Qualitative Memory Cases

Figure fig:appendix_working_memory_carryover: Working-memory cases for delayed preference carryover. A future-facing rule is stated in an earlier turn and only becomes actionable after a later edit. Memory injection retrieves the stored rule at the trigger turn, whereas the no-memory setting relies mainly on local context.

Existing Assets and Use Conditions

We use existing presentation-generation systems, hosted model APIs, visual representation models, and author-created templates for research comparison, generation, evaluation, and analysis. We do not redistribute third-party model weights, proprietary endpoints, commercial services, or third-party code as part of this submission. Table tab:existing_assets summarizes the main existing assets used in the experiments and their use conditions.

Table tab:existing_assets: Existing assets and use conditions.

\begin{table}[!htbp]
\centering
\small
\caption{Existing assets and use conditions.}
\label{tab:existing_assets}
\setlength{\tabcolsep}{5pt}
\begin{tabular}{p{0.24\linewidth}p{0.68\linewidth}}
\toprule
Asset category & Use and condition \\
\midrule
Prior presentation systems &
DeepPresenter, SlideTailor, and PPTAgent are cited and used for baseline
generation, comparison, and evaluation alignment under their released code or
project terms; third-party code is not redistributed. \\
\midrule
Hosted LLMs &
GPT-5, GLM-5, and Gemini 3.1 Pro are used for generation, modification, and
LLM-as-judge evaluation through hosted APIs or institutionally provided endpoints under
applicable provider terms; no model weights or endpoints are redistributed. \\
\midrule
Visual representation models &
DINOv2 is used for deck-level visual embeddings in diversity-style analysis.
The standard DINOv2 model/code release is under Apache License 2.0; checkpoints
are not redistributed. \\
\midrule
Presentation templates &
Author-created templates are used as task-time design constraints for
template-conditioned generation examples and evaluation settings; no
third-party templates are redistributed. \\
\midrule
Evaluation materials &
Profile-memory banks, prompts, generated decks, matched-pair definitions, and
judge outputs are constructed for this paper's controlled evaluation. These
materials are described for reproducibility. The source code is publicly
available, and selected evaluation artifacts will be released when
documentation and licensing checks are finalized. \\
\bottomrule
\end{tabular}
\end{table}

Broader Impacts and Responsible Use

Personalized presentation agents can lower the cost of producing structured visual communication, helping users translate technical material into decks that better match their audience, role, and design preferences. Memory mechanisms may also reduce repeated instruction effort across authoring sessions and make multi-turn editing more efficient, especially when users need consistent style, recurring content emphasis, or localized revisions over an evolving deck.

At the same time, persistent personalization introduces risks. Stored preference profiles may encode sensitive user habits, organizational style constraints, or audience-targeting strategies, and incorrect memory consolidation may preserve outdated or unintended preferences across future tasks. Presentation generation can also be misused to produce persuasive but misleading materials, or to over-adapt content framing to a target audience. These risks suggest that personalized presentation agents should provide user-visible memory inspection, editing, and deletion controls; avoid storing unnecessary sensitive information; and separate stable user preferences from one-off task instructions. Our current work studies controlled generation and editing settings rather than deployment, and we leave stronger privacy controls, memory auditing, and real-user governance mechanisms to future work.