How to Build a Slide Generator AI That Actually Works

The Core Components of a Slide Generator AI

You have a 10-page report that needs to become a 15-slide deck for a meeting tomorrow. The old way is a three-hour slog of copying, pasting, and summarizing until your eyes glaze over. The new way is to build a machine to do it for you. This isn’t about finding a single magic app; it’s about building a small, focused automation pipeline. After reading this, you’ll know exactly how to build your own slide generator AI.

This kind of system has three main parts. Get these right, and the rest is just assembly.

• The Brain: This is your Large Language Model (LLM). You need something that’s good at following complex instructions and structuring its output. Your main contenders are OpenAI’s GPT-4o and Anthropic’s Claude 3 Opus. I find Opus is slightly better for summarizing dense, jargon-heavy text without losing nuance. GPT-4o is faster and cheaper, which makes it great for iterating. For this build, we’ll use GPT-4o because the cost is negligible and the speed helps during testing.
• The Orchestrator: This is the glue that connects the steps. It’s a no-code automation platform. Your best bets are Make.com or n8n. I use both, but for this walkthrough, Make.com is easier to visualize. It’s a visual workflow builder that moves data from one step to the next. If you’ve tried Zapier automations, you know what I mean, but Make is more flexible for multi-step, conditional logic.
• The Renderer: This is the tool that actually creates the presentation file. The two practical options are the Google Slides API and the Canva API. The Canva API can produce prettier results out of the box, but it’s more complex and has associated costs. The Google Slides API is free, powerful, and integrated into an ecosystem you likely already use. We’ll stick with Google Slides.

That’s the stack: OpenAI for thinking, Make.com for plumbing, and Google Slides for the final output.

What Most Guides Get Wrong About This

Almost every tutorial I’ve seen on this topic makes the same fundamental mistake. They try to do everything in a single, massive prompt. They feed the entire source document to an LLM and say, “Turn this into a 10-slide presentation with speaker notes and image suggestions.”

This approach fails miserably in production.

A single mega-prompt creates a single point of failure. The LLM has to simultaneously be a summarizer, an outliner, a copywriter, and a creative director. It gets confused. It will repeat points, miscount the slides, invent facts, and generate speaker notes that are just rephrased bullet points. The output is generic, unreliable, and requires heavy editing, which defeats the entire purpose of the automation.

The correct approach is to break the problem down into a chain of specialized prompts. Each step in the chain is a small, focused AI agent with one job. This is the core idea behind a real operator playbook: don’t build a monolith, build an assembly line. One agent summarizes. Another creates an outline. A third writes the content for each slide, one by one. This modularity makes the system more reliable, easier to debug, and capable of producing much higher-quality output.

Step-by-Step: The Prompt Chain for Generating a Deck

Here’s the assembly line logic. This is a sequence of API calls, orchestrated by Make.com, where the output of one step becomes the input for the next.

1. The Summarizer Agent: The first step is to distill the source text. Don’t ask for slides yet. Just ask for the core components. The prompt’s only job is to extract the main argument and supporting pillars. Critically, you must demand structured output like JSON.
   Your input is a long-form document. Your task is to extract its core components. Analyze the text and return a JSON object with three keys: 'thesis' (a single sentence summarizing the main point), 'supporting_points' (an array of 3-5 key arguments or topics as strings), and 'cta' (the primary call to action or concluding thought, as a string). Output only the valid JSON.
2. The Outline Agent: This agent takes the JSON from the Summarizer. Its job is to structure the presentation, not write it. It maps the core components to a slide structure.
   You will receive a JSON object containing a thesis, supporting points, and a CTA. Your task is to create a slide-by-slide outline for a presentation. Return a JSON array where each object represents a slide and has two keys: 'slide_title' (a short, punchy title) and 'slide_type' (one of: 'Title', 'Content', 'Image_Highlight', 'CTA'). Create a title slide, one slide for each supporting point, and a final CTA slide.
3. The Content Expansion Agent: This is where the magic happens. Your orchestrator (Make.com) will loop through the JSON array created by the Outline Agent. For *each slide object*, it calls this agent. This focus is what guarantees quality.
   You are an expert presentation writer. You will receive the title for a single slide. Your task is to write the content for this one slide. Return a JSON object with two keys: 'bullet_points' (an array of 2-4 short, concise bullet points for the slide body) and 'speaker_notes' (a detailed paragraph of 100-150 words for the presenter to read, adding context, anecdotes, or data).
4. The Visuals Agent (Optional but Recommended): Inside that same loop, you can add another call. This agent takes the bullet points for the slide and suggests an image. The key is to ask for concepts, not just keywords.
   Based on these bullet points: [insert bullet points from previous step], suggest a compelling visual concept for this slide. Describe the image, diagram, or chart. Be specific. Example: 'A diagram showing a linear process with four labeled steps' instead of 'workflow'.

