Artículos
Deja de pasarle tus SOP a un AI Agent a pelo: usa RFC 2119 (MUST/SHOULD/MAY) para controlar su comportamiento al detalle
Si le metes un SOP humano directamente a un LLM, lo habitual es que el Agent acierte una vez y descarrile tres. En este artículo mostramos cómo reescribir System Prompts y Agent Skills con MUST, SHOULD y MAY de RFC 2119 para delimitar restricciones duras, recomendaciones firmes y margen discrecional, junto con tres principios para llevarlo a producción.
· 4 min de lectura
Al llevar un Agent a producción, el error más típico en muchos equipos es volcar tal cual un documento de Word o Notion con el «SOP humano» en el LLM, esperando que se apañe solo. El resultado suele parecer una lotería: acierta una vez y descarrila tres.
El problema no es que al modelo le falte potencia, sino que los SOP humanos van cargados de «conocimiento tácito (Tacit Knowledge)». El cerebro humano deduce de forma natural que «si el importe es inferior a 500 euros no hace falta aprobación» o que «si este paso da error, se puede ignorar y seguir»; pero para un LLM, el texto no estructurado carece de límites de prioridad, así que se limita a improvisar.
Para lograr que el comportamiento de un Agent sea determinista, el primer paso no pasa por cambiar a un modelo más grande, sino por adoptar un estándar clásico de las especificaciones de protocolos de red: la gradación semántica de RFC 2119.
La conclusión por adelantado: marca únicamente el cumplimiento normativo, la seguridad y el Schema troncal como MUST; confía el resto de límites a SHOULD y MAY; y delega los puntos de alto riesgo en la revisión humana.
¿Por qué RFC 2119?#
Al redactar un System Prompt, un Agent Skill o una Workflow Rule, expresiones ambiguas como «ten en cuenta», «a ser posible» o «procura» carecen de fuerza vinculante para el modelo. Pasar a niveles verbales explícitos permite trazar las fronteras de decisión de forma taxativa.
MUST / REQUIRED: restricciones estrictas, cero compromisos#
- Semántica: jamás se puede omitir; no admite excepciones.
- Casos de uso: validación de datos, comprobaciones de seguridad, especificaciones del Schema de salida y bloqueos de alto riesgo.
- Ejemplo: «Antes de invocar la API de facturación,
MUST validar primero si el identificador de empleado existe; si la respuesta viene vacía, MUST interrumpir la ejecución de inmediato».
SHOULD / RECOMMENDED: recomendación firme, pero admite desviaciones justificadas#
- Semántica: debe cumplirse salvo que el contexto aporte un motivo de peso; si se desvía, el Agent tiene que razonar el porqué.
- Casos de uso: selección de estrategias algorítmicas, preferencias de clasificación y lógica de reintentos.
- Ejemplo: «Para Tickets de consulta de clientes,
SHOULD priorizar la asignación a soporte de nivel 1; no obstante, si implica disputas de pagos, se permite reasignar al equipo de revisión financiera».
MAY / OPTIONAL: totalmente opcional, a criterio del modelo#
- Semántica: el modelo puede decidir si lo ejecuta en función de los recursos de contexto disponibles o del presupuesto de tokens.
- Casos de uso: explicaciones complementarias, propuestas de desarrollo adicional y formatos de log opcionales.
- Ejemplo: «Al generar el resumen de resolución,
MAY adjuntar el ID de 1～2 Tickets históricos de casos similares como referencia».
Tres principios para llevarlo a la práctica#
1. Nada de llenar todo con MUST: deja margen para el Reasoning#
Marcar todas las reglas como MUST equivale a tratar el LLM como un Deterministic Compiler, lo que suele derivar en conflictos entre reglas o en bloqueos lógicos al dispararse el Context. Reserva MUST solo para «cumplimiento normativo, seguridad y Schema troncal»; delega el resto de límites en SHOULD.
2. Estructúralo con bloques Markdown#
Divide el Prompt en los cuatro bloques siguientes para que el alcance (Scope) de cada nivel semántico quede claro a simple vista:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. Asocia los puntos de alto riesgo a Human-in-the-loop#
Cuando las condiciones activen un límite MUST crítico (como importes por operación superiores a $5,000 o cambios de privilegios de Admin), la única acción MUST del Agent pasa por «pausar la pipeline y esperar el visto bueno de un operador humano», nunca tomar la decisión en su lugar.
Conclusión: del juguete de Demo a estar Production-Ready#
Trata a tu Agent como una línea de producción industrial, no como un «chico para todo» omnipotente. Establece un contrato de comportamiento mediante RFC 2119 y lograrás que tu Agent deje de ser un juguete de Demo para estar realmente Production-Ready.