AutoSlides · internal explainer · for the curious, not the experts

How it works
& why we built it this way

AutoSlides turns one written brief into a real, editable Google Slides deck — built in our BBC 2026 template, in our house voice, ready to open in your own Drive. This page explains what happens under the hood, in plain language, and the choices behind it.

Audience: AI-curious colleagues Status: proof of concept Read time: ~10 min
01

The one big idea

If you remember nothing else, remember this:

The key move

The AI never designs a slide. It only does two things a language model is genuinely good at: pick which of our pre-built template layouts to use, and write the words that go on them. Google Slides then assembles the actual deck by copying our template.

That single decision is what makes the output trustworthy. Asking an AI to invent a slide pixel-by-pixel gives you off-brand fonts, wonky spacing, and surprises. Instead, our designers built a master template — one polished slide per layout (cover, section divider, three-column, pyramid, pull-quote, big-number, and so on). Every editable piece of text on those slides is a labelled blank, written as {{title}}, {{subtitle}}, {{quote}}, etc.

The AI reads a menu of those layouts, chooses a sequence that tells a story, and fills in the blanks with copy. The result is always on-brand and fully editable — it opens as a normal Google Slides file you can keep tweaking by hand.

Think of it less like "AI generates a presentation" and more like a very fast junior strategist who knows our template inside out, writes a first draft of every slide, and hands it to you to refine.

02

The pipeline, end to end

Three players pass work between them: your browser, our small server (a handful of functions under /api), and two outside services — OpenAI (the language model that plans) and Google (which stores and builds the actual deck).

Two of these steps — planning and building — can take a minute or more, so they stream: the story arc and each finished slide appear live as the AI writes them, and the build reports each stage ("copying the template…", "writing the copy…") as it happens. You're never staring at a frozen spinner wondering if it broke.

03

What happens when you use it

  1. Sign in with your BBC Google account

    This proves you're one of us and — crucially — lets the app act as you when it talks to Google. The finished deck lands in your own Drive, not some shared service account.

  2. Write a brief → "Plan slides"

    You type what the deck is about (a dice button rolls in fully-worked example briefs). The AI responds with a narrative — the story the deck will tell — followed by every slide: which layout, the copy for each blank, and speaker notes. It all appears live, slide by slide.

  3. Review & refine — you're the editor

    Nothing is built yet; this is just a plan. You can edit any text inline, reorder slides (↑/↓), remove ones you don't want, tweak the speaker notes, or type feedback like "merge slides 3 and 4, punchier tone" and have the AI revise the whole plan while keeping the story coherent. Each card shows a thumbnail of its layout.

  4. Name it → "Build deck"

    The server copies the master template into your Drive, keeps only the layouts you chose (in your order), swaps every {{blank}} for your copy, writes the speaker notes, and hands back a link. Open it — it's a normal, editable Google Slides presentation.

Your brief, the edited plan and the last result are saved in your browser, so a refresh doesn't lose your work.

04

How we "teach" the AI

The AI doesn't magically know our template or our house style. Every request carries a long system prompt — a set of standing instructions — that does three jobs:

Your brief is then added as the user's message, and the AI must reply in a strict, machine-readable format (more on that below). When you ask for a revision, we replay the previous plan back to the AI and ask it to change only what you questioned.

The exact wording lives in prompt.md in the repo — it's readable, and tuning it is most of how the output gets better over time.

05

The paths we chose, and why

Every interesting system is a stack of trade-offs. Here are the ones that shaped AutoSlides.

Approach

Fill a template — don't generate slides from scratch

WhyBrand fidelity and editability. The deck is literally our designers' template with the words swapped in, so it can't drift off-brand, and it opens as a normal, hand-editable Slides file.
Trade-offThe AI can only produce layouts that already exist in the template. New visual ideas mean a designer adds a layout first.
Scope

Give the AI a narrow job: choose & write, not design

WhyLanguage models are excellent at judgement (which layout fits) and prose (the copy), and unreliable at precise visual layout. We lean entirely on their strengths.
Trade-offVisual variety is bounded by the template library — by design.
Quality

