Prompts de sistema para agentes de presentación con IA: una guía para desarrolladores (2026)

Los prompts de sistema para agentes de presentación con IA son diferentes de los prompts de usuario: codifican el rol del agente, las restricciones y el contrato de salida en lugar de la tarea específica. Un prompt de sistema bien diseñado transforma un LLM general en un agente confiable de generación de diapositivas: voz consistente, estructura predecible y uso de herramientas invocable. Esta guía para desarrolladores cubre la plantilla de prompt de sistema de 7 secciones utilizada en producción por el pipeline de agentes de 2Slides, un prompt de sistema listo para copiar y pegar para construir un agente de diapositivas con Claude, GPT-4o o DeepSeek, los tres anti-patrones que producen salidas poco confiables, y cómo integrar un prompt de sistema con la API V1 de 2Slides (generate, create-pdf-slides, create-like-this, generate-narration, jobs/:id, themes/search). La guía finaliza con tres ejemplos prácticos: un agente de pitch deck que convierte notas del fundador en presentaciones para inversores, un agente de board deck que formatea métricas trimestrales para audiencias ejecutivas, y un agente de ingesta que convierte PDFs en presentaciones.

Si estás construyendo un chatbot, un asistente de programación que genera presentaciones, o una herramienta interna que automatiza informes, la diferencia entre una demo y producción está casi totalmente en el prompt de sistema. Esta guía está escrita para desarrolladores: sin marketing inflado, código real, endpoints reales.

Prompts del Sistema vs Prompts del Usuario: ¿Cuál es la Diferencia Real?

Un prompt del usuario es la tarea. Un prompt del sistema es el manual de operaciones.

Cuando un product manager escribe "hazme 10 diapositivas sobre los ingresos del Q3", eso es un prompt del usuario. Cuando tu agente devuelve consistentemente JSON válido, nunca excede tu presupuesto de diapositivas, siempre cita fuentes en las notas del orador, y llama al endpoint

cuando el usuario sube un archivo — ese comportamiento proviene del prompt del sistema.

En las APIs de OpenAI, Anthropic y Google, el prompt del sistema es un campo separado (

en Anthropic, rol en OpenAI chat completions, en Gemini). Los modelos están entrenados para darle mayor peso que a los turnos del usuario y tratarlo como no-anulable por mensajes posteriores. Eso lo convierte en el lugar adecuado para:

• Definición del rol — qué tipo de agente es este
• Contratos de salida — esquema JSON, formato markdown, o forma de tool-call
• Restricciones estrictas — límites de palabras, reglas de tono, contenido prohibido
• Inventario de herramientas/API — qué funciones son invocables y cuándo
• Reglas de escalación — cuándo rechazar, pedir aclaración, o derivar

Los prompts del usuario que intentan codificar todo esto fallan en el momento en que el texto de la tarea del usuario se vuelve largo. Los prompts del sistema sobreviven cada turno.

La Plantilla de Sistema de Prompts de 7 Secciones

Cada agente de generación de diapositivas confiable que hemos lanzado o auditado en 2Slides utiliza alguna variante de esta estructura de siete secciones. El orden importa — los LLMs ponderan más las instrucciones anteriores, por lo que el rol y el contrato aparecen primero, los ejemplos trabajados aparecen al final.

1. Identidad y Rol — descripción de un párrafo de quién es el agente y qué hace
2. Contrato de Salida — esquema o formato exacto que el agente debe devolver
3. Restricciones Estrictas — reglas no negociables (longitud, tono, patrones prohibidos)
4. Inventario de Herramientas — cada API o función disponible, con orientación sobre cuándo llamarla
5. Política de Razonamiento — cómo debe pensar el agente (cadena de pensamiento, autocomprobación, escalación)
6. Manejo de Fallos — qué hacer cuando la entrada es ambigua, mal formada o fuera de tema
7. Ejemplos Trabajados — de dos a cuatro pares completos de entrada/salida que demuestran el comportamiento correcto

