MemSlides: Hierarchical Memory for Slide Agents, Reviewed
A hierarchical memory framework for personalized presentation agents. Try it at memslides.com.
At a glance
- What is it?
- MemSlides is a Python framework that treats deck building as a stateful authoring loop with three memory stores and scoped slide-local edits. The design is aimed at research workflows, and its setup cost is real: LibreOffice, Playwright, conda, and your own model credentials.
- Who is it for?
- Adopt MemSlides if you are building or evaluating a personalized presentation agent and can absorb the conda, LibreOffice, and Playwright setup plus your own model credentials. Do not adopt it if you need a hosted, credential-free deck generator or a stable public API, since the README documents an experiment runner rather than a service contract.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem MemSlides targets: decks that change after round one
Most slide-generation tools treat the task as a single conversion: source material goes in, a deck comes out. The README states that MemSlides treats presentation generation as a stateful authoring process instead, which is a different problem statement. If you have ever asked a model for a deck, then asked it to change the chart on slide seven and watched it rewrite slide two, you have hit the failure this project is organized around.
The target user is not someone who needs one deck. It is someone building an agent that produces decks for the same person repeatedly, or that revises a deck across many feedback turns. The README frames this as personalization: recurring preferences should persist across jobs, while session-specific constraints should expire with the deck. That distinction only matters if there is more than one job. For a single one-off generation, the memory architecture is overhead with no payoff.
Three memory stores separated by lifetime
The mechanism is a split by how long a piece of information should live. Long-term memory holds two things: intent-conditioned user profile memory, used for what the README calls round-0 personalization, and tool memory. Working memory holds active preferences, session state, and revision constraints within the current deck.
The word intent-conditioned is doing real work here. Personalization is not a flat preference list applied to every deck. The README describes routing intent-matched preferences into the current job, and it names the dimensions those preferences cover: theme, visual style, layout, template use, content strategy, and general presentation habits. So a profile entry is keyed by the kind of presentation being made, not just by the user. That is a sensible design if a person wants dense technical layouts for internal reviews and sparse visual decks for talks.
Tool memory is the less common piece. The README says it stores reusable execution experience so that future localized edits can avoid repeated failures, and that it retrieves prior task and tool-chain experience before similar edit operations. This is a cache of what worked, indexed by the operation being attempted. It is a plausible response to the reality that agent tool calls fail in repeatable ways, but the README does not describe the retrieval key, the storage format, or how stale entries are invalidated. Treat that as an open question rather than a documented guarantee.
Scoped revision: patching the smallest affected region
The second half of the architecture is the edit path. During revision, the README states that MemSlides projects user feedback onto the smallest affected slide region and applies scoped local patches rather than regenerating the full deck. The stated goal is to reduce unintended drift in content that was already aligned.
This is the part with the clearest practical consequence. Full-deck regeneration is easy to implement and easy to reason about, because every revision produces a fresh, internally consistent deck. Local patching preserves prior work but introduces a new question: how does the system decide the boundary of the affected region? The README says feedback is projected onto the smallest affected region but does not specify the projection rule. If that rule is wrong, the failure mode is a patch that fixes the requested element and leaves a neighboring element inconsistent with it. That is a different class of bug than regeneration drift, and it is not obviously better. It is better only when the projection is accurate.
A figure in the repository, localized_modify_example.png, is referenced as an illustration of this behavior. The README does not describe the example in text.
Getting it running: system packages, conda, Playwright, and a smoke suite
The README gives a source install path. It starts with system packages: sudo apt-get update, then sudo apt-get install -y libreoffice fontconfig fonts-noto-cjk poppler-utils. The presence of LibreOffice and poppler-utils tells you the pipeline touches real document rendering and conversion, not just text. The CJK font package suggests non-Latin text is expected to render correctly rather than appear as boxes.
From there, conda env create -f environment.yml, then conda activate memslides, then pip install -e ".[research]". The research extra is the one the README uses in its own instructions. Browser automation is installed separately with python -m playwright install chromium ffmpeg, and the entry point is confirmed with python -m memslides.experiment --help.
The verification step is a packaged suite: python -m memslides.experiment run smoke_minimal --output-base .memslides/experiments --parallel 1. The README is explicit that smoke_minimal is only a small verification suite, and that any local suite YAML path or packaged suite name can be passed to the same run command. A Docker path exists as well: docker compose build, then docker compose run --rm memslides with the same experiment command pointed at /app/.cache/memslides/experiments.
Configuration is where the project stops being self-contained. The README states that MemSlides needs user-provided model and service credentials for real generation experiments, kept outside git and supplied through environment variables, a .env file, or a private YAML file selected with MEMSLIDES_CONFIG_FILE or the --config flag. The packaged public config lives at src/memslides/memslides.yaml, and its placeholders are expanded from the current process environment. The README text supplied here is truncated at that sentence, so the full placeholder list is not available from this material.
The setup burden is the first real limitation
The install path is not a pip install and a one-line call. It requires a conda environment, four system packages, a Chromium download through Playwright, and an ffmpeg download through the same command. That is a lot of surface area for a tool whose value proposition is a memory architecture. On a locked-down machine without sudo, or in a container image you do not control, the apt-get step alone can block adoption.
The credential requirement compounds this. The smoke suite is described as a verification suite, not a demonstration of generation quality, and the README says credentials are needed for real generation experiments. So the first thing you can run without credentials tells you that the plumbing is connected. It does not tell you whether the personalization works. That gap between verifying the install and evaluating the claim is worth planning for.
A second limitation is documented rather than implied: the repository carries an explicit notice that memslides.org is a fake website, not operated by the project, and not affiliated with the repository. The official trial site is memslides.com. If you search for this project by name, the wrong domain may come up first. That is an unusual thing for a README to have to say, and it is a real operational hazard for anyone trying to reach the hosted demo.
How this differs from a stateless deck generator
The natural comparison is a stateless pipeline that turns a document or prompt into a deck in one pass, with no profile store and no revision memory. Tools in that category are simpler to deploy because there is no state to persist, no profile schema to design, and no question about when a preference should expire. Every request is independent, which also means every request is reproducible from its inputs alone.
The difference in approach is not the model. It is where the state lives. A stateless generator encodes all context in the prompt for that one call. MemSlides moves part of the context out of the prompt and into stores with different lifetimes, then retrieves from them. That buys cross-job consistency and cheaper revisions, and it costs you a persistence layer, a retrieval policy, and a new failure mode where the wrong memory is retrieved and silently applied. The README does not describe how conflicts between a stored profile preference and an explicit in-session instruction are resolved. If you are choosing between the two approaches, that resolution rule is the thing to look for in the code, because it determines whether the memory helps or fights the user.
Maintenance, licence, and what to check before adopting
The licence is Apache-2.0, which permits commercial and modified use and includes an explicit patent grant. It does not remove the obligation to preserve notices and state changes, and it does not cover the model or service credentials you supply, which carry their own terms. That is a description of the licence text, not legal advice.
On maintenance, the supplied material gives a release history of one tagged release, version_1, dated 2026-06-15, and a last push of 2026-09-09. The README's news table lists milestones through 2026-08-06, including a note that the project crossed 1,000 GitHub stars and that the demo site crossed 200 registered users. Those numbers describe attention, not code quality, and they say nothing about how quickly issues are closed or whether the memory APIs are stable. A single tagged release means you should expect the interfaces described in the README, such as the suite YAML format and the config resolution order, to be the version you pin to rather than a settled contract.
The environment is pinned to Python 3.11 and Node 20 according to the badges. If your stack is on a different Python minor version, check environment.yml before assuming the conda create will resolve cleanly.
What to verify first is concrete. Confirm that src/memslides/memslides.yaml expands from your environment by running the smoke suite with your credentials in place, not just with the defaults. Read the code that decides the boundary of a local patch, since that rule is the difference between scoped revision helping and hurting. And check how a stored profile preference is overridden by an explicit instruction in the current session, because that conflict is the one most likely to produce a deck the user did not ask for.
Editorial conclusion
Adopt MemSlides if you are building or evaluating a personalized presentation agent and can absorb the conda, LibreOffice, and Playwright setup plus your own model credentials. Do not adopt it if you need a hosted, credential-free deck generator or a stable public API, since the README documents an experiment runner rather than a service contract. Before committing, verify that the packaged config at src/memslides/memslides.yaml expands cleanly from your environment, and run python -m memslides.experiment run smoke_minimal to confirm the toolchain works on your machine.
Community notes