MultiAgentPPT: A2A, MCP and ADK for streamed presentation generation

MultiAgentPPT's multi-agent presentation pipeline

MultiAgentPPT addresses the problem of turning a broad topic into a structured, researched presentation rather than asking one model prompt to produce an entire deck in one response. It is intended for developers experimenting with agent orchestration, editable presentation content and streamed user interfaces. The documented workflow begins with an Outline Agent, passes the outline through topic splitting, assigns research to multiple Research Agents, and then sends their results to a Summary Agent. The frontend can display the generation process while the backend works through the deck.

The repository separates simple and retrieval-backed implementations. `simpleOutline` provides a simplified outline service without external dependencies, while `slide_outline` generates a higher-quality outline after MCP retrieval. `simplePPT` provides a simplified presentation service without retrieval or concurrency. `slide_agent` is the main multi-agent implementation for generating complete presentation content, with the README describing concurrent research and XML-format slide content. This split is useful for understanding the system incrementally, but it also means that a reader must choose between mutually exclusive service ports rather than run every component at once.

MCP retrieval and concurrent research in slide_agent

The main collaboration flow starts when a user supplies research content. The system calls the Outline Agent, retrieves material through MCP, produces an outline and waits for the user to confirm it. Once confirmed, the outline is sent to the presentation generation service. A Split Outline Agent divides it into topics, and a Parallel Agent starts separate Research Agents. Each research branch performs automatic knowledge-base retrieval through RAG before its output reaches the shared Summary Agent.

After research results are combined, a Loop PPT Agent generates slides one page at a time. The documented loop contains a Write PPT Agent and a Check PPT Agent. The checker inspects each page and can send it back for regeneration, with the diagram stating a maximum of three retries. The README says `page_number` is used as the unique identifier for each page, replacing title-based identification. That change supports content updates and proofreading, although it makes correct page numbering important to the frontend and rendering path.

The architecture also includes metadata transfer from the frontend to agents and progress details in `slide_agent`. The repository layout provides separate backend services, but the README does not document a message schema, retry backoff, persistence behavior for interrupted runs, or the exact protocol used between the agents. Those details should be checked in the service code before adopting the pipeline as a production foundation.

Streaming output, image handling and PPTX export

MultiAgentPPT presents streaming as a core interaction feature. The outline and generated page content are returned progressively, and the frontend shows the state of each agent's work. The README also records a change to image rendering. Background images use the `object-cover` style, while non-background images use `object-contain` and display explanatory text. This distinction is useful because it prevents every image from being treated as a full-slide background.

The download path is server-side. Frontend JSON data is sent through the Python backend, where `python-pptx` renders the downloadable file. The frontend environment includes `DOWNLOAD_SLIDES_URL="http://localhost:10021"`, which indicates a separate download service endpoint, although the backend startup table does not document the command or port assignment for that service. A first deployment therefore needs configuration review rather than assuming that `slide_agent` alone provides the download endpoint.

The README lists integration of an editable and downloadable PPTX frontend as unfinished. In other words, online editing is part of the intended direction, but the current documented task list does not establish that the complete editor is available. The repository also warns that the built-in research example is “Electric Vehicle Development Overview.” Other topics require prompt changes and a corresponding MCP tool, so the included example should not be mistaken for a general-purpose research corpus.

Local backend setup and the first outline service

The README recommends Python 3.12 and creates a Conda environment before installing the backend dependencies. The commands below create the environment, enter `backend`, install its requirements and copy each module's environment template. Run the module-specific commands from the repository root as shown.

conda create --name multiagent python=3.12
conda activate multiagent
cd backend
pip install -r requirements.txt
cd simpleOutline && cp env_template .env
cd ../simplePPT && cp env_template .env
cd ../slide_outline && cp env_template .env
cd ../slide_agent && cp env_template .env

The documentation says each copied file must be edited for the relevant service. It does not list the required environment variables or model-provider credentials, so configuration cannot be completed from the README alone. After configuration, a module can be started with `python main_api.py`. The documented default ports are 10001 for `simpleOutline` and 10011 for `simplePPT`. For the retrieval-backed route, `slide_outline` also uses 10001 and requires `simpleOutline` to be closed, while `slide_agent` uses 10011 and requires `simplePPT` to be closed.

For the first real use, start only the outline service, open the frontend and submit the built-in electric vehicle topic. The frontend should show a streamed outline that can be confirmed before slide generation. That sequence validates configuration without immediately depending on the full concurrent generation and download path.

