System prompts para agentes: cómo escribir el cerebro de tu agente

En un chatbot el prompt es una instrucción; en un agente el system prompt es el cerebro: define quién es, qué contexto del negocio maneja, qué reglas sigue, qué límites respeta y en qué formato entrega cada respuesta. Es el archivo más caro de tu proyecto, porque cada decisión del agente —cada llamada a herramienta, cada correo redactado, cada dato inventado— pasa por él. Esta guía te da una plantilla paso a paso para escribir el tuyo, ejemplos antes y después, y la regla que más cuesta aceptar: un system prompt corto supera a uno largo.

Qué es un system prompt y por qué importa

El system prompt es el bloque de instrucciones permanentes que el modelo recibe al inicio de cada conversación. A diferencia del user prompt (el mensaje variable de cada usuario), el system prompt no cambia entre peticiones: es la especificación del agente. Los documentos oficiales de system prompts de Claude y la guía de prompt engineering de OpenAI coinciden en lo esencial: las instrucciones permanentes deben estar separadas de la petición del usuario, porque el modelo trata ambos bloques de forma distinta y porque la caché de contexto premia lo estable.

Un system prompt mal escrito produce síntomas específicos: respuestas que cambian de tono entre usuarios, herramientas llamadas cuando no deben, datos de pedidos inventados, salidas imposibles de parsear. Ninguno se arregla con mejor código: se arregla con mejor especificación.

La plantilla en cinco bloques

El system prompt de un agente tiene cinco bloques, en este orden:

1. Rol: quién es el agente y para quién trabaja.
2. Contexto del negocio: qué producto o servicio maneja, qué información es confiable.
3. Reglas de comportamiento: cómo decide, qué tono usa, qué prioriza.
4. Límites: qué no puede hacer nunca y cuándo escalar.
5. Formato de salida: estructura exacta de cada respuesta.

Plantilla lista para copiar:

Eres {rol} de {empresa}. Tu trabajo es {misión en una línea}.

Contexto: {qué producto/servicio manejas, qué sistema usas para
verificar información, quién es el cliente típico}.

Reglas:
- {regla de tono y estilo}
- {regla de decisión: cuándo respondes, cuándo preguntas más}
- {regla de verificación: qué datos necesitas confirmar con herramientas}

Límites:
- Nunca {lo que está prohibido}.
- Si {condición de riesgo}, escala a un humano con un resumen.

Formato de salida: {estructura exacta, p. ej. JSON con campos
definidos o secciones fijas}. Idioma: español.

Cada bloque tiene un propósito. El rol no es decoración: define qué información debe pedir y qué tono usar. El contexto del negocio evita que el modelo adivine reglas de tu operación. Las reglas convierten tu criterio en decisiones repetibles. Los límites son la diferencia entre un agente útil y un agente peligroso. El formato de salida hace que el resultado sea validable y barato de procesar.

Antes y después

Antes — el prompt que todo el mundo escribe la primera vez:

Eres un asistente de soporte de una tienda. Ayuda a los clientes
con sus pedidos y responde con amabilidad.

El resultado: respuestas genéricas, tono inconsistente, inventa fechas de entrega, no sabe cuándo consultar el pedido real y nunca escala un reembolso.

Después — el mismo agente con cerebro definido:

Eres el agente de soporte de Tienda GT. Tu trabajo es resolver
consultas de pedidos con datos verificados, no con suposiciones.

Contexto: la tienda vende electrónica en Guatemala y entrega en
48-72 horas. La única fuente de verdad de un pedido es la
herramienta consultar_pedido.

Reglas:
- Respondes en español, tono amable y directo.
- Antes de decir estado, fecha o monto de un pedido, consultas
  consultar_pedido.
- Si la consulta no está clara, haces una sola pregunta de
  aclaración antes de responder.

Límites:
- Nunca inventes estados, fechas ni montos.
- Si el cliente pide reembolso o cancelación, escalas con un
  resumen de tres líneas.

Formato: saludo breve, respuesta al problema, siguiente paso.

La diferencia no es de estilo: es de contrato. El agente sabe qué consultar, qué no responder, cuándo escalar y cómo entregar. Eso se puede probar, medir y mejorar.

Por qué corto supera a largo

La tentación es documentarlo todo: políticas completas, historias de la empresa, manuales pegados. Eso degrada el agente por tres razones:

• Las instrucciones clave se diluyen: el modelo pondera lo que está al inicio y lo que se repite; un prompt de 3.000 palabras entierra lo importante.
• Más texto, más contradicciones: cada párrafo nuevo es una oportunidad de chocar con otro ("sé breve" junto a "explica cada paso en detalle").
• Más tokens, más costos: el system prompt se envía en cada llamada; un prompt largo encarece cada respuesta y ralentiza la primera salida.

La regla práctica: si una línea no cambia ninguna decisión del agente, elimínala. Escribe lo mínimo que capture rol, contexto, reglas, límites y formato. Después itera con evals, no con intuición: el flujo de iteración de prompts con dataset de casos y verificación es el mismo que usamos en la guía base de prompt engineering para agentes.

Cómo probarlo antes de confiar

Un system prompt no se escribe y se publica: se prueba. El ciclo mínimo:

1. Dataset de 10-20 casos reales con la respuesta esperada o los criterios de una buena respuesta.
2. Corre el agente con el system prompt nuevo y revisa cada salida contra los criterios.
3. Verifica el output en los casos límite: peticiones fuera de alcance, datos que no existen, formatos rotos.
4. Cambia una variable por vez: prompt, modelo o herramientas, nunca las tres juntas.

Los errores que encuentres en la prueba se convierten en reglas nuevas del prompt. Así el cerebro del agente aprende de la operación real, no de lo que crees que va a pasar. La guía de evals prácticos para agentes explica cómo armar esa suite sin morir en el intento.

Errores comunes al escribir system prompts

• Mezclar reglas con peticiones: instrucciones permanentes dentro del user prompt se pierden o el usuario las sobrescribe.
• Describir en lugar de especificar: "se amable" no dice nada; "saluda con una línea, responde directo y cierra con el siguiente paso" sí.
• Límites vagos: "no inventes cosas" falla; "nunca afirmes estado, fecha o monto sin consultar la herramienta" funciona.
• Formato libre: sin estructura de salida, parsear respuestas es un infierno de regex frágiles.
• Escribir para impresionar: el prompt es código, no literatura. Cada palabra debe cambiar una decisión o sobra.

Checklist de verificación de tu system prompt

1. El rol y la misión están en una línea y son verificables.
2. El contexto del negocio dice cuál es la fuente de verdad de los datos.
3. Cada regla describe una decisión concreta, no un sentimiento.
4. Los límites dicen qué no hacer y cuándo escalar.
5. El formato de salida es parseable y se validó con casos reales.
6. El prompt entero cabe en menos de una pantalla y no se contradice.

Escribir el system prompt como contrato —corto, explícito y probado— es la inversión con mejor retorno de todo tu agente: mejora calidad, reduce costos y hace el comportamiento predecible. Para el resto del camino de construcción, el hub de guías de construcción de agentes reúne arquitectura, herramientas y plantillas, y el curso gratuito de instalación te deja un agente corriendo para que pruebes tu primer system prompt con datos reales.