cs.AIAug 25, 2026

ACE: A Self-Correcting Agentic Canvas Editor for Multi-Slide Presentation Automation

Authors: JooYoung Jang, Taegyeong Lee, Jihyeon Park, Nojun Kwak

Organizations: Seoul National University · Miridih

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

Commercial design platforms increasingly edit documents through large language model (LLM) agents, but two practical problems block reliable deployment: legacy document formats expose only flat, absolutely positioned elements, so agents must recompute coordinates and routinely break layouts; and design has no unique ground truth, so diff-against-reference metrics penalize valid-but-different outputs. We present ACE, an agentic canvas editor over a hierarchical scene-graph with a presentation-specialized action space (98 tools), paired with CARE, a content-aware router that feeds the agent only the relevant slice of each deck (avg.\ ∼\sim89% input-token reduction), and a self-correction loop driven by a ground-truth-free instruction-following (IF) judge whose natural-language critique is fed back as the next-turn instruction. With a fixed backbone, a scene-graph editor in a single turn already matches a same-backbone agentic HTML pipeline that iterates internally; adding self-correction lifts ACE significantly above it on instruction following (IF 4.23 vs.\ 3.81 on the full 94-task benchmark, paired p=.010p{=}.010, replicated by an out-of-loop judge) at 1.75×\times the speed and ∼\sim44% lower cost. VQ means are statistically indistinguishable, but 26 blind raters prefer ACE overall (58.7% decisive win-rate) and prefer the self-corrected output 81% of the time; the ranking is invariant across three judge families, and out-of-loop judges retain two-thirds of the self-correction gain, bounding circularity. 66% of cases halt after one pass, and a strict-peak rollback removes every observed regression.

Figures & tables

Figure 1: Qualitative comparisons (each row: reference, ACE, Claude-Skill HTML, PPTArena). (a) Case 71, highlight only negative table cells; (b) Case 32, arrange image and text; (c) Case 42, organize a research poster; (d) Case 56, add pictures; (e) Case 61, sort rows by score and crop images to 16:9. Backbones: claude-sonnet-4-6 for ACE/HTML; gpt-5.5 judge. Because design has no unique ground truth, ACE’s edits often differ from the manual reference yet remain valid—what our reference-free IF judge rewards.
Figure 2: Overall architecture of ACE: the scene-graph editor and its 98-tool action space, CARE’s three-way context routing, and the self-correction loop driven by the ground-truth-free IF judge.
Figure 3: A slide, an example edit, and its data representations. (a,b) Case 112 increases the auto-layout children from five to seven and the frame re-flows automatically using auto-layout. (c) OOXML flattens the slide into absolutely positioned siblings (EMU coordinates, no grouping), while the SceneGraph encodes it as a parent–child tree with responsive auto-layout constraints.
Figure 4: The ACE workflow with CARE. CARE routes each instruction into one of three context scopes—Micro-Spatial (direct node editing), Macro-Programmatic (skeleton JSON for cross-slide batch scripting), and Systemic-Token (style metadata for design-system updates)—minimizing the agent’s context window load while preserving precision.
Figure 5: The human designer’s iterative workflow that ACE imitates: form a design intent, edit the original, inspect the result against that intent, and repeat until satisfied.
Figure 6: Self-correction on Case 54 ( gpt-5.5 backbone). Slide 1 (reference): the target design—cream background, centred company header, and horizontal rules—to propagate to slides 2–9. Origin: the rest of the deck before editing. Iteration 1 IF score = 3 (IF critique): the agent applied some key slide 1 layout elements to slides 2–9, including the cream background, centred company header, and horizontal rules, and shifted some content down, but it did not fully apply slide 1’s layout structure, left old footer text/elements, and some adjusted content does not fit cleanly within the new layout. Iteration 2 IF score = 4 (final): this critique becomes the next-turn instruction; the agent removes the residual footer elements and refits the displaced content, yielding a layout consistent with slide 1 across the deck—an instance of the loop in Algorithm 1 .
Figure 7: Qualitative example (Case 17, build ensemble category boards). ACE’s edit differs from the manual reference yet remains valid—what our reference-free judge rewards—while PPTArena fails to build the grid. Backbones: claude-sonnet-4-6 (ACE/HTML); gpt-5.5 judge. Further comparisons: Appendix N .
Appendix figures & tables6 assets

Supplementary material from the paper’s appendix.

Appendix

IDSimplified PromptDesign Dimension
C1Decompose AI-generated image into layered SVG components and create connectors.Asset Decomposition
C2Generate a 9-page presentation based on a template.Multi-page Synthesis
C3Find a suitable template for the reference image.Style Retrieval
C4Create a protein-food infographic from text (green theme).Creative Synthesis
C5Scale AutoLayout (5 to 6) and rearrange contents.Structural Scaling
C6Align list items using the AutoLayout system.Responsive Layout
Appendix
Table 12: Specifications for the 12 novel design tasks (Cases 101–112). Cases C2–C4 (102–104) are released without automatic scores.
Figure 8: Distribution of (a) reasoning turns and (b) total API operations. Both metrics exhibit long-tail characteristics, ensuring the benchmark tests both efficiency and endurance in long-horizon editing tasks.
Figure 9: Figma API operation distribution. The top 12 operation types account for the majority of the 2,454 total operations, spanning text styling, spatial layout, and element creation.
Figure 10: Task difficulty vs. input complexity. Each point is a task; x-axis: Figma nodes (log scale), y-axis: total API operations, point size: agent turns, color: unique operation types. High-density tasks like EducationalRockRecognition (148 nodes, 156 operations) highlight the benchmark’s focus on logic over raw scale.
Figure 11: Overview of the Figma-Slide benchmark (97 curated tasks). The grid displays 95 thumbnails: one origin is text-based (no thumbnail), and Case 112 is omitted because its source thumbnail is identical to that of Case 105.
Figure 12: Tool-execution efficiency on the same “Table-to-Chart” task. (a) The specialized create_graphics tool needs only 22 operations. (b) Forcing atomic primitives ( create_rectangle , etc.) yields a 3.0 ×\times increase (66 operations), inflating the “reasoning tax” and the chance of alignment errors.
More in this topic

