03/Enterprise AI

Agentic Decks

An AI agent that writes a complete, on-brand PowerPoint deck from a conversation — then edits any deck you already have, including ones it never wrote.

Domain: Enterprise AI · document automation
Status: Live in production

The challenge

Building a deck is one of the most common and least enjoyable pieces of knowledge work there is, and the options were both bad. Do it by hand and lose hours to layout. Ask a general-purpose LLM and get a wall of bullet text that still has to be designed by a human — output that doesn't survive contact with the real file format. Text overruns its box, the visual language changes every slide, and what comes back is usually a web page or an image rather than a genuine, editable PowerPoint file someone can take into a meeting.

The larger gap was on the other side. Almost every AI presentation tool abandons the user the moment they already have a deck — and real work is rarely a blank canvas. It's last quarter's board deck that needs restyling, a partner's file that has to move into the company template, one slide somebody wants rebuilt around a different layout. Doing that by hand is slide-by-slide manual labour. Doing it naively with an LLM means letting a model rewrite a binary Office document, which is a fast route to a file the customer's PowerPoint refuses to open.

Nothing on the market let a user upload their own deck and talk to it with any confidence that the file would still work afterwards.

Our role

Sole owner of the presentation capability inside a larger product team, end to end: the agent architecture — multi-step deck generation, the conversational editor, and the intent layer that decides when to build, when to edit and when to stop and ask a question; the Python services, persistence, streamed progress and file delivery behind it; the document engine for reading and safely modifying native PowerPoint files, and the agent-facing tool surface exposing it; the design system and the renderer that converts a rendered design into a real .pptx; and a variant of the whole feature for a compliance-constrained environment where an entire class of third-party dependency wasn't permitted.

The surrounding chat product, its authentication, and infrastructure ownership were not ours. We integrated into those.

What we built

Pillar A — Create a deck by talking

The user just asks. The agent works out whether it has enough to go on and asks for what's missing — how long, who for — instead of quietly guessing. A deck can be grounded on four things: a topic, an uploaded PDF or Word document, the conversation the user has already been having, or analysis produced elsewhere in the product.

From there it reads or researches the source, plans the entire deck before writing any of it, and puts that plan through a review pass for narrative flow, balance and variety — so a weak structure is caught while it's still cheap to fix. Only then are the slides written, many at once, each assigned a real designed layout from a large template library rather than poured into a generic bullet list. Imagery is sourced or generated to match. What arrives is a genuine PowerPoint file the user can open and keep working in.

And it doesn't stop at delivery. The user keeps talking — "make slide three shorter", "swap that image", "add a closing slide". The deck is edited in place, only the affected slides are rebuilt, and the updated file comes straight back.

Pillar B — Bring your own deck

Precise editing — wording, fonts, colours, sizes, bullets, tables, chart data, speaker notes, pictures, and deck-wide theme colours and fonts.
Layout intelligence — align, distribute, arrange into a grid, place one shape relative to another, centre on the slide. The system quietly keeps shapes on the slide and off each other, and tells the agent when it has adjusted something so the agent can explain it.
Whole-slide redesign — pick, or have the agent search for, a layout from a curated bank of professionally designed slides, and have an existing slide rebuilt into it. The user's own theme, colours and branding are kept; content is reflowed and pictures matched. The same path authors a brand-new slide from a one-line brief.
Deck migration — stage a foreign deck alongside the user's own and move it across wholesale. Every slide gets a proposed layout in the user's template; the user reviews and edits that plan before anything is written; then the deck is rebuilt slide by slide on their branding, carrying tables, charts, images and speaker notes across.

Everything is versioned. Each change is a discrete recorded step, the history is visible, any earlier point can be restored, and the original upload is never modified.

What makes this AI-powered rather than a set of buttons: every capability above is exposed to the model as a tool, so the assistant plans and composes them itself. It decides which layout suits a slide, how content should be redistributed into a new arrangement, what a picture should show — and when to ask a clarifying question instead of acting on a guess.

Stack

Technology stack, by layer
Layer	What we used
AI / ML	GPT-class reasoning models on Azure OpenAI, tiered by task LangGraph and LangChain for orchestration an MCP tool server schema-constrained structured output (Pydantic) retrieval-augmented grounding over uploaded PDF/Word with vector search CPU-only static embeddings for layout retrieval stock-photo APIs and generative image models
Frontend	React Next.js (App Router) TypeScript Tailwind CSS — a large library of slide designs authored as components server-sent events for streamed progress and chat
Backend	Python FastAPI MongoDB python-pptx and lxml working directly against the OOXML package headless Chromium for layout measurement Pydantic throughout
Infrastructure	Docker, one image with a Node sidecar Kubernetes with multiple replicas and blue/green rollouts Azure Blob Storage with short-lived signed URLs Azure OpenAI CI on push structured logging with per-run tracing

Decisions

Decision01

Making an LLM safe to point at a binary document format

The obvious design — let the model write the file — is the one that fails in production. An Office document is a bundle of interdependent XML parts. A small mistake doesn't produce a slightly wrong slide, it produces a file PowerPoint refuses to open. A user who sees that once stops trusting the product entirely.

So the model never writes the file. It chooses from a closed vocabulary of typed, validated operations, and a deterministic engine applies them. Everything a user could want — retype a line, recolour a shape, move a picture, add a table row, swap a theme font, rebuild a whole slide — is one of those operations.

The payoff compounds. Every edit is validated before it touches anything, and a batch either fully applies or fully rolls back. The edit history is a recorded sequence, so undo is exact rather than approximate. The original upload is never mutated. And an entire failure class — the model emitted markup that corrupted the deck — simply doesn't exist. It also made the engine unit-testable, which is why it carries a real test suite instead of being verified by opening files and squinting at them.

Decision02

One source of truth for how a slide looks

A deck has to look right in two places: in the product's own preview, and in PowerPoint on somebody else's laptop. The tempting approach is two layout implementations, one per target — and they drift within weeks.

Instead the design system is authored once, as web components, and the native file is derived from what that design system actually rendered rather than laid out a second time from scratch. Adding a new slide design became a front-end task rather than a two-sided one, which is why the library grew to twenty-one visual families without fidelity falling apart.

Two supporting rules made it hold. If the renderer is unavailable the build fails loudly rather than silently shipping a bland, unstyled deck — a plausible-looking wrong output is far worse than an honest error, because the user can't tell it went wrong. And length budgets are advertised to the writer up front, so text is written to fit its box rather than truncated after the fact.

Results

Slide design families

Results
Status	Live in public production since August 2026
Slide design families	21, authored once and rendered to both preview and native file
Corrupted-file failure class	Eliminated by construction — the model never writes the file
Compliance variant	A full build of the feature for an environment where a whole class of third-party dependency was not permitted

Building something like this?Get a quote