Cómo escribir prompts de sistema para agentes de IA que no fallen en producción

Tabla de contenidos

Actualizado julio 2026.

TL;DR: Un prompt de sistema en producción tiene cinco capas: identidad (quién es el agente y qué no puede hacer), contexto (qué sabe sobre el entorno), tarea (cómo se ve el éxito paso a paso), formato de salida (la capa más subestimada) y casos extremos (qué hacer cuando las entradas fallan). La mayoría de los prompts fallan porque omiten las capas 4 y 5. Escribe el formato de salida antes que cualquier otra cosa — te obliga a ser preciso sobre lo que realmente quieres.

[Perspectiva del operador] Gestiono más de 30 agentes de IA en producción para mi marca de consultoría y Pickleland, una instalación de pádel en Pflugerville, TX. He reescrito más prompts de sistema de los que he escrito — generalmente porque la primera versión parecía funcionar bien en las pruebas y luego se degradaba silenciosamente en producción. Esto es lo que he aprendido sobre cómo escribir prompts que duran.

El problema del prompt de sistema que nadie admite

La mayoría de los prompts de sistema para agentes se escriben en unos 20 minutos, se prueban con dos o tres ejemplos y luego nunca se vuelven a tocar. El modelo se lanza. Por un tiempo, funciona. Luego algo cambia — las entradas se vuelven más complejas, el modelo se actualiza, aparece un caso extremo nuevo — y el agente empieza a producir basura. En silencio. A escala.

El problema no es que el prompt original fuera malo. Es que la mayoría de los prompts se escriben para demostrar el camino feliz. Están diseñados para la entrada que tenías en mente cuando construiste el agente, no para la distribución completa de entradas que el agente verá en realidad.

Los prompts de sistema en producción son diferentes a los prompts de demostración. Deben manejar entradas que no diseñaste, fallar con gracia cuando algo va mal y producir una salida consistente incluso cuando el comportamiento del modelo cambia ligeramente entre versiones.

Las cinco capas de un prompt de sistema en producción

Pienso en cada prompt de sistema que escribo en cinco capas. No tienen que aparecer en este orden — pero todas deben estar presentes.

Capa 1: Identidad

La identidad le dice al modelo quién es y cuáles son sus restricciones operativas. No un personaje de juego de roles — una definición funcional de lo que este agente hace y no hace.

Una capa de identidad sólida responde tres preguntas:

• ¿De qué es responsable este agente?
• ¿De qué NO es responsable explícitamente (y debe escalar o rechazar)?
• ¿Qué estándares mantiene?

Capa de identidad débil:

Eres un agente de atención al cliente útil para una instalación de pádel.

Capa de identidad más sólida:

Eres el asistente de reservas de Pickleland, una instalación de pádel en
Pflugerville, TX. Tu trabajo es responder preguntas sobre disponibilidad
de pistas, opciones de membresía y próximos eventos.

NO gestionas disputas de facturación, solicitudes de reembolso ni quejas
sobre el personal — enruta esas al equipo de operaciones humano a través
de la ruta de escalado definida a continuación.

Respondes con un tono amistoso pero eficiente. Nunca inventas disponibilidad
ni precios. Cuando no sabes algo, lo dices y ofreces tomar un mensaje para
el equipo de operaciones.

El alcance explícito de lo que NO se hace es la parte que la mayoría de los operadores omiten. Sin él, el modelo intentará ser útil fuera de su ámbito — y ahí es donde las cosas salen mal.

Capa 2: Contexto

El contexto es lo que el agente sabe sobre su entorno que no está en el mensaje del usuario. Esto incluye:

• La fecha y hora actuales (inyéctalas dinámicamente — nunca confíes en el sentido interno de tiempo del modelo)
• Estado relevante de sistemas externos (próximos eventos, inventario, detalles de la cuenta del usuario)
• Reglas de negocio que no son obvias a partir de la descripción de la tarea

La mayoría de los agentes que reviso están escasos de contexto. El operador asume que el modelo “sabe” cosas que no sabe — precios actuales, nombres de miembros específicos del personal, qué funcionalidades están activas en el sistema. No lo asumas. Inyéctalo.

Capa 3: Tarea

La capa de tarea describe lo que hace el agente, paso a paso. No “ayudar a los clientes” — el flujo de decisión real.

