---
title: 'SlideAgent: Dynamic Slide Update'
url: https://www.emergentmind.com/topics/slideagent
type: topic
---

# SlideAgent: Dynamic Slide Update

SlideAgent is an end-to-end agentic system for performing dynamic slide update on arbitrary, user-provided PowerPoint decks. It was introduced for the task defined as “Dynamic Slide Update via Natural Language Instructions on User-provided Templates,” in which a system must ground a natural-language instruction in a shared data backend, modify the affected analytical content, and preserve the original slide design. In the formulation introduced with DynaSlide, SlideAgent combines multimodal slide parsing, instruction grounding, SQL-based data retrieval, tool-augmented recomputation, and fact-aware summary rewriting, and serves as a strong reference baseline on a benchmark of 20,036 real-world instruction–execution triples under bring-your-own-template conditions [2604.17894].

## 1. Task definition and scope

SlideAgent addresses a specific automation problem: keeping complex, analytics-style presentation decks up to date without rebuilding them from scratch. The motivating observation is that presentation slides are a primary medium for data-driven reporting, yet maintaining such decks remains labor-intensive. Existing automation methods are described as mostly following fixed template filling and therefore as unable to support dynamic updates for diverse, user-authored slide decks [2604.17894].

The central task is not generic slide generation. It is an in-place update problem over arbitrary PowerPoint slides that already exist, and whose layout and style must be preserved. In this setting, a source slide, a natural-language user instruction, and a shared external database jointly determine a target slide. The system must identify which elements depend on the changed filters or aggregation logic, regenerate only the affected analytical content, and re-render those elements at the exact original coordinates with the original fonts, colors, and structure [2604.17894].

A common misconception is that such updating reduces to string substitution or template slot filling. SlideAgent’s formulation is substantially stricter. It includes tables, charts, titles, and textual conclusions; it assumes user-provided templates rather than a closed template library; and it evaluates exact agreement of both content and layout. The benchmark further enforces a bring-your-own-template setting in which no two splits share the same sub-template, so generalization to unseen layouts is part of the task definition [2604.17894].

The framework distinguishes between two logic regimes. In the closed-domain regime, table and chart logic is recoverable through a library of 11 predefined statistical functions \(F_k\), including mean, sum, count, growth-rate, binning, and cross-pivot. In the open-domain regime, the system must reconstruct previously unseen analytical logic from slide artifacts and captions, making aggregation recovery itself part of the inference problem [2604.17894].

## 2. System architecture and internal representations

SlideAgent is organized into two tightly coupled stages: **Slide Understanding** and **Instruction-Driven Update** [2604.17894].

In the first stage, multimodal layout parsing combines a rendered slide image with the original PPTX structure. A vision–language model, Qwen-VL, processes the PNG rendering and proposes bounding boxes with semantic roles such as title, caption, table body, chart, and summary. In parallel, `python-pptx` extracts shape objects together with precise geometry and style attributes. These two views are aligned by intersection-over-union matching:

$$
\mathrm{IoU}(b_v, b_p)=\frac{\mathrm{Area}(b_v\cap b_p)}{\mathrm{Area}(b_v\cup b_p)}
$$

If \(\mathrm{IoU} > 0.5\), the VLM label is attached to the exact PPTX shape. The resulting representation is a structured list of element objects of the form \(\{id, role, text, x, y, w, h, style\}\) [2604.17894].

Logic extraction then operates over tables and charts. Data-source extraction uses a schema-aligned slot-filling prompt to map caption text and headers to nine database columns—`city`, `block`, `date_code`, `supply_sets`, `trade_sets`, `dim_area`, `dim_price`, `dim_unit_price`—and to the correct PostgreSQL table. Function-logic extraction depends on whether the logic is closed-domain or open-domain. In the closed-domain case, the language model selects one of the 11 predefined statistical functions via a function-calling API and recovers both function identity and arguments. In the open-domain case, the logic is decomposed into a five-tuple

$$
\mathcal{L}=(S,H,C,F,O)
$$

where \(S\in\{FC,CF,XC\}\) is the table structure type, \(H=(H_{\text{row}},H_{\text{col}})\) are headers, \(C=[k,T,v_{\text{start}},v_{\text{end}},v_{\text{step}}]\) is the constraint specification, \(F\) are source fields, and \(O\) are aggregation functions such as `Sum`, `Avg`, and `Count`. An internal `synthesize_analytical_table` routine then executes a Split–Apply–Combine pipeline to regenerate the tabular result [2604.17894].