La plantilla es deliberadamente opinionada. Cuando auditamos agentes que se comportan mal en producción, la causa es casi siempre una sección faltante en lugar de una mala. Los agentes sin un inventario de herramientas alucina endpoints. Los agentes sin una sección de manejo de fallos inventan datos cuando las entradas son escasas. Los agentes sin ejemplos trabajados derivan el tono durante conversaciones largas.

Identidad y Rol

Eres SlideAgent, un asistente de generación de presentaciones. Tu trabajo es tomar entradas de usuario no estructuradas (notas, transcripciones, PDFs, datos en bruto) y devolver una especificación estructurada de presentación que puede ser renderizada por la API V1 de 2Slides. No eres un chatbot de propósito general. No respondes trivias, escribes código, ni mantienes conversaciones largas. Produces presentaciones y luego te detienes.

Contrato de Salida

Para cada turno del usuario que describa una presentación a construir, DEBES generar un único objeto JSON que coincida con este esquema:

{ "title": string, // 3-10 palabras, mayúsculas en títulos "audience": string, // ej. "inversores serie-a", "equipo ejecutivo" "tone": "formal" | "conversational" | "technical", "slide_count": integer, // 5 <= n <= 40 "language": string, // código ISO 639-1, predeterminado "en" "theme_hint": string, // texto libre, será pasado a themes/search "slides": [ { "layout": "title" | "content" | "two-column" | "quote" | "chart" | "image", "heading": string, // <= 12 palabras "bullets": string[], // 0-5 elementos, cada uno <= 18 palabras "speaker_notes": string, // 30-80 palabras, oraciones completas "image_prompt": string?, // opcional, para layouts de imagen "chart_data": object? // opcional, para layouts de gráficos } ], "api_call": { "endpoint": "generate" | "create-pdf-slides" | "create-like-this", "reasoning": string // una oración: por qué este endpoint } }

Sin prosa antes o después del JSON. Sin delimitadores markdown alrededor del JSON. Si el usuario hace una pregunta que no es una solicitud de presentación, devuelve:

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

Restricciones Estrictas

• Nunca excedas 40 diapositivas. Si el usuario solicita más, limita a 40 y anótalo en speaker_notes de la diapositiva 1.
• Cada diapositiva debe tener speaker_notes. Speaker_notes vacío es un error.
• Las viñetas deben ser paralelas gramaticalmente (todas empiezan con verbo, o todas son frases nominales — nunca mezcladas).
• No inventes estadísticas. Si el usuario no proporcionó un número, no escribas uno. Usa "[fuente necesaria]" como marcador de posición.
• No incluyas información de contacto, números de teléfono o direcciones de correo electrónico a menos que el usuario los haya proporcionado explícitamente.
• Los títulos van en mayúsculas de título. Las viñetas en mayúsculas de oración. Sin TODO MAYÚSCULAS.
• Niégate a producir contenido que sea difamatorio, o que haga afirmaciones médicas, legales o financieras que el usuario no haya documentado.

Inventario de Herramientas (API V1 de 2Slides)

Puedes dirigir al código de llamada para invocar estos endpoints. No los llamas tú mismo; los nombras en el campo "api_call".

• generate — Predeterminado. Texto de entrada, presentación de salida. Usar para la mayoría de solicitudes.
• create-pdf-slides — Cuando el usuario subió o pegó una URL de PDF. Pasa la URL del PDF en el prompt del usuario.
• create-like-this — Cuando el usuario dijo "como mi última presentación" o proporcionó una URL de presentación de referencia. Reutiliza tema + estructura.
• generate-narration — Después de construir una presentación, para agregar voz en off TTS a cada diapositiva. Solo llama cuando el usuario pida video o narración explícitamente.
• download-slides-pages-voices — Descarga por lotes páginas renderizadas y audio. Llama al final de un flujo de trabajo de video.
• jobs/:id — Consulta el estado de trabajo asíncrono. El código de llamada maneja el polling; tú no.
• themes/search — Encuentra un tema por palabra clave. Tu campo "theme_hint" será pasado aquí por el código de llamada.

Política de Razonamiento

Antes de emitir JSON, piensa paso a paso dentro de etiquetas :

1. Analiza la entrada del usuario. ¿De qué trata realmente la presentación?
2. Identifica la audiencia. ¿Inversores? ¿Ingenieros? ¿Junta directiva? ¿Equipo de ventas?
3. Elige slide_count basándote en la densidad del contenido, no en halagos del usuario.
4. Selecciona endpoint: generate (predeterminado) | create-pdf-slides | create-like-this.
5. Redacta el esquema, luego autoverifica: ¿son paralelas las viñetas? ¿Están documentados los números?

Después de , emite el objeto JSON. No incluyas el razonamiento en la salida final — el código de llamada elimina los bloques antes de renderizar.

Manejo de Fallos

• Tema ambiguo: haz UNA pregunta aclaratoria en el campo "suggestion" de una respuesta de error. No hagas múltiples preguntas.
• Entrada mal formada (el usuario pegó incoherencias): devuelve { "error": "unintelligible_input", "suggestion": "..." }.
• Instrucciones contradictorias (el usuario quiere 50 diapositivas en 5 minutos): respeta la restricción estricta (máx 40) y anota el conflicto en speaker_notes de la diapositiva 1.
• URL de PDF que parece inválida: aun así emite el JSON con api_call = create-pdf-slides; el backend devolverá un error claro si la URL no se puede obtener.

Ejemplos Trabajados

Ejemplo 1: Entrada mínima

Usuario: "hazme una presentación sobre nuestros ingresos del Q3, alcanzamos $4.2M, un aumento del 30% interanual, la audiencia es la junta directiva"

Audiencia junta directiva -> tono formal. Presentación de ingresos -> 8-12 diapositivas es estándar. Los números tienen fuente (el usuario los proporcionó). Endpoint: generate. { "title": "Revisión de Ingresos Q3", "audience": "junta directiva", "tone": "formal", "slide_count": 10, "language": "es", "theme_hint": "minimal corporate finance", "slides": [ { "layout": "title", "heading": "Revisión de Ingresos Q3", "bullets": [], "speaker_notes": "Diapositiva de apertura. ..." }, ... ], "api_call": { "endpoint": "generate", "reasoning": "Entrada solo de texto, sin presentación de referencia o PDF." } }

Ejemplo 2: Ingesta de PDF

Usuario: "convierte este whitepaper en un resumen de 12 diapositivas para ingenieros: https://example.com/whitepaper.pdf"

URL de PDF presente -> create-pdf-slides. Audiencia de ingenieros -> tono técnico. Usuario especificó 12 diapositivas -> respetarlo. { "title": "Resumen del Whitepaper", "audience": "ingenieros de software", "tone": "technical", "slide_count": 12, "language": "es", "theme_hint": "technical documentation dark", "slides": [ ... ], "api_call": { "endpoint": "create-pdf-slides", "reasoning": "Usuario proporcionó URL de PDF." } }

Ejemplo 3: No es una solicitud de presentación

Usuario: "¿cuál es la capital de Francia?"

{ "error": "not_a_deck_request", "suggestion": "Creo presentaciones de diapositivas. Intenta: 'crea un briefing de 5 diapositivas sobre Francia'." }

El prompt anterior tiene aproximadamente 1,800 tokens. Ese es el límite que recomendamos — cualquier cosa más larga comienza a desplazar la entrada real del usuario en modelos con ventanas de contexto de 8k o 16k. Para modelos con contexto de 200k puedes expandir de forma segura los ejemplos trabajados para cubrir más casos extremos.

## Integración con la API V1 de 2Slides

El prompt del sistema nombra los endpoints; el código que los invoca los ejecuta. Aquí está lo que hace cada endpoint y cuándo tu agente debe utilizarlos.

- **`POST /api/v1/slides/generate`** — El motor principal. Acepta un prompt de texto más indicaciones estructuradas opcionales (número de diapositivas, idioma, ID de tema) y devuelve un ID de trabajo. El noventa por ciento del tráfico de agentes utiliza este endpoint.
- **`POST /api/v1/slides/create-pdf-slides`** — Acepta una URL de PDF y la convierte en una presentación. Úsalo cuando el usuario suba un documento. Maneja la extracción, fragmentación y resumen en el servidor, por lo que tu agente no necesita un analizador de PDF.
- **`POST /api/v1/slides/create-like-this`** — Acepta una URL o ID de presentación de referencia y un nuevo tema. Reutiliza el tema visual y el ritmo estructural de la referencia. Úsalo para flujos de trabajo tipo "hazlo como nuestra última presentación ejecutiva".
- **`POST /api/v1/slides/generate-narration`** — Añade voz en off TTS a una presentación existente. Devuelve URLs de audio por diapositiva. Encadénalo después de `generate` cuando la salida final sea un video.
- **`GET /api/v1/slides/download-slides-pages-voices`** — Endpoint por lotes que devuelve imágenes de páginas renderizadas y audio de narración en una respuesta. Úsalo en el paso final de un pipeline de exportación de video.
- **`GET /api/v1/jobs/:id`** — Endpoint de sondeo. Tu agente no llama a esto; tu código de invocación lo hace. Devuelve `pending`, `processing`, `success` o `failed` más la URL final de la presentación al completarse.
- **`GET /api/v1/themes/search?q=...`** — Búsqueda por palabras clave en la biblioteca de temas públicos. Pasa el campo `theme_hint` de tu salida del system-prompt aquí para resolverlo a un ID de tema concreto antes de llamar a `generate`.

Un ciclo completo de agente se ve así en pseudocódigo:

```ts
const completion = await llm.messages.create({
  system: SYSTEM_PROMPT,           // la plantilla de 7 secciones anterior
  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); // llama a /api/v1/jobs/:id
return result.deckUrl;

Si eres nuevo en la estructura de la API, la guía para desarrolladores para construir un agente de presentaciones AI recorre el flujo completo con TypeScript funcional. Para una arquitectura de nivel superior basada en habilidades — donde el system prompt es solo una habilidad entre varias — consulta la descripción general de habilidades del agente de diapositivas AI.

3 Anti-Patrones Que Rompen los Agentes de Diapositivas

Después de revisar docenas de agentes en producción — desde herramientas internas de análisis hasta copilotos de ventas públicos — los mismos tres modos de falla aparecen una y otra vez.

Anti-Patrón 1: El Contrato de Salida Sin Límites

Síntoma: El agente a veces devuelve JSON, a veces markdown, a veces un párrafo educado. Tu analizador lanza

una vez cada 50 solicitudes.

Causa: El prompt del sistema dice "devuelve una presentación de diapositivas" sin especificar la forma exacta, o especifica una forma pero permite prosa alrededor de ella.

Solución: Escribe el esquema en el prompt del sistema. Di explícitamente: "Sin prosa antes o después del JSON. Sin cercas markdown alrededor del JSON." Luego pasa cada salida por un validador (Zod, Pydantic, io-ts) y reintenta en caso de falla. Trata el cumplimiento del esquema como un requisito de producto estricto, no como algo deseable.

Anti-Patrón 2: Desviación del Inventario de Herramientas

Síntoma: El agente dice con confianza al usuario "Llamaré al endpoint

" — un endpoint que no existe. La presentación del usuario nunca llega.

Causa: El prompt del sistema menciona herramientas en prosa en lugar de en un inventario estructurado, así que el modelo alucina variaciones. O el inventario está desactualizado después de que lanzaste nuevos endpoints.

Solución: Mantén un único inventario canónico de herramientas en el prompt del sistema, actualizado cada vez que cambie el API. Si tu API tiene 7 endpoints, lista exactamente 7, cada uno con una línea describiendo cuándo llamarlo. Prohíbe al modelo nombrar cualquier otra cosa — "Si ninguno de los endpoints anteriores aplica, devuelve

y escala."

Anti-Patrón 3: Alucinación de Estadísticas

Síntoma: El usuario dice "crea una presentación sobre nuestros números del Q3" sin proporcionar números. El agente escribe alegremente "Los ingresos crecieron 47.3% a $8.2M." El CFO está furioso.

Causa: No hay una restricción estricta que prohíba inventar datos. El modelo por defecto genera ficción que suena plausible porque eso es lo que la mayoría de los LLMs hacen cuando están sub-especificados.

Solución: Agrega una regla explícita: "No inventes estadísticas. Si el usuario no proporcionó un número, usa

como marcador de posición." Luego escanea las salidas con una expresión regular o una verificación separada con LLM para detectar especificidad sospechosa. Esta única regla ha detectado más errores de escalación con clientes en nuestra revisión que cualquier otra.

Ejemplo Práctico 1: Agente de Pitch Deck

El agente de pitch deck convierte las notas del fundador en una presentación de inversores de 10 diapositivas. Añade estas líneas al prompt del sistema base:

# Especialización: Modo Pitch Deck
Cuando construyas un pitch deck, usa exactamente esta estructura:
1. Título
2. Problema
3. Solución
4. Tamaño del mercado (TAM/SAM/SOM)
5. Demo del producto / captura de pantalla
6. Métricas de tracción
7. Modelo de negocio
8. Competencia
9. Equipo
10. Petición (cantidad de financiación + uso de fondos)

Forzar slide_count = 10. Forzar tone = "conversational but confident."
Si el usuario no proporcionó un número para tamaño de mercado, tracción o petición,
usa "[source needed]" — no inventes.

Entrada de ejemplo: "B2B SaaS para consultorios dentales, les ayudamos a automatizar reclamaciones de seguros, tenemos 12 clientes de pago, buscamos levantar $1.5M en ronda semilla."

Salida de ejemplo (abreviada): JSON de diez diapositivas con la estructura fija,

, , y la diapositiva de tracción mostrando en lugar de números inventados.

Ejemplo Práctico 2: Agente de Presentaciones para Juntas Directivas

Las presentaciones para juntas directivas tienen un contrato diferente: tono formal, tablas densas, cero emojis, orden específico de diapositivas que los CFOs esperan. Añade:

# Especialización: Modo Presentación para Junta Directiva
Usa exactamente esta estructura para reuniones de junta directiva:
1. Resumen ejecutivo (3 bullets)
2. Finanzas (ingresos, margen, runway)
3. Cuadro de KPIs (diseño de tabla)
4. Iniciativas estratégicas (estado + riesgo)
5. Plan de contratación
6. Riesgos y mitigaciones
7. Solicitudes a la junta directiva

Forzar tono = "formal". Forzar idioma para que coincida con la configuración regional del usuario.
Cada número debe tener una fuente en speaker_notes.
Sin diapositivas de imágenes — las presentaciones para juntas directivas son texto y tablas.

El agente de presentaciones para juntas directivas funciona bien con

cuando la junta directiva ha visto presentaciones trimestrales anteriores. Pasa la URL de la presentación anterior; la nueva presentación hereda el tema y el ritmo.

Ejemplo Práctico 3: Agente de Ingesta PDF-a-Presentación

Este agente convierte whitepapers de clientes, PDFs de investigación o RFPs en presentaciones resumen digestibles. Es el más simple de construir porque el endpoint

de 2Slides hace la mayor parte del trabajo pesado.

# Especialización: Modo de Ingesta PDF
Activación: el usuario proporciona una URL que termina en .pdf O dice explícitamente
"convierte este PDF/whitepaper/informe en diapositivas."

Siempre establecer api_call.endpoint = "create-pdf-slides".
Establecer slide_count según la longitud del PDF:
  - < 5 páginas -> 5 diapositivas
  - 5-20 páginas -> 8-12 diapositivas
  - 20-50 páginas -> 15-20 diapositivas
  - > 50 páginas -> 25-30 diapositivas (límite en 30)

Extraer el título del PDF para el título de la presentación. Si el usuario especificó una
audiencia diferente de la audiencia original del PDF, marcar eso en
slide 1 speaker_notes para que el renderizador sepa adaptar el tono.

Para agentes que funcionan dentro de Claude Desktop o un host MCP similar, el flujo de ingesta PDF puede configurarse en menos de una hora — consulta cómo usar Claude MCP para generar presentaciones para el tutorial completo.

Preguntas Frecuentes

¿Debería poner el system prompt en código o en una base de datos?

Para agentes en producción, ponlo en control de versiones (como un archivo

importado en tiempo de compilación) y etiqueta las versiones. Los prompts almacenados en base de datos suenan flexibles, pero hacen que los rollbacks sean dolorosos y oscurecen qué prompt produjo qué salida en tus registros. Si necesitas personalización por tenant, almacena las modificaciones específicas del tenant en la base de datos y combínalas con el prompt base en tiempo de solicitud.

¿Cuán largo debería ser un system prompt?

Para agentes de generación de diapositivas, de 1,500 a 2,500 tokens es el punto óptimo. Los prompts más cortos omiten restricciones y fallan en casos extremos. Los prompts más largos desplazan la entrada real del usuario en modelos de contexto más pequeño y a menudo se repiten. Si superas los 3,000 tokens, audita en busca de redundancia — probablemente la misma regla está declarada dos veces.

¿Necesito diferentes system prompts para Claude vs GPT-4o vs DeepSeek?

Solo ajustes menores. La plantilla de 7 secciones funciona en los tres. Claude responde bien al andamiaje de etiquetas XML (

, ). GPT-4o prefiere markdown limpio con reglas numeradas. DeepSeek maneja ambos pero se beneficia de ejemplos más explícitos. Escribe un prompt base, luego haz pruebas A/B de pequeñas variantes de formato por modelo.

¿Puedo actualizar el system prompt sin redesplegar?

Sí — y deberías poder hacerlo, para iteración rápida. Almacena el prompt en una variable de entorno o un servicio de feature-flags para que SRE pueda revertir un prompt defectuoso en segundos. Trata un prompt defectuoso como un deploy defectuoso: es un incidente de producción y necesita los mismos controles de radio de explosión.

¿Cómo pruebo un system prompt?

Construye un conjunto de regresión de 50 a 200 pares de entrada/salida que cubran tu distribución real de usuarios: presentaciones de ruta feliz, entradas adversarias, intentos de JSON mal formado, solicitudes fuera de tema. Ejecuta el conjunto completo en cada cambio de prompt y califica el cumplimiento del esquema más la calidad evaluada por humanos. Esta es la inversión de ingeniería de mayor apalancamiento para la confiabilidad del agente.

La Conclusión

Un system prompt es infraestructura, no copy. Es lo que transforma un LLM genérico en un agente de generación de diapositivas confiable con un contrato de salida conocido, un inventario fijo de herramientas y modos de fallo predecibles. Los desarrolladores que tratan el system prompt como un artefacto de producto — versionado, probado, monitoreado — lanzan agentes que sobreviven el contacto con usuarios reales. Los desarrolladores que lo tratan como un ejercicio de prompt-engineering de una sola vez lanzan demos.

La plantilla de 7 secciones y el ejemplo listo para producción en esta guía son el punto de partida, no el punto final. Bifúrcalos, especializalos para tu caso de uso, conéctalos a la API V1 de 2Slides y — lo más importante — construye el arnés de regresión antes de lanzar. Los agentes que ganan en 2026 son aquellos cuyos prompts están diseñados con el mismo rigor que su código.

Lanza tu agente de diapositivas en producción — obtén una API key de 2Slides o explora el servidor MCP.