Permítame ser cuidadoso. Este post no se trata de explotar material filtrado ni de hacer jailbreak a sistemas. No me interesa ninguna de las dos cosas, y a usted tampoco le debería interesar si está dirigiendo una empresa de verdad. Lo que me interesa es lo que la estructura de un system prompt de producción profundamente pensado nos enseña sobre cómo darle instrucciones a agentes de IA que realmente funcionan en el mundo real — bajo presión, a escala, con usuarios reales tratando de romper cosas.
Anthropic de hecho ha publicado mucho del material relevante por su cuenta — vea sus notas oficiales sobre system prompts — y Simon Willison ha sido el mejor cronista público de cómo están estructurados estos prompts y qué revelan. Los prompts filtrados son valiosos no porque revelen secretos. Son valiosos porque muestran, a escala de producción seria, cómo un equipo que de verdad sabe lo que hace escribe instrucciones para un modelo poderoso. Y casi nada en cómo escriben instrucciones se parece a lo que la mayoría de los fundadores y operadores hacen cuando le dan un prompt a un agente.
Lección uno: la estructura es la instrucción
Lo primero que le pega al leer cualquier prompt serio de producción es la cantidad de andamiaje estructural. Secciones con encabezados. Reglas numeradas. Definiciones de rol explícitas. Etiquetas tipo XML para distintas categorías de instrucción. No es estilístico. Esto es la instrucción.
Cuando uno le tira un muro de texto a un modelo, el modelo tiene que inferir qué significan las distintas partes del prompt y cómo se relacionan entre sí. Cuando usted le da al modelo estructura explícita — "esta sección es sobre seguridad, esta sección es sobre uso de herramientas, esta sección es sobre cuándo rechazar" — ya hizo la mitad del trabajo de prompt engineering antes de escribir los encabezados.
La mayoría de los fundadores que conozco escriben prompts que parecen un correo. Un saludo, un párrafo, una solicitud, una despedida. Eso funciona para un becario inteligente que conoce su empresa. No funciona para un modelo operando bajo condiciones adversas a escala.
Lección dos: las reglas le ganan a los ejemplos. Los ejemplos le ganan a las abstracciones.
Un prompt serio de producción usa una estratificación muy específica. Reglas duras arriba ("nunca hagas X"). Ejemplos concretos en el medio. Principios abstractos al final como respaldo. Los prompts filtrados de Claude Code siguen este patrón casi a la perfección.
Lo que la mayoría de los prompts escritos por operadores hacen es lo opuesto. Arrancan con abstracciones vagas — "sé útil y preciso" — y nunca dan una regla dura ni un ejemplo concreto. El modelo hace lo mejor que puede, pero no tiene anclaje. Su comportamiento deriva de maneras que usted no puede predecir, no puede reproducir y no puede depurar.
Mi conclusión después de leer con cuidado. Cada instrucción que le doy a un agente debe incluir al menos un ejemplo concreto de cómo se ve la salida correcta. Si no puedo escribir ese ejemplo, no entiendo lo suficientemente bien lo que quiero como para pedirlo — y el agente definitivamente no lo va a entender.
Si no puede mostrarle al agente un buen ejemplo de lo que quiere, el agente no puede construirlo por usted. El ejemplo es la especificación.
Lección tres: el comportamiento de rechazo es un problema de diseño, no de seguridad
Una porción enorme del prompt es sobre cuándo y cómo el modelo debe negarse a hacer algo. No solo "cosas ilegales". Toda una taxonomía de cuándo rechazar, cuándo empujar de vuelta, cuándo pedir preguntas aclaratorias, cuándo seguir adelante. Esa taxonomía está diseñada, no asumida.
Si está construyendo un producto agente para su empresa, el comportamiento de "rechazar" no es una idea de último momento. Es la parte de mayor apalancamiento de su prompt. Porque cada vez que el agente dice "voy a hacer mi mejor esfuerzo" cuando debería haber dicho "necesito más información" — o dice "no puedo ayudar con eso" cuando debería haberlo intentado — está quemando confianza con el usuario y entrenándolo a que rodee a su agente. "Haz lo que dices, di lo que haces" también aplica para los agentes. Si el agente no puede trazar una línea clara alrededor de lo que va a hacer y lo que no, va a decir sí a cosas que no debería y no a cosas que sí.
Diseñe su taxonomía de rechazo antes de diseñar el happy path. Es la jugada adulta.
Lección cuatro: las instrucciones de uso de herramientas merecen más palabras que las instrucciones de tareas
En el prompt, las instrucciones sobre cómo y cuándo usar herramientas son significativamente más largas que las instrucciones sobre qué tareas realizar. No es accidente. El uso de herramientas es donde los agentes fallan en el mundo real. Llamando a la herramienta equivocada. Llamando a la herramienta correcta con los argumentos equivocados. Llamando herramientas en el orden equivocado. Llamando una herramienta cuando deberían haber hecho primero una pregunta aclaratoria.
Si el agente de su empresa tiene acceso a cualquier herramienta — una base de datos, un API, un sistema de archivos, un índice de búsqueda — debería estar gastando al menos el 60% de su tiempo de prompt engineering en las instrucciones de uso de herramientas. No en la personalidad. No en el tono. La mecánica de cuándo echar mano de cada herramienta y cómo verificar que hizo lo que dijo que iba a hacer.
Lección cinco: el prompt es una política, no una conversación
El cambio de pensamiento más importante que me dio leer un prompt real de producción. El system prompt no es un mensaje. Es una política. Es la constitución escrita bajo la cual opera el agente. Debe escribirse como un documento legal — preciso, sin ambigüedades, con prioridad explícita entre reglas en conflicto, con lenguaje específico sobre casos límite.
La mayoría de los prompts escritos por fundadores son conversacionales. Se leen como un mensaje de Slack a un nuevo empleado. El agente resultante se comporta como un nuevo empleado que tuvo un onboarding de cinco minutos. Entusiasta. En su mayoría útil. Ocasionalmente desastroso. Inconsistente día a día.
Reescriba el system prompt de su agente como si lo fuera a leer un abogado. No porque quiera que su agente suene como un abogado, sino porque la precisión que se requiere para escribirlo así es precisamente lo que su agente necesita para comportarse de manera consistente cuando mil usuarios lo estén golpeando simultáneamente.
Lo que hice después de leerlo
Tres cambios prácticos que hice a cómo escribo prompts para mis propias herramientas:
- Ahora empiezo cada nuevo prompt de agente con un esquema estructural — rol, reglas duras, instrucciones de uso de herramientas, ejemplos, taxonomía de rechazo, casos límite — antes de escribir una sola oración de contenido.
- Me obligo a escribir al menos tres ejemplos concretos por cada instrucción importante. Si no puedo, la instrucción aún no está bien definida. Eso es una señal para mí, no una derrota.
- Trato al prompt como política versionada. Cada cambio recibe un mensaje de commit. Cada cambio se prueba contra el mismo conjunto de escenarios. Nada de ediciones vaqueras a la 1 a.m.
No necesita leer ningún prompt filtrado para adoptar estos hábitos. Pero si alguna vez le llegan a las manos un prompt serio de producción — léalo una vez, con cuidado, con la mente abierta. Le va a enseñar más sobre cómo instruir a un agente de IA que cualquier blog post sobre prompt engineering, incluido este.
Aquí va el reto. Abra el system prompt que esté impulsando ahora mismo a su agente más importante. Léalo como si fuera un abogado auditando un contrato. Por cada oración pregúntese: ¿esta regla es concreta, hay un ejemplo, el orden de prioridad sobrevive a una contradicción? Si la respuesta es no a cualquiera de las tres, reescríbalo esta semana. La diferencia entre un agente que funciona y uno que lo avergüenza un martes en la tarde casi siempre está en el prompt, no en el modelo.
Para ver cómo cableo todo esto al día a día operativo, vea la IA dentro de la cabina del operador.