Scene Graphs

See all 17 papers

Explore similar work

CardsList
Dec 2, 2025

PPTArena: A Benchmark for PowerPoint Editing

We introduce PPTArena, a benchmark for PowerPoint editing that evaluates how agents modify real slides from natural-language instructions. Unlike benchmarks that rely on image-PDF renderings or text-to-slide generation, PPTArena features 100 decks with over 1,300 human-curated edits across 2,125 slides, spanning text, charts, animations, and professional master styles. Each edit pairs a ground-truth deck with a target rubric and is scored by two Vision-Language Model (VLM) judges: one rates instruction following from structural diffs, the other visual quality from slide images. On top of this benchmark, we present PPTPilot, a structure-aware agent that plans semantic edit sequences, routes between programmatic tools and deterministic XML operations, and verifies each result in an iterative plan-edit-check loop. PPTPilot outperforms strong VLM-based agents by more than 10 percentage points on compound, layout-sensitive, and cross-slide edits, with large gains in visual fidelity and deck-wide consistency. Despite this, all agents still struggle on long-horizon, document-scale tasks, underscoring how hard reliable PowerPoint editing remains. We publicly release our code at https://github.com/michaelofengend/PPTArena .

Michael Ofengenden, Yunze Man, Ziqi Pang +2

University of Illinois Urbana-Champaign · University of California, Berkeley

LLM Agent EvaluationAI Agent BenchmarksTool-Using Agents
AskPDF
Sep 2, 2026

SLIDEFORGE: An LLM Agent for Controllable Editing of Slides as Structured Artifacts

Current AI agents compellingly describe slides. However, AI-assisted slide editing requires more than understanding: the output must retain layout, style, component structure, and native editability. Towards, AI-assisted slide editing, existing agents operate on screenshots or weak document representations and often fragment coherent visual units, rasterize editable content, or break layout. In contrast, for controllable slide editing, we introduce an agentic framework, SLIDEFORGE, which builds a Deck State Graph, an executable slide state that links visual decomposition, native pptx object structure, and perceptual organization. By recovering human-referable components while retaining fine-grained editable structure, SLIDEFORGE supports theme-preserving reconstruction through slide-native operations and rendered-state verification. We further introduce an evaluation paradigm for controllable slide transformation that jointly measures component recovery, preservation, restyling consistency, visual quality, and native editability. Experiments show that SLIDEFORGE outperforms direct prompting, screenshot-based agents, and generic code-agent baselines across these dimensions. Code is available at https://github.com/UIUC-MONET/SLIDEFORGE.

Haozhen Zheng, Fulin Wang, Tianhu Xiong +6

University of Illinois Urbana-Champaign · Meta

LLM Agents
AskPDF
Sep 26, 2026

"You're Right, Let Me Fix It": How LLM Agents Damage Correct Work When Falsely Accused

LLM agents increasingly keep working after a task succeeds as they resume after compaction or take over handoffs. Their finished work keeps receiving follow-up input that sometimes falsely accuses it for later failures. We call an agent's acceptance of such a false accusation gaslight sycophancy, and destructive over-correction when acting on it damages previously correct work. We introduce CAVE-Bench, a benchmark of 365 agentic tasks across six domains built around opaque tasks. Every scored run first reaches a verified correct state, whose supporting rationale and history stay in the workspace while the facts that would settle the accusation lie in external or runtime state beyond the agent's reach. The agent cannot confirm or refute the claim with a local check, so the right response should keep the work and ask for the missing evidence. Each task either hands the agent correct work with saved evidence or let it build and verify that work first, and five risk factors set how the accusation enters the workflow. We score accusation acceptance and evidence use from the trajectory and measure harm by deterministic replay of downstream events. Across 14 of the latest models in Claude Code, false accusations damage correct work in up to 60.06% of runs, and stronger models often do so after recovering the supporting evidence. The same model behaves differently across OpenCode, Codex, and Hermes, and a harness gate driven by the benchmark's live signals cuts replayed harm by 74%. These results show that preserving already-correct work under unsupported accusation is a distinct safety challenge for long-lived agents. Our project is in https://henrymao2004.github.io/agent-over-correction/.

Xutao Mao, Rui Qian, Longxiang Wang +6

City University of Hong Kong · Fudan University · Southeast University +2

LLM AgentsLLM Agent SafetyLLM Agent ReliabilityLLM SycophancyAI Agent Safety Benchmarks
AskPDF