Anatomía de un system prompt: rol, contexto, restricciones y formato de salida

Este artículo forma parte de la serie Capacitaciones IThreex: contenido derivado de las formaciones internas que damos a nuestro equipo de ingeniería e implementación de agentes IA sobre la plataforma ABLE.

Las cuatro partes que no pueden faltar

Todo system prompt sólido, sin importar el caso de uso, se organiza en cuatro bloques:

1. Rol

Va siempre primero. Define quién es el agente y cuál es su objetivo. "Sos un asistente de soporte técnico de nivel 1 para una empresa de conectividad" comunica mucho más que "eres un asistente útil".

2. Contexto

Esta es la parte que más se subestima. El agente va a recibir datos desde varias fuentes: herramientas MCP, base de conocimiento (RAG), el propio mensaje del usuario. El modelo recibe los datos, pero no sabe para qué sirve cada uno. Hay que decírselo explícitamente: "el dato de la tool A es el saldo del cliente y se usa para calcular la bonificación; el dato de la tool B es el histórico de incidencias y se usa para priorizar el caso".

3. Restricciones

Qué debe y qué no debe hacer para que la respuesta sea confiable: no inventar información, no prometer plazos, no divulgar herramientas configuradas, escalar a un humano en determinados escenarios.

4. Formato de salida

En la mayoría de los casos conviene una salida estructurada (JSON) para tener control programático. Cuando el agente redacta texto —una resolución, un email, un informe— conviene incluir un ejemplo de redacción correcta en lugar de describirla.

Regla práctica: estos cuatro bloques nunca deben mezclarse en un solo párrafo. Cuando se mezclan, el modelo confunde contexto con formato y reglas con rol.

XML, Markdown o JSON: cuándo usar cada uno

Formato	Cuándo conviene
XML	Prompts largos, con muchos pasos y secciones. Los tags delimitan de forma inequívoca dónde empieza y termina cada bloque.
Markdown	Prompts medianos. Títulos y subtítulos separan bien rol, objetivo, contexto, skills, proceso y reglas.
JSON	Agentes desarrollados por código donde se necesita estructura estricta y parseable.

Delimitado vs sin delimitar: la diferencia real

En un prompt sin delimitar, el modelo tiene que inferir por sí mismo qué parte es el rol, cuál es el contexto, cuáles son las reglas y cuál es el formato esperado. Ese razonamiento extra es donde aparecen los errores: mezcla contexto con reglas, o formato con rol.

En un prompt delimitado, esa inferencia no existe. El modelo dedica su atención a resolver la tarea, no a interpretar la estructura de la instrucción.

Prompt largo no es prompt malo

Existe la idea de que hay que "acortar el prompt". Es una simplificación. Lo que hay que eliminar no es longitud: es ambigüedad, repetición y contradicción.

Un patrón concreto: cinco instrucciones sueltas del tipo "no inventes datos", "no agregues información", "no completes vacíos", "no supongas", "no extrapoles" se consolidan en una sola regla conceptual:

Toda afirmación debe derivarse exclusivamente del contexto proporcionado.

Un prompt más corto, más claro, y que el modelo cumple mejor.

La regla crítica va repetida al final

Los modelos prestan más atención al inicio y, sobre todo, al cierre del prompt. Si hay una regla que no se puede violar —típico en casos legales o financieros: "no inventes cláusulas ni normativa"— conviene declararla en el bloque de restricciones y volver a enunciarla como última línea del system prompt.