Prompt de sistema para agentes: 12 patrones de diseño listos para producción

El diseño de system prompts es la construcción estructurada del system prompt de un agente de IA a partir de bloques reutilizables: rol, objetivo, restricciones, instrucciones de herramientas, formato de salida, ejemplos, gestión de errores, reflexión, memoria, escalado, criterios de parada y seguridad. En 2026, un buen system prompt de agente es modular, auditable y guiado por evals: un artefacto versionable en lugar de un muro de texto en prosa.

La diferencia entre un agente de demo y un sistema listo para producción rara vez está en el modelo. Está en el sustrato del prompt: en si el rol, las herramientas, el formato de salida y los criterios de parada están bien definidos. Los doce patrones de diseño siguientes son los bloques recurrentes en los que convergen los agentes en producción serios (Claude Code, Cursor, Devin, OpenAI Codex Agents).

Respuestas rápidas

• La estructura gana a la prosa: el system prompt de un agente se divide en cuatro capas (Identity, Capability, Behavioral, Context) separadas con etiquetas XML o encabezados Markdown. El modelo parsea los prompts estructurados con más fiabilidad.
• La longitud adecuada: 500-3.000 tokens para el núcleo (sin esquemas de herramientas). Si es demasiado vago, produce salidas inconsistentes; si es demasiado detallado, se vuelve frágil y provoca el efecto lost in the middle dentro del propio prompt.
• Un patrón sin eval es folclore: cada patrón se verifica con un conjunto de evaluación. Clásicos como «Eres un experto» o «Take a deep breath» a menudo no tienen un efecto medible en los modelos modernos.

La base: el modelo de cuatro capas

Antes de que los patrones individuales surtan efecto, todo system prompt de agente necesita un armazón. Los system prompts en producción se estructuran de forma consistente en cuatro capas, que a la vez marcan la estructura de la caché (capas estables delante, dinámicas detrás):

Anthropic recomienda separar estas secciones con etiquetas XML como <instructions> o con encabezados Markdown (datos de 2026). La ventaja es doble: el modelo parsea la estructura con más fiabilidad y el ingeniero puede comparar, versionar y someter a tests A/B cada sección.

Los 12 patrones de diseño de un vistazo

1-3: rol, objetivo, restricciones

El antipatrón «Eres un asistente útil» es inespecífico y no aporta ningún control. La base es un rol concreto con dominio y límites. Igual de dañinas son las restricciones contradictorias como «Sé conciso, pero exhaustivo». Es mejor un comportamiento por defecto claro con cláusulas de excepción explícitas. Importante: como máximo 5-8 reglas de alta prioridad. El modelo aplica con menos frecuencia las reglas del final de una lista de 47 puntos (lost in the middle dentro del propio system prompt); el resto va en las descripciones de herramientas.

4: instrucciones de herramientas

Las definiciones de herramientas no son una capa aparte: el modelo las parsea en cada turno de inferencia. Cuando un agente actúa mal, según Anthropic la causa «en la mayoría de los casos» no está en el modelo, sino en la definición de la herramienta. Regla general: 3-5 herramientas siempre cargadas, el resto mediante búsqueda de herramientas. A partir de 10 herramientas empieza una degradación medible. El componente más eficaz y más olvidado es la cláusula When-not-to-use: si existen a la vez search_web y query_internal_db, es ella la que decide la selección. En cambio, si dos herramientas se solapan por completo en su función, no hay prompt que valga, por bueno que sea: entonces hay que fusionarlas o separarlas limpiamente por su función.

5-6: formato de salida y ejemplos few-shot

«Fiable» significa en 2026 100 %, no 95. Los Structured Outputs de OpenAI imponen, mediante decodificación restringida, un cumplimiento del 100 % del esquema JSON (GA desde agosto de 2024). Anthropic introdujo Structured Outputs nativos en noviembre de 2025, y están disponibles de forma general desde febrero de 2026. También aquí la decodificación restringida impone el esquema: el esquema JSON va en output_config.format. Para las llamadas a herramientas, strict: true en la definición de la herramienta impone el esquema. El workaround anterior con tool_choice y una pseudoherramienta como return_structured_result sigue funcionando, pero sin el modo strict no garantiza una fidelidad completa al esquema. Para combinar chain-of-thought y salida estructurada en una sola llamada, el patrón XML funciona bien en producción: el modelo piensa de forma visible en el bloque <thinking> y el sistema downstream solo parsea el bloque <final_output>. Los ejemplos few-shot (como el array input_examples de Anthropic) cubren parámetros anidados u opcionales sobre los que el modelo, sin ellos, adivina. Importante: ejemplos diversos y canónicos, sin duplicados, porque si no el modelo elige el más cercano.

7-8: gestión de errores y reflexión