The second stage treats the user instruction as a state update over structured parameters. User instruction parsing is modeled as a JSON state-update task: the system takes the current parameter state, including slots and function arguments, and prompts an LLM to produce a revised state with only the relevant fields changed. That revised state is converted into a new SQL query through a structured prompt, executed on the shared PostgreSQL database, and passed to the appropriate computation tool. Closed-domain tables invoke the selected predefined function \(F_k\); open-domain tables invoke `synthesize_analytical_table(D,\mathcal{L})`. Summary regeneration uses a fact-aware rewriting prompt that receives the original summary and the pre-update and post-update data, and is required to produce a numerically exact narrative reflecting the new figures. Final rendering uses `python-pptx` with the layout metadata from Stage 1 to repopulate all updated elements in place [2604.17894].

## 3. DynaSlide benchmark and data model

DynaSlide operationalizes the dynamic update task on real-estate analytics slides and provides the benchmark on which SlideAgent is evaluated [2604.17894].

| Component | Specification |
|---|---|
| Source slides | 7,685 distinct source slides |
| Templates and themes | 34 user-defined sub-templates across 6 business themes |
| Database | 1.79 M cleaned transaction records, 2020–2024 |
| Grounded triples | 20,036 instruction–execution triples |
| Split sizes | 12,022 train, 4,007 val, 4,007 test |

The source slides were generated by EasySlide (`python-pptx`) from user-defined sub-templates spanning themes such as cross-structure analysis, market capacity, and price trends. The shared PostgreSQL database covers three cities and two market types, new versus resale. This shared backend is not incidental: it defines the grounding substrate that makes updates reproducible rather than merely stylistic [2604.17894].

Each instruction–execution triple is accompanied by explicit metadata. The `slide_filters` field records the original SQL template, the statistical function \(F_k\), and resolved variables. The `query_filters` field records the variables changed by the instruction. The `update_filters` field records the merged filter set used for re-querying and recomputation. A metadata YAML file is also included for reproducibility. This design makes DynaSlide simultaneously a dataset for end-to-end evaluation and a substrate for component-level diagnosis [2604.17894].

The benchmark’s bring-your-own-template condition is methodologically important. Because no two splits share the same sub-template, template memorization is structurally disallowed. A system must instead infer slide semantics and update logic from previously unseen layouts. This makes DynaSlide closer to real business reporting workflows than benchmarks built around a fixed slide ontology [2604.17894].

## 4. Update workflow and execution semantics

SlideAgent’s operational workflow can be illustrated by the example instruction: “Show me 2023–2024 instead of 2020–2022 and bin area in 20 m² steps” [2604.17894].

The first step is dependency identification. Using the structured representation built during slide understanding, the system identifies which slide elements depend on the date range or on area binning. This avoids global regeneration and constrains the modification scope to the affected analytic objects. The instruction parser then updates the JSON parameter state by changing fields such as \(v_{\text{start}}=2023\), \(v_{\text{end}}=2024\), and \(v_{\text{step}}=20\) [2604.17894].

Next, SlideAgent generates and executes a new SQL query. The paper gives the following representative form:

```sql
SELECT date_trunc('year',date_code) AS year,
       width_bucket(dim_area,20, ..., ...) AS area_bin,
       SUM(trade_sets) AS sales
FROM Transactions
WHERE city='Beijing' AND block='Chaoyang'
GROUP BY year, area_bin;
```

The retrieved data are then passed to the appropriate aggregation tool or to the generic synthesizer, depending on whether the logic is closed-domain or open-domain. The resulting table and chart series replace the prior analytical content. Summary regeneration is explicitly fact-aware: for example, a sentence such as “Sales grew by 10%” is rewritten to “Sales grew by 25.4%” using the old and new numerical evidence as conditioning context [2604.17894].

The final stage re-renders all affected elements in place. Titles, tables, charts, and summaries are written back to the exact original coordinates, preserving fonts, colors, and overall structure. The paper also notes an architectural negative result: no separate attention weights or update operators are explicitly defined beyond the slot-filling and state-update prompts; the key formal mappings are the JSON parameter state and the logic tuple \(\mathcal{L}\) [2604.17894].

