Prompts de Sistema para Agentes de IA de Apresentação: Um Guia para Desenvolvedores (2026)

Prompts de sistema para agentes de IA de apresentação são diferentes de prompts de usuário — eles codificam o papel do agente, restrições e contrato de saída em vez da tarefa específica. Um prompt de sistema bem elaborado transforma um LLM genérico em um agente de geração de slides confiável: voz consistente, estrutura previsível e uso de ferramentas invocável. Este guia para desenvolvedores cobre o template de prompt de sistema de 7 seções usado em produção pelo próprio pipeline de agente do 2Slides, um prompt de sistema pronto para colar para construir um agente de slides com Claude, GPT-4o ou DeepSeek, os três anti-padrões que produzem saída não confiável, e como integrar um prompt de sistema com a API V1 do 2Slides (generate, create-pdf-slides, create-like-this, generate-narration, jobs/:id, themes/search). O guia termina com três exemplos práticos: um agente de pitch-deck que converte notas de fundadores em decks para investidores, um agente de board-deck que formata métricas trimestrais para audiências executivas, e um agente de ingestão que converte PDFs em apresentações.

Se você está construindo um chatbot, um assistente de codificação que gera saída de slides, ou uma ferramenta interna que automatiza relatórios, a diferença entre uma demo e produção está quase inteiramente no prompt de sistema. Este guia é escrito para o público de desenvolvedores: sem floreios de marketing, código real, endpoints reais.

Prompts de Sistema vs Prompts de Usuário: Qual é a Diferença Real?

Um prompt de usuário é a tarefa. Um prompt de sistema é o manual de operações.

Quando um gerente de produto digita "faça 10 slides sobre a receita do 3º trimestre", isso é um prompt de usuário. Quando seu agente retorna consistentemente JSON válido, nunca excede seu orçamento de slides, sempre cita fontes nas notas do apresentador e chama o endpoint

quando o usuário carrega um arquivo — esse comportamento vem do prompt de sistema.

Nas APIs do OpenAI, Anthropic e Google, o prompt de sistema é um campo separado (

no Anthropic, função nas completions de chat do OpenAI, no Gemini). Os modelos são treinados para dar mais peso a ele do que às interações do usuário e para tratá-lo como não substituível por mensagens posteriores. Isso o torna o lugar certo para:

• Definição de função — que tipo de agente é este
• Contratos de saída — schema JSON, formato markdown ou estrutura de chamada de ferramentas
• Restrições rígidas — limites de palavras, regras de tom, conteúdo proibido
• Inventário de ferramentas/API — quais funções podem ser chamadas e quando
• Regras de escalação — quando recusar, pedir esclarecimento ou transferir

Prompts de usuário que tentam codificar tudo isso quebram no momento em que o texto da tarefa do usuário fica longo. Prompts de sistema sobrevivem a cada interação.

O Template de Prompt de Sistema de 7 Seções

Cada agente de geração de slides confiável que lançamos ou auditamos na 2Slides usa alguma variante desta estrutura de sete seções. A ordem importa — LLMs dão mais peso às instruções iniciais, então papel e contrato vêm primeiro, exemplos práticos vêm por último.

1. Identidade & Papel — descrição de um parágrafo sobre quem é o agente e o que ele faz
2. Contrato de Saída — schema ou formato exato que o agente deve retornar
3. Restrições Rígidas — regras não negociáveis (comprimento, tom, padrões proibidos)
4. Inventário de Ferramentas — cada API ou função disponível, com orientação de quando chamar
5. Política de Raciocínio — como o agente deve pensar (cadeia de pensamento, auto-verificação, escalação)
6. Tratamento de Falhas — o que fazer quando a entrada é ambígua, malformada ou fora do tópico
7. Exemplos Práticos — dois a quatro pares completos de entrada/saída demonstrando comportamento correto