Frontend PostgreSQL and download configuration

The frontend is a Next.js application and uses PostgreSQL to store generated presentations. The README provides two Docker commands, one using the `postgres` image and one using a mirrored `postgresql:15` image. The choice depends on network access. Both commands map PostgreSQL to port 5432 and use the credentials shown below.

docker run --name postgresdb -p 5432:5432 -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=welcome -d postgres

After starting the database, the frontend environment must contain the exact values documented in the README. `DATABASE_URL` targets the `presentation_ai` database, while `A2A_AGENT_OUTLINE_URL` and `A2A_AGENT_SLIDES_URL` point to the backend services on ports 10001 and 10011.

DATABASE_URL="postgresql://postgres:welcome@localhost:5432/presentation_ai"
A2A_AGENT_OUTLINE_URL="http://localhost:10001"
A2A_AGENT_SLIDES_URL="http://localhost:10011"
DOWNLOAD_SLIDES_URL="http://localhost:10021"

Install the frontend packages, push the database models and start the development server with the documented commands. The database name in `DATABASE_URL` must exist according to the local PostgreSQL setup; the README does not give a separate database-creation command.

cp env_template .env
pnpm install
pnpm db:push
npm run dev

The documented page is `http://localhost:3000/presentation`. The combination of `pnpm install` and `npm run dev` is intentional in the README, so a replacement package runner should not be assumed. The repository also offers Docker Compose, but it explicitly asks the user to inspect `docker-compose.yml` and each directory's `Dockerfile` before using it.

Maintenance status and the TrainPPTAgent replacement

The repository is not marked as archived, and its last push was on 2026-10-14. However, the README explicitly says that the current version is no longer maintained because the PPT content and templates cannot be maintained well. It recommends a new, more enterprise-oriented template-based project called TrainPPTAgent at `https://github.com/johnson7788/TrainPPTAgent`.

That distinction matters. A recent commit does not resolve the maintainer's stated project-status warning. There are also no GitHub releases, so there is no documented release cadence or upgrade series to rely on. For an organization considering MultiAgentPPT, the relevant maintenance cost includes evaluating a fork, checking how local changes survive updates, and deciding whether to migrate concepts into TrainPPTAgent instead. The MIT license permits use and modification under its terms, but license compliance and suitability of third-party models, APIs, templates and MCP tools remain separate checks.

The TODO list also leaves integration of an editable and downloadable PPTX frontend unfinished. That is a product limitation, not merely a missing convenience feature. The architecture is therefore more appropriate for a controlled prototype or reference implementation than for a system whose main requirement is dependable template maintenance.

Why a single-agent or template-first pipeline may fit better

A single-agent presentation generator is a different approach: one model or one controlled pipeline receives the topic and produces the outline and pages sequentially. It has fewer service boundaries, fewer port and environment configurations, and fewer agent-message contracts to inspect. Its trade-off is that research, topic splitting, summarization and page checking are not isolated as separate executable stages.

TrainPPTAgent is the more direct alternative named by the project maintainer. The README recommends its template-oriented approach and describes it as the more enterprise-oriented version. That recommendation specifically addresses the stated difficulty of maintaining MultiAgentPPT's content and templates. It does not mean that TrainPPTAgent is documented here as a drop-in replacement, nor does it establish equivalent A2A, MCP or ADK capabilities.

For evaluation purposes, MultiAgentPPT is the stronger reference when the goal is to inspect concurrent research, streamed progress, per-page checking and Python service orchestration. A template-first or single-agent approach is more practical when predictable slide structure, centralized template ownership and fewer runtime services matter more than an agent-by-agent research pipeline.

Editorial conclusion

MultiAgentPPT suits engineers who want to study or fork a concrete A2A, MCP and ADK presentation pipeline, especially when streaming per-slide generation and concurrent research are useful. It is a poor production choice for teams expecting ongoing template maintenance, a finished online PPTX editor, rollback documentation or a stable replacement roadmap in this repository. Check the module port conflicts, environment templates, real MCP and RAG data sources, and the incomplete PPTX editing path first. For a maintained template-oriented system, the README directs users to TrainPPTAgent.

Frequently asked questions

Official sources

1. Issues
2. johnson7788/MultiAgentPPT on GitHub
3. License: MIT
4. README