This workflow clarifies why dynamic slide update is not equivalent to ordinary text editing. The system must jointly solve element localization, schema grounding, logic recovery, SQL synthesis, analytical recomputation, fact-preserving narrative rewriting, and style-preserving rendering. Any failure in an upstream component can propagate into multiple downstream artifacts [2604.17894].

## 5. Evaluation protocols and empirical performance

DynaSlide defines evaluation at both end-to-end and component levels. The end-to-end metric is **Task Success Rate (SR)**, defined as the percentage of test slides whose content, including text data and numeric values, and whose layout exactly match the ground truth after update. Element-level accuracy is reported separately for Titles, Tables, Charts, and Summaries. In the open-domain setting, the pipeline is also evaluated by module: Function Logic Extraction, Data Source Extraction, Instruction Parsing, SQL Generation, Tool Invocation, and Summary Update [2604.17894].

The main empirical findings are strongly diagnostic. Model scale matters: GPT-OSS-120B achieves **80.6% SR** in the closed-domain setting and **68.9% SR** in the open-domain setting, substantially above smaller 20B models. Closed-domain performance exceeds open-domain performance by **12–15 points**, indicating that reconstructing unknown logic remains a principal challenge. At the element level, captions are comparatively easy, at approximately **95%**, because they often involve direct substitution, whereas tables and charts fall in the **66–87%** range and summaries in the **37–69%** range. In the open-domain module breakdown, logic extraction and schema grounding reach approximately **88–90%** with GPT-OSS-120B, while summary update reaches only **68%**. The paper explicitly identifies error accumulation across modules as common: a misparsed header or incorrect SQL query can cascade into chart and summary failures [2604.17894].

These results establish several technically relevant points. First, the hard part of dynamic slide update is not merely database access; fact-aware text regeneration is empirically the weakest component. Second, exact layout preservation does not remove the need for semantic reasoning; it amplifies it, because the system must update content without relaxing presentation constraints. Third, open-domain analytical logic remains a distinct bottleneck even when slide parsing and schema grounding are relatively strong [2604.17894].

A second common misconception is that a high element-level score on captions or titles implies reliable slide updating overall. The benchmark results contradict this. Numerically exact summaries and logically reconstructed analytical tables remain the dominant sources of end-to-end failure, so strong local substitution performance does not by itself indicate full task competence [2604.17894].

## 6. Research context, limitations, and future directions

Within the literature provided here, SlideAgent occupies the update-and-preserve corner of the slide-agent design space. It is distinct from systems for generating new presentations from documents, such as the two-stage edit-based PPTAgent with PPTEval over Content, Design, and Coherence [2501.03936]; from preference-conditioned generation systems such as SlideTailor, which distills content and aesthetic preferences from a paper–slides pair and a visual template and introduces a chain-of-speech mechanism [2512.20292]; from audience-conditioned evaluation frameworks such as X+Slides, which scores decks by Audience Coverage, Domain-wise Coverage, Efficiency, and Correctness [2606.19256]; and from in-place editing benchmarks such as PPTArena, where PPTPilot uses a hybrid programmatic-and-XML plan-edit-check loop over real PowerPoint decks [2512.03042]. This broader context suggests that recent slide research is fragmenting into at least four subproblems: generation, updating, editing, and delivery.

SlideAgent’s own paper identifies several open directions. **Cross-modal consistency** remains difficult, because text, tables, and visuals must remain synchronized after update. **Robust open-domain logic reconstruction** remains limited beyond the 11 predefined templates, and richer program synthesis or self-supervised chart de-rendering is proposed as a possible aid. **Error isolation and recovery** are still underdeveloped, since current pipelines allow upstream failures to propagate; verification checks and fallback strategies are suggested. The paper also points to **broader domain coverage and unstructured templates**, including finance, healthcare, and fully uncurated slide decks scraped in the wild, as well as the **integration of decorative and conceptual diagrams**, which fall outside DynaSlide’s focus on analytic elements such as tables, charts, and summaries [2604.17894].

A plausible implication is that future systems will need to combine the strengths of several adjacent lines of work: the template generalization required by DynaSlide, the structured edit planning seen in PowerPoint editing agents, the user- and audience-modeling emphasized in personalization benchmarks, and the delivery-aware planning found in presentation-video systems. In its present form, however, SlideAgent is best understood as a benchmark-driven reference architecture for natural-language, database-grounded, style-preserving analytical slide updating under bring-your-own-template conditions [2604.17894].

Source: https://www.emergentmind.com/topics/slideagent