O template é deliberadamente opinativo. Quando auditamos agentes que se comportam mal em produção, a causa é quase sempre uma seção faltando em vez de uma seção ruim. Agentes sem inventário de ferramentas alucinam endpoints. Agentes sem seção de tratamento de falhas inventam dados quando as entradas são escassas. Agentes sem exemplos práticos desviam o tom ao longo de conversas longas.

Identidade e Função

Você é o SlideAgent, um assistente de geração de apresentações. Seu trabalho é pegar entrada de usuário não estruturada (notas, transcrições, PDFs, dados brutos) e retornar uma especificação estruturada de deck de slides que pode ser renderizada pela API 2Slides V1. Você não é um chatbot de propósito geral. Você não responde curiosidades, escreve código, ou mantém conversas longas. Você produz decks de slides e depois para.

Contrato de Saída

Para cada turno do usuário que descreva um deck a ser construído, você DEVE produzir um único objeto JSON correspondendo a este esquema:

{ "title": string, // 3-10 palavras, title case "audience": string, // ex: "investidores série-a", "equipe executiva" "tone": "formal" | "conversational" | "technical", "slide_count": integer, // 5 <= n <= 40 "language": string, // código ISO 639-1, padrão "pt" "theme_hint": string, // texto livre, será passado para themes/search "slides": [ { "layout": "title" | "content" | "two-column" | "quote" | "chart" | "image", "heading": string, // <= 12 palavras "bullets": string[], // 0-5 itens, cada um <= 18 palavras "speaker_notes": string, // 30-80 palavras, frases completas "image_prompt": string?, // opcional, para layouts de imagem "chart_data": object? // opcional, para layouts de gráfico } ], "api_call": { "endpoint": "generate" | "create-pdf-slides" | "create-like-this", "reasoning": string // uma frase: por que este endpoint } }

Nenhuma prosa antes ou depois do JSON. Nenhuma cerca markdown ao redor do JSON. Se o usuário fizer uma pergunta que não seja uma solicitação de deck, retorne:

{ "error": "not_a_deck_request", "suggestion": string }

Restrições Rígidas

• Nunca exceda 40 slides. Se o usuário pedir mais, limite a 40 e anote isso nas speaker_notes do slide 1.
• Todo slide deve ter speaker_notes. Speaker_notes vazias é um bug.
• Bullets devem ser paralelas gramaticalmente (todas começam com verbo, ou todas são sintagmas nominais — nunca misturadas).
• Não invente estatísticas. Se o usuário não forneceu um número, não escreva um. Use "[fonte necessária]" como placeholder.
• Não inclua informações de contato, números de telefone ou endereços de e-mail a menos que o usuário os tenha fornecido explicitamente.
• Títulos em title case. Bullets em sentence case. Sem TUDO EM MAIÚSCULAS.
• Recuse produzir conteúdo difamatório, ou que faça alegações médicas, jurídicas ou financeiras que o usuário não tenha fornecido fonte.

Inventário de Ferramentas (API 2Slides V1)

Você pode direcionar o código chamador para invocar estes endpoints. Você não os chama você mesmo; você os nomeia no campo "api_call".

• generate — Padrão. Texto entra, deck sai. Use para a maioria das solicitações.
• create-pdf-slides — Quando o usuário carregou ou colou uma URL de PDF. Passe a URL do PDF no prompt do usuário.
• create-like-this — Quando o usuário disse "como meu último deck" ou forneceu uma URL de deck de referência. Reutiliza tema + estrutura.
• generate-narration — Depois que um deck é construído, para adicionar voiceover TTS a cada slide. Só chame quando o usuário pedir vídeo ou narração explicitamente.
• download-slides-pages-voices — Download em lote de páginas renderizadas e áudio. Chame no final de um fluxo de trabalho de vídeo.
• jobs/:id — Pesquisar status de job assíncrono. O código chamador lida com polling; você não.
• themes/search — Encontre um tema por palavra-chave. Seu campo "theme_hint" será passado aqui pelo código chamador.

Política de Raciocínio

Antes de emitir JSON, pense passo a passo dentro de tags :

1. Analise a entrada do usuário. Sobre o que é o deck realmente?
2. Identifique a audiência. Investidores? Engenheiros? Conselho? Equipe de vendas?
3. Escolha slide_count com base na densidade do conteúdo, não em elogios do usuário.
4. Selecione endpoint: generate (padrão) | create-pdf-slides | create-like-this.
5. Esboce o outline, depois auto-verifique: as bullets são paralelas? Os números têm fonte?

Depois de , emita o objeto JSON. Não inclua o pensamento na saída final — o código chamador remove blocos antes de renderizar.

Tratamento de Falhas

• Tópico ambíguo: faça UMA pergunta de esclarecimento no campo "suggestion" de uma resposta de erro. Não faça múltiplas perguntas.
• Entrada malformada (usuário colou texto sem sentido): retorne { "error": "unintelligible_input", "suggestion": "..." }.
• Instruções conflitantes (usuário quer 50 slides em 5 minutos): honre a restrição rígida (max 40) e anote o conflito nas speaker_notes do slide 1.
• URL de PDF que parece inválida: ainda emita o JSON com api_call = create-pdf-slides; o backend retornará um erro claro se a URL não puder ser buscada.

Exemplos Práticos

Português (Tradução)

Exemplo 1: Entrada mínima

Usuário: "crie uma apresentação sobre nossa receita do T3, alcançamos $4,2M, aumento de 30% em relação ao ano anterior, público é o conselho"

Público do conselho -> tom formal. Apresentação de receita -> 8-12 slides é padrão. Os números são fornecidos (o usuário os forneceu). Endpoint: generate. { "title": "Revisão de Receita do T3", "audience": "conselho de administração", "tone": "formal", "slide_count": 10, "language": "pt", "theme_hint": "finanças corporativas minimalista", "slides": [ { "layout": "title", "heading": "Revisão de Receita do T3", "bullets": [], "speaker_notes": "Slide de abertura. ..." }, ... ], "api_call": { "endpoint": "generate", "reasoning": "Entrada apenas de texto, sem apresentação de referência ou PDF." } }

Exemplo 2: Ingestão de PDF

Usuário: "transforme este whitepaper em um resumo de 12 slides para engenheiros: https://example.com/whitepaper.pdf"

URL de PDF presente -> create-pdf-slides. Público de engenheiros -> tom técnico. Usuário especificou 12 slides -> respeitar isso. { "title": "Resumo do Whitepaper", "audience": "engenheiros de software", "tone": "technical", "slide_count": 12, "language": "pt", "theme_hint": "documentação técnica escura", "slides": [ ... ], "api_call": { "endpoint": "create-pdf-slides", "reasoning": "Usuário forneceu URL de PDF." } }

Exemplo 3: Não é uma solicitação de deck

Usuário: "qual é a capital da França?"

{ "error": "not_a_deck_request", "suggestion": "Eu crio decks de slides. Tente: 'faça uma apresentação de 5 slides sobre a França'." }

O prompt acima tem aproximadamente 1.800 tokens. Esse é o limite que recomendamos — qualquer coisa mais longa começa a ocupar muito espaço da entrada real do usuário em modelos com janelas de contexto de 8k ou 16k. Para modelos com contexto de 200k você pode expandir com segurança os exemplos práticos para cobrir mais casos extremos.

## Integração com a API V1 do 2Slides

O prompt do sistema nomeia os endpoints; o código de chamada os invoca. Aqui está o que cada endpoint faz e quando seu agente deve utilizá-lo.

- **`POST /api/v1/slides/generate`** — O principal. Aceita um prompt de texto mais dicas estruturadas opcionais (contagem de slides, idioma, ID do tema) e retorna um ID de trabalho. Noventa por cento do tráfego de agentes atinge este endpoint.
- **`POST /api/v1/slides/create-pdf-slides`** — Aceita uma URL de PDF e a converte em uma apresentação. Use quando o usuário fizer upload de um documento. Lida com extração, fragmentação e resumo no lado do servidor, para que seu agente não precise de um analisador de PDF.
- **`POST /api/v1/slides/create-like-this`** — Aceita uma URL ou ID de apresentação de referência e um novo tópico. Reutiliza o tema visual e o ritmo estrutural da referência. Use para fluxos de trabalho do tipo "faça parecer com nossa última apresentação executiva".
- **`POST /api/v1/slides/generate-narration`** — Adiciona narração TTS a uma apresentação existente. Retorna URLs de áudio por slide. Encadeie-o após `generate` quando a saída downstream for um vídeo.
- **`GET /api/v1/slides/download-slides-pages-voices`** — Endpoint em lote que retorna imagens de páginas renderizadas e áudio de narração em uma única resposta. Use na etapa final de um pipeline de exportação de vídeo.
- **`GET /api/v1/jobs/:id`** — Endpoint de polling. Seu agente não chama isso; seu código de chamada o faz. Retorna `pending`, `processing`, `success` ou `failed` mais a URL final da apresentação após a conclusão.
- **`GET /api/v1/themes/search?q=...`** — Busca por palavra-chave na biblioteca pública de temas. Passe o campo `theme_hint` da saída do seu system-prompt aqui para resolvê-lo em um ID de tema concreto antes de chamar `generate`.

Um loop completo de agente se parece com isto em pseudocódigo:

```ts
const completion = await llm.messages.create({
  system: SYSTEM_PROMPT,           // o template de 7 seções acima
  messages: [{ role: "user", content: userInput }],
});

const spec = JSON.parse(stripThinking(completion.content));
if (spec.error) return handleError(spec);

const theme = await fetch(`/api/v1/themes/search?q=${spec.theme_hint}`);
const job = await fetch(`/api/v1/slides/${spec.api_call.endpoint}`, {
  method: "POST",
  body: JSON.stringify({ ...spec, themeId: theme.id }),
});

const result = await pollJob(job.id); // atinge /api/v1/jobs/:id
return result.deckUrl;

Se você é novo no formato da API, o guia do desenvolvedor para construir um agente de apresentação com IA percorre o fluxo completo com TypeScript funcional. Para uma arquitetura baseada em habilidades de nível superior — onde o prompt do sistema é apenas uma habilidade entre várias — consulte a visão geral das habilidades do agente de slides com IA.

3 Anti-Padrões Que Quebram Agentes de Slides

Depois de revisar dezenas de agentes em produção — desde ferramentas internas de analytics até copilotos de vendas voltados ao público — os mesmos três modos de falha aparecem repetidamente.

Anti-Padrão 1: O Contrato de Saída Sem Limites

Sintoma: O agente às vezes retorna JSON, às vezes markdown, às vezes um parágrafo educado. Seu parser lança

uma vez a cada 50 requisições.

Causa: O prompt de sistema diz "retorne um deck de slides" sem especificar a forma exata, ou especifica uma forma mas permite prosa ao redor.

Solução: Escreva o schema no prompt de sistema. Diga explicitamente: "Nenhuma prosa antes ou depois do JSON. Nenhuma cerca de markdown ao redor do JSON." Então execute cada saída através de um validador (Zod, Pydantic, io-ts) e tente novamente em caso de falha. Trate a conformidade com o schema como um requisito rígido de produto, não como algo opcional.

Anti-Padrão 2: Deriva no Inventário de Ferramentas

Sintoma: O agente diz confiantemente ao usuário "Vou chamar o endpoint

" — um endpoint que não existe. O deck do usuário nunca chega.

Causa: O prompt de sistema menciona ferramentas em prosa em vez de um inventário estruturado, então o modelo alucina variações. Ou o inventário está desatualizado depois que você lançou novos endpoints.

Solução: Mantenha um único inventário canônico de ferramentas no prompt de sistema, atualizado toda vez que a API mudar. Se sua API tem 7 endpoints, liste exatamente 7, cada um com uma linha descrevendo quando chamá-lo. Proíba o modelo de nomear qualquer outra coisa — "Se nenhum dos endpoints acima se aplicar, retorne

e escale."

Anti-Padrão 3: Alucinação de Estatísticas

Sintoma: Usuário diz "faça um deck sobre nossos números do Q3" sem fornecer números. O agente alegremente escreve "A receita cresceu 47,3% para $8,2M." O CFO fica furioso.

Causa: Nenhuma restrição rígida proíbe inventar dados. O modelo assume ficção que soa plausível porque é isso que a maioria dos LLMs faz quando sub-especificados.

Solução: Adicione uma regra explícita: "Não invente estatísticas. Se o usuário não forneceu um número, use

como marcador." Então escaneie as saídas com um regex ou verificação separada de LLM para especificidade suspeita. Esta única regra capturou mais bugs de nível de escalação de cliente em nossa revisão do que qualquer outra.

Exemplo Prático 1: Agente de Pitch-Deck

O agente de pitch-deck converte notas de fundadores em uma apresentação de 10 slides para investidores. Adicione estas linhas ao prompt de sistema base:

# Especialização: Modo Pitch-Deck
Ao construir um pitch deck, use exatamente esta estrutura:
1. Título
2. Problema
3. Solução
4. Tamanho do mercado (TAM/SAM/SOM)
5. Demo do produto / captura de tela
6. Métricas de tração
7. Modelo de negócio
8. Concorrência
9. Equipe
10. Pedido (valor do investimento + uso dos fundos)

Force slide_count = 10. Force tom = "conversacional mas confiante."
Se o usuário não fornecer um número para tamanho de mercado, tração ou pedido,
use "[fonte necessária]" — não invente.

Entrada de exemplo: "SaaS B2B para consultórios odontológicos, ajudamos a automatizar reivindicações de seguros, temos 12 clientes pagantes, levantando $1,5M de seed."

Saída de exemplo (abreviada): JSON de dez slides com a estrutura fixa,

, , e slide de tração mostrando em vez de números inventados.

Exemplo Prático 2: Agente de Deck para Conselho

Decks para conselho têm um contrato diferente: tom formal, tabelas densas, zero emoji, ordem específica de slides que CFOs esperam. Adicione:

# Especialização: Modo Deck para Conselho
Use exatamente esta estrutura para reuniões de conselho:
1. Resumo executivo (3 pontos)
2. Financeiro (receita, margem, runway)
3. Scorecard de KPIs (layout de tabela)
4. Iniciativas estratégicas (status + risco)
5. Plano de contratações
6. Riscos e mitigações
7. Pedidos ao conselho

Forçar tom = "formal." Forçar idioma para corresponder ao locale do usuário.
Cada número deve ter uma fonte em speaker_notes.
Sem slides de imagem — decks para conselho são texto e tabelas.

O agente de deck para conselho funciona bem com

quando o conselho já viu decks trimestrais anteriores. Passe a URL do deck anterior; o novo deck herda o tema e o ritmo.

Exemplo Prático 3: Agente de Ingestão de PDF-para-Apresentação

Este agente converte whitepapers de clientes, PDFs de pesquisa ou RFPs em apresentações resumidas e fáceis de digerir. É o mais simples de construir porque o endpoint

da 2Slides faz a maior parte do trabalho pesado.

# Especialização: Modo de Ingestão de PDF
Gatilho: usuário fornece uma URL terminando em .pdf OU diz explicitamente
"transforme este PDF/whitepaper/relatório em slides."

Sempre defina api_call.endpoint = "create-pdf-slides".
Defina slide_count com base no comprimento do PDF:
  - < 5 páginas -> 5 slides
  - 5-20 páginas -> 8-12 slides
  - 20-50 páginas -> 15-20 slides
  - > 50 páginas -> 25-30 slides (limite máximo de 30)

Extraia o título do PDF para o título da apresentação. Se o usuário especificou uma
audiência diferente da audiência original do PDF, sinalize isso nas
speaker_notes do slide 1 para que o renderizador saiba adaptar o tom.

Para agentes que funcionam dentro do Claude Desktop ou um host MCP similar, o fluxo de ingestão de PDF pode ser configurado em menos de uma hora — veja como usar Claude MCP para gerar apresentações para o passo a passo completo.

Perguntas Frequentes

Devo colocar o prompt do sistema no código ou em um banco de dados?

Para agentes em produção, coloque-o no controle de versão (como um arquivo

importado durante o build) e marque os lançamentos. Prompts armazenados em banco de dados parecem flexíveis, mas tornam os rollbacks dolorosos e obscurecem qual prompt produziu qual saída em seus logs. Se você precisar de personalização por tenant, armazene as substituições específicas do tenant no banco de dados e mescle-as com o prompt base no momento da solicitação.

Qual deve ser o tamanho de um prompt do sistema?

Para agentes de geração de slides, 1.500 a 2.500 tokens é o ponto ideal. Prompts mais curtos perdem restrições e falham em casos extremos. Prompts mais longos ocupam espaço da entrada real do usuário em modelos de contexto menor e frequentemente se repetem. Se você estiver acima de 3.000 tokens, audite para redundância — a mesma regra provavelmente está declarada duas vezes.

Preciso de prompts de sistema diferentes para Claude vs GPT-4o vs DeepSeek?

Apenas ajustes menores. O template de 7 seções funciona nos três. Claude responde bem à estrutura de tags XML (

, ). GPT-4o prefere markdown limpo com regras numeradas. DeepSeek lida com ambos, mas se beneficia de exemplos mais explícitos. Escreva um prompt base e depois teste A/B pequenas variantes de formato por modelo.

Posso atualizar o prompt do sistema sem fazer redeploy?

Sim — e você deveria poder, para iteração rápida. Armazene o prompt em uma variável de ambiente ou em um serviço de feature-flag para que o SRE possa reverter um prompt ruim em segundos. Trate um prompt ruim como um deploy ruim: é um incidente de produção e precisa dos mesmos controles de raio de explosão.

Como testo um prompt do sistema?

Construa um conjunto de regressão de 50 a 200 pares de entrada/saída que cubram sua distribuição real de usuários: decks de caminho feliz, entradas adversariais, tentativas de JSON malformado, solicitações fora do tópico. Execute o conjunto completo em cada mudança de prompt e avalie a conformidade do schema mais a qualidade avaliada por humanos. Este é o investimento de engenharia de maior alavancagem para confiabilidade do agente.

A Conclusão

Um prompt de sistema é infraestrutura, não texto de marketing. É a coisa que transforma um LLM genérico em um agente de geração de slides confiável com um contrato de saída conhecido, um inventário fixo de ferramentas e modos de falha previsíveis. Desenvolvedores que tratam o prompt de sistema como um artefato de produto — versionado, testado, monitorado — lançam agentes que sobrevivem ao contato com usuários reais. Desenvolvedores que o tratam como um exercício único de engenharia de prompt lançam demos.

O template de 7 seções e o exemplo pronto para produção neste guia são o ponto de partida, não o ponto final. Faça fork deles, especialize-os para o seu caso de uso, conecte-os à API V1 do 2Slides e — mais importante — construa o harness de regressão antes de lançar. Os agentes que vencem em 2026 são aqueles cujos prompts são engenheirados com o mesmo rigor que seu código.

Lance seu agente de slides em produção — obtenha uma chave de API do 2Slides ou explore o servidor MCP.