When AI Generates PPTs, How Much Does Runtime Determine Their Quality?

Problem: PPT generation is one‑shot and lacks re‑usability

Consultants work with many historical slides; they need to locate pages, edit locally while preserving templates, and later let an agent resume work. Therefore a PPT must be an Artifact that can be inspected, addressed, modified and verified repeatedly.

Prototype

Implemented a PPT Agent prototype using PptxGenJS and python-pptx, source at phodal/claude-code-codex-slide. Modern LLMs can generate JavaScript that creates any PPT shape, but generated slides converge to a few common layouts (three‑column cards, four‑grid, timelines) because agents only use a tiny slice of the API.

Runtime concept

Introduce an Artifact Runtime that adds an operable layer on top of programmable APIs. The runtime supports a four‑step loop:

Observe – obtain current state of the presentation.

Address – assign stable identifiers to objects.

Operate – perform localized edits.

Verify – re‑inspect to confirm changes.

Inspect / Resolve workflow

inspect({ search: "Revenue" })
→ { "kind": "textbox", "id": "sh/c3d4e5f6", "name": "headline", "text": "Revenue outlook" }
resolve("sh/c3d4e5f6").text.replace("Revenue", "Revenue outlook")
inspect({ target: { id: "sh/c3d4e5f6" } })

The id (e.g., sh/c3d4e5f6) survives manual edits in PowerPoint, enabling the agent to locate the same object later.

From APIs to layout semantics

Adding more atomic APIs does not automatically increase expressiveness. Instead, the runtime must maintain relationships such as equal width, equal spacing, alignment, and wrap behavior so that layout can be recomputed when content changes.

Compose API (Artifact Tool)

Defines structure with row, column, grid and space allocation with fill and hug:

slide.compose(
  <row width="fill" gap={24}>
    <box width="fill" height="hug">ARR</box>
    <box width="fill" height="hug">NRR</box>
    <box width="fill" height="hug">Churn</box>
    <box width="fill" height="hug">Payback</box>
  </row>
)

Domain semantics

Layout primitives describe geometry only. Mapping them to domain objects (e.g., metric cards, service dependencies, architectural stages) lets the runtime inherit styles, adjust layouts, and verify readability without the agent handling low‑level details.

Boundary of Runtime

Runtime handles engineering concerns—object addressing, layout solving, format conversion—while the agent retains responsibility for narrative structure and professional judgment. The user perceives stable layouts, preserved templates, and seamless hand‑off.

Conclusion

Moving from programmable generation to expressive creation is achieved not by adding more APIs but by letting an Artifact Runtime take over repeatable engineering tasks, allowing agents to focus on high‑level intent.