La trampa aquí es escribir una capa de tarea demasiado abstracta. “Responde la pregunta del cliente” no es una capa de tarea. Una capa de tarea real parece un diagrama de flujo: clasifica la intención, busca la información correcta para esa intención, aplica las reglas de negocio, produce la salida.

Los diagramas de flujo son más robustos que las directivas porque reducen la necesidad del modelo de inferir qué quieres en casos ambiguos.

Capa 4: Formato de salida

Esta es la capa más subestimada, y la más responsable de los fallos silenciosos.

Si no especificas el formato de salida con precisión, el modelo producirá una salida que parece correcta para un lector humano pero que es suficientemente inconsistente como para romper el análisis posterior. He tenido agentes que funcionaron perfectamente durante semanas y luego empezaron a añadir una nueva línea adicional antes del JSON que rompía mi lógica de extracción.

Escribe el formato de salida antes que cualquier otra cosa. Si no puedes describir exactamente cómo quieres que sea la salida, no entiendes la tarea lo suficientemente bien como para automatizarla todavía.

Para la salida estructurada, especifica el esquema exacto:

Devuelve un único objeto JSON con estos campos exactos:
{
  "intent": "availability" | "event" | "membership" | "complaint" | "other",
  "reply": string,
  "escalate": boolean,
  "escalation_note": string
}

No incluyas ningún texto fuera del objeto JSON.
No añadas marcadores de código markdown alrededor del JSON.

Capa 5: Casos extremos

La capa de casos extremos responde: ¿qué hace el agente cuando la entrada es ambigua, incompleta, en el idioma incorrecto, hostil, o claramente incorrecta?

Para cada caso extremo, dale al modelo una ruta de respuesta explícita. Esta capa es tu protección contra el comportamiento predeterminado del modelo en situaciones ambiguas, que generalmente es intentar ser útil — lo que a menudo significa inventar algo.

El punto de apalancamiento: el formato de salida

Si tuviera que elegir una capa en la que invertir más tiempo, sería el formato de salida. Cada acción que toma tu agente — escribir en una base de datos, enviar un mensaje, llamar a una herramienta — depende de analizar la salida del modelo. Si la salida es inconsistente, la acción posterior falla.

Para agentes de alto riesgo, uso el output estructurado de Claude con un esquema JSON definido. El modelo está obligado a llamar a una herramienta con un esquema validado — sin lógica de análisis, sin regex, sin esperar que el JSON esté bien formado.

Cómo mantengo los prompts de sistema con el tiempo

Un prompt de sistema en producción es un documento vivo:

1. Revisión semanal puntual. Reviso cinco a diez salidas aleatorias de cada agente de alto riesgo frente a la salida esperada.
2. Revisión tras actualización del modelo. Cada vez que cambia la versión del modelo subyacente, ejecuto el agente contra el conjunto dorado completo de mi marco de evaluación.
3. Registro de casos extremos. Mantengo un registro de entradas que el agente manejó mal. Cuando tres o más entradas comparten un patrón, añado una regla explícita.
4. Versionado del prompt. Cada cambio significativo recibe un comentario de versión en el archivo del prompt.

Preguntas frecuentes

¿Cuánto debe durar un prompt de sistema en producción?

Lo suficientemente largo como para cubrir las cinco capas. Lo suficientemente corto como para que puedas leerlo en dos minutos y detectar la deriva. Para la mayoría de mis agentes, eso son 200–600 palabras.

¿Cuándo debo dividir una tarea compleja en múltiples agentes en lugar de un prompt largo?

Cuando la tarea tiene dos o más modos distintos que requieren contexto diferente, formatos de salida diferentes o manejo de errores diferente. Consulta agentes por eventos vs programados para el patrón.

¿Cuál es la razón más común por la que un prompt que funcionó en las pruebas falla en producción?

Las entradas de prueba no eran representativas de la distribución de producción. Construye un conjunto de pruebas a partir del tráfico de producción real, no de entradas imaginadas.

¿Cómo sé cuándo actualizar el prompt vs actualizar el código?

Si el agente produce el formato de salida incorrecto, actualiza el prompt. Si el agente produce la salida correcta pero el sistema posterior no puede usarla, actualiza el código. Si el agente produce hechos incorrectos con confianza, verifica primero la capa de contexto.