Los bucles robustos distinguen tipos de error: un error de herramienta (500/timeout) permite reintentar con los mismos parámetros (máx. 2 veces con backoff), un error de validación (400) permite reintentar con parámetros ajustados y un error de permisos (403) no admite reintento, sino escalado. El antipatrón más peligroso es la supresión silenciosa de errores: las llamadas a herramientas fallan y el agente sigue como si todo fuera bien. Los errores deben volver al modelo como resultados explícitos de la herramienta. La reflexión/verificación suele costar 2-3 veces más tokens a cambio de 5-15 puntos porcentuales de calidad. En un agente que aprueba un pedido de 50.000 EUR, el ROI es evidente; en un agente de atención al cliente con márgenes de céntimos tienes que hacer bien las cuentas.

9-10: gestión de memoria y escalado/HITL

Incluso dentro de la ventana de contexto, el modelo «olvida» el estado introducido al principio. Mitigaciones: fijar el estado crítico (objetivo, tarea actual, hechos clave) al final del system prompt (los modelos prestan más atención al final que a la parte central), un encabezado previo antes de cada turno del usuario y un scratchpad mantenido explícitamente como ancla. En entornos multi-tenant, la contaminación de memoria es uno de los bugs de producción más frecuentes. Solución: un reinicio explícito de la sesión al inicio de cada conversación y el ID de sesión como parámetro obligatorio en todas las herramientas de estado. Para decisiones de alto riesgo, hace falta un control human-in-the-loop antes de ejecutar la herramienta.

11-12: criterios de parada y seguridad

Según las investigaciones, los bucles infinitos fueron la clase de bug más frecuente en producción en 2025-2026. Una terminación robusta combina un máximo de iteraciones (10-30 en uso general, 50-100 en programación, como límite estricto), un criterio de éxito, un límite de coste y la detección de estados repetidos (la misma llamada a herramienta con los mismos parámetros 3 veces como detector de thrashing). Por último, las indicaciones de seguridad deben marcarse explícitamente como no negociables y situarse por encima de las instrucciones de persona. El antipatrón «persona por encima de la seguridad» es un vector conocido de inyección de prompts. Para cargas de trabajo en Europa se suman los patrones del RGPD: seudonimización antes de inyectar el contexto y una capa de enmascaramiento de PII antes de la inyección en el RAG.

Caso práctico: agente de triaje en una pyme

Una pyme de la región DACH (Alemania, Austria y Suiza) utiliza un agente de triaje para atención al cliente con el siguiente presupuesto (datos de 2026): system prompt de 800-1.500 tokens, definiciones de herramientas de 800-1.500 tokens (4-5 herramientas con input_examples), retrieval base de unos 2.000 tokens (3-5 chunks con reranking), historial de conversación por debajo de 4.000 tokens (sliding window N=10) y salida de 1.000-2.000 tokens. En total, unos 10.000 tokens por llamada. El system prompt y las definiciones de herramientas suman 1.600-3.000 tokens, es decir, entre una quinta parte y un tercio de la entrada, y se mantienen iguales en todas las llamadas. Para este prefijo entra en juego el Prompt Caching: en la mayoría de los modelos Claude, las lecturas de caché cuestan el 10 % de la tarifa estándar de entrada, siempre que el prefijo alcance la longitud mínima del modelo (de 512 a 4.096 tokens según la documentación de Anthropic, datos de octubre de 2026). Así, los costes de entrada por llamada bajan en torno a un 20-30 %, y los de salida no cambian. Si la caché caduca, volver a escribir el prefijo cuesta más que la entrada normal.

Pseudocódigo para las salvaguardas del bucle:

• max_iterations = 20
• on tool_error(403): escalate_to_human() (sin reintento)
• on tool_error(500): retry(max=2, backoff=true)
• on repeated_call(same_tool, same_params, n>=3): break (thrashing)
• if confidence < 0.8 or amount > 5000: handoff_to_human()
• terminate_on: submit_final_answer() called

Nota importante para elegir el modelo: con los tokenizadores estándar, el alemán produce un 30-50 % más de tokens que el inglés. Por eso, una ventana de 200K solo admite tanto contenido en alemán como unos 130K-150K tokens de texto en inglés. Eso hace que la disciplina con la longitud del prompt sea aún más importante y que el caching compense todavía más.

Para agencias y B2B

Una agencia que opera agentes para clientes de varios sectores no debería escribir los system prompts desde cero para cada cliente, sino derivarlos por herencia de plantillas a partir de una base de la agencia: el branding y el comportamiento del cliente se sobrescriben, los doce patrones se mantienen constantes. Esto escala mejor, porque la infraestructura compartida (framework de evals, librería de herramientas, observabilidad) genera rendimientos compuestos, mientras que los «copos de nieve» de cada cliente generan un esfuerzo de mantenimiento exponencial. Para los decisores B2B en Europa, el mensaje clave es este: un system prompt no es un texto que se escribe una vez, sino un artefacto de ingeniería versionado con regresión de evals en cada cambio. Blck Alpaca, desde Viena, acompaña a las empresas en la creación de esta disciplina reproducible de system prompts, desde la elección de patrones hasta una capa de logging conforme al Reglamento de IA de la UE y al RGPD.