Make it write the story first, slides second

WhyThis was the single biggest quality fix. Forcing the AI to commit to a narrative arc up front — and to state each slide's purpose and how it follows the previous one — makes the deck read as one coherent argument instead of disconnected slides.
Trade-offA little more thinking time per deck; well worth it.
Reliability

Demand a strict, structured answer (not free text)

WhyWe ask the AI for a rigid JSON shape with a fixed schema, so the server can build a deck from it mechanically — no fragile guessing about what the AI "meant". Unknown layouts and stray fields are filtered out server-side.
Trade-offThe schema needs maintaining, and a quirk of strict mode means copy is passed as key/value pairs rather than a plain object.
Maintainability

One file describes the whole template

WhyThe layout list, the AI's menu, and the build step all read from the same _registry.json. The template is the single source of truth; the rest follows automatically.
Trade-offEdit the template and you must update that file (and re-render thumbnails) or things silently mismatch. We name an owner for it.
Correctness

Let the server fill what computers do better

WhySlide numbering and today's date are filled in by the server and hidden from the AI entirely. The model doesn't reliably know the date and shouldn't be hand-numbering chapters — so it never sees those blanks.
Trade-offA bit of bookkeeping to keep those "derived" fields out of the AI's view, including during revisions.
Control

Human in the loop, always

WhyThe AI produces a plan, not a finished deck. You edit, reorder and refine before anything is built. AI drafts; a person decides.
Trade-offIt's a two-step flow (plan, then build), not one magic button — intentionally.
Voice

Bake in the house style — and ban invention

WhyDetailed copy rules make the output sound like BBC reporting back finished strategy work. The hard rule "never invent a quote, name or figure" keeps the deck grounded in what you actually gave it.
Trade-offA thin brief yields thinner decks — the AI won't paper over gaps with fiction. That's the safe failure.
Experience

Stream everything live

WhyPlanning and building take time. Showing the narrative and each slide as they're written (and each build stage as it runs) keeps the wait legible and lets you read along.
Trade-offStreaming a half-written answer needs a forgiving parser that can read an incomplete document — a bit of extra plumbing.
Security

Secrets on the server; the deck is built as you

WhyOur OpenAI key and template ID never leave the server. Google access is granted in your browser, so decks land in your Drive — the app never holds a master key to everyone's files. Only signed-in @bbc.be accounts can reach the API at all, so strangers can't spend our AI budget.
Trade-offYou sign in with Google, and access tokens expire after about an hour (the app re-prompts automatically).
Hosting

Run it in Europe, on Google Cloud Run

WhyBriefs contain confidential client strategy, so we keep traffic in the EU (europe-west1, Belgium) and inside the Google project we already use for sign-in. It scales to zero, so idle cost is essentially nothing.
Trade-offA few-second "cold start" after a quiet spell, and we own a small deploy step. We picked it over US-default hosts on data-residency grounds.
06

What it deliberately won't do

It's a proof of concept, and honest about its edges:

07

Plain-language glossary

Large Language Model (LLM)
The AI behind the planning — here, OpenAI's GPT model. It predicts text, which makes it good at choosing layouts and writing copy when given clear instructions and material.
Prompt
The text you send the AI. We wrap your brief inside a much larger "system prompt" of standing instructions before it ever reaches the model.
Structured / JSON output
Forcing the AI to answer in a strict, predefined data shape instead of free prose, so software can act on it reliably.
Placeholder / token
A labelled blank in the template, written like {{title}}. The build step finds each one and replaces it with the AI's copy.
Registry
One file (_registry.json) listing every template layout — its name, when to use it, and its blanks. The single source of truth.
Streaming
Sending the answer piece by piece as it's produced, so you see the deck appear live rather than all at once at the end.
OAuth / access token
The "sign in with Google" handshake. It gives the app a short-lived pass to act on your behalf — so decks are built into your own Drive.
Cloud Run
Google's service for running our app on demand. It wakes up for a request, runs, and sleeps again — cheap, and hosted in the EU.