This multi-agent chain transforms one big, unreliable task into a series of small, reliable ones. It’s a foundational pattern for building any serious no-code AI system.

Is the Google Slides API Actually Hard to Use?

This is a fair question. The short answer is no, the API itself is logical. But the initial setup is a bureaucratic nightmare.

My biggest gripe is with the authentication process in Google Cloud Platform. To get the credentials your script needs, you have to navigate a maze of projects, service accounts, IAM roles, and enabling the correct API library. The documentation assumes you’re a full-time developer on a corporate team. It’s overkill for a solo operator just trying to automate a deck. Honestly, expect to lose an hour or two to this the first time you do it, clicking through menus and wondering why your permissions are denied — and good luck finding clear docs for this specific use case.

But once you’re past that hurdle, there’s a specific feature I absolutely love: the presentations.batchUpdate endpoint. Instead of making separate API calls to create a slide, add a title, add a text box, and insert bullet points, you can bundle all those commands into a single request. This is incredibly efficient. You construct a list of instructions and send them all at once. This reduces the number of API calls, simplifies your automation logic in Make.com, and makes the whole process run faster. It’s the right way to interact with the API.

A Real-World Example with Make.com and OpenAI

Let’s map this to a real scenario. You want to feed the system a blog post URL and get a presentation back. Here’s the stack and the flow in Make.com.

The stack: Make.com for orchestration, OpenAI GPT-4o for the LLM calls, and the connected Google Slides app.

The price: Make.com’s Core plan at $29/mo is fair and what I’d recommend. It gives you enough operations for this and other projects. The free plan is a joke for anything more than a two-step flow; you’ll hit the limits immediately. The OpenAI API cost for generating a full 12-slide deck from a 2000-word article is laughably low, maybe $0.15 with GPT-4o. It’s essentially free at small scale.

Here’s the workflow you’d build:

• Trigger: A simple webhook or even a new row in a Google Sheet containing a URL.
• Module 1: HTTP ‘Get a file’. This module fetches the raw HTML from the provided blog post URL.
• Module 2: HTML to Text. A built-in Make.com module that strips out all the code and leaves you with clean text content.
• Module 3: OpenAI ‘Create a Completion’. This is your Summarizer Agent. You feed it the clean text and use the prompt from the previous section.
• Module 4: OpenAI ‘Create a Completion’. This is your Outline Agent. It takes the JSON output from Module 3 as its input.
• Module 5: JSON ‘Parse JSON’. This converts the JSON string from the outline agent into a usable data structure that Make.com can iterate over.
• Module 6: Google Slides ‘Create a Presentation’. This creates the blank deck and gives you the Presentation ID you’ll need for the next steps.
• Module 7: Iterator. This module takes the array of slides from Module 5 and processes them one by one. The following modules will run once for each slide in your outline.
• Module 8 (inside Iterator): OpenAI ‘Create a Completion’. This is the Content Expansion Agent. It generates bullet points and speaker notes for the current slide in the loop.
• Module 9 (inside Iterator): Google Slides ‘Create a Slide’. This uses the Presentation ID from Module 6 and the title from the current slide data to add a new slide to your deck. It then populates it with the content from Module 8.

This flow is a perfect example of an AI automation blueprint. It’s a repeatable, scalable process that turns raw information into a finished asset.

How to Debug When This Breaks

Your most frequent point of failure will be the LLM outputting malformed JSON. You’ll ask for a perfectly structured JSON object, and it will send you one with a missing comma, a trailing apology, or—my personal favorite—wrapped in markdown code fences like … . This will cause the ‘Parse JSON’ module in your orchestrator to fail, and the whole run will stop.

There are two ways to handle this.

First, improve your prompt defense. Go back to every prompt that is supposed to return JSON and add a line to the system message or at the end of the prompt: “You are a machine that outputs only valid, RFC 8259 compliant JSON. Do not include any preamble, conversational text, or markdown code fences. Your entire response must be the JSON object itself.” This simple instruction solves the problem about 90% of the time.

Second, for the remaining 10%, build a recovery route. In Make.com, you can add error handling to any module. On the ‘Parse JSON’ module, add an error handler that triggers another LLM call. This is your ‘Fixer Agent’. The prompt is simple: “The following text is supposed to be valid JSON but is broken. Please fix it and return only the corrected, valid JSON. Do not add any explanation. Here is the broken text: [insert the faulty output from the previous step].” The output of this fixer agent then flows back into your main process. This makes your automation far more resilient and is a key technique for building systems you can actually rely on.

Building this entire workflow from scratch involves a lot of trial and error with prompts, API docs, and data mapping. It’s a solid weekend project.

Adjacent reading: deeper coverage of AI agent platforms.

If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this workflow as a blueprint at deepusecase.com/vault.