Artículos
Deja de aventarle SOPs directo a tu AI Agent: usa RFC 2119 (MUST/SHOULD/MAY) para controlar su comportamiento con precisión
Si le metes un SOP humano directo a un LLM, el Agent suele funcionar bien una vez y tronar tres. Aquí te muestro cómo reescribir tu System Prompt y Agent Skill con MUST, SHOULD y MAY de RFC 2119, marcando restricciones duras, recomendaciones fuertes y discrecionalidad, junto con tres principios para llevarlo a producción.
· 4 min de lectura
Al implementar Agents, la trampa más común en los equipos es agarrar un documento entero de Word o Notion con el «SOP humano», encajárselo directo al LLM y esperar que lo resuelva en automático. El resultado suele ser como jugar a la lotería: una vez sale bien y tres se va al carajo.
La bronca no es que al modelo le falte capacidad, sino que los SOPs humanos traen un montón de «conocimiento tácito (Tacit Knowledge)». El cerebro humano deduce en automático que «si el monto es menor a 500 no requiere firma» o que «si este paso tira error, te lo puedes saltar por ahora»; pero para un LLM, el texto no estructurado no tiene límites de jerarquía ni fuerza, así que no le queda de otra que improvisar.
Para que el comportamiento de un Agent sea determinista, el primer paso no es cambiar a un modelo más grande, sino adoptar un estándar clásico de especificaciones de protocolos de red: la semántica de niveles de RFC 2119.
Al grano: marca como MUST únicamente el cumplimiento normativo, la seguridad y los Schemas críticos; delega el resto de los límites a SHOULD y MAY; y deja los nodos de alto riesgo en manos de revisión humana.
¿Por qué RFC 2119?#
Al armar un System Prompt, Agent Skill o Workflow Rule, frases vagas como «por favor toma en cuenta», «de preferencia» o «haz lo posible por» no le ponen ningún límite real al modelo. En cambio, usar niveles de verbos explícitos traza fronteras de decisión tajantes e ineludibles.
MUST / REQUIRED: Restricción dura, cero tolerancia#
- Semántica: Jamás se puede omitir, no admite excepciones.
- Escenarios de aplicación: Validación de datos, revisiones de seguridad, contratos de salida de Schema, bloqueos de alto riesgo.
- Ejemplo: «Antes de invocar el API de facturación,
MUST validar primero que el ID de empleado exista; si la respuesta viene vacía, MUST abortar la ejecución de inmediato.»
SHOULD / RECOMMENDED: Recomendación fuerte, pero permite desviaciones justificadas#
- Semántica: A menos que haya una razón de Context sumamente sólida, se tiene que cumplir; si el Agent se desvía, está obligado a justificar su Reasoning.
- Escenarios de aplicación: Selección de estrategias de algoritmos, preferencias de clasificación, lógica de reintentos.
- Ejemplo: «Para Tickets de consulta de clientes,
SHOULD priorizar la asignación a soporte de primer nivel; pero si hay disputas de pagos o flujo de dinero, se permite reasignar al equipo de auditoría financiera.»
MAY / OPTIONAL: Opcional y a criterio propio, total discrecionalidad#
- Semántica: El modelo puede decidir por su cuenta si lo ejecuta o no, según los recursos del Context actual o el presupuesto de tokens.
- Escenarios de aplicación: Notas complementarias, sugerencias de análisis extendido, formatos de logs opcionales.
- Ejemplo: «Al generar el resumen de atención,
MAY adjuntar 1～2 IDs de Tickets históricos de referencia para casos similares.»
Tres principios para llevarlo a la práctica#
1. No llenes todo de MUST: deja margen para el Reasoning#
Marcar cada regla como MUST equivale a tratar al LLM como si fuera un Deterministic Compiler, lo que suele detonar conflictos entre reglas o deadlocks lógicos cuando el Context se satura. Reserva MUST únicamente para «cumplimiento normativo, seguridad y Schema central», y deja los demás márgenes en manos de SHOULD.
2. Acompáñalo con bloques de Markdown estructurados#
Estructura el Prompt en estos cuatro bloques para que el Scope de la fuerza semántica quede claro de un vistazo:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. Ata los nodos de alto riesgo a Human-in-the-loop#
Cuando las condiciones detonen un límite crítico de tipo MUST (como una transacción individual > $5,000 o cambios de permisos de Admin), el único comportamiento MUST del Agent es «pausar el pipeline y esperar a que un humano revise y dé el visto bueno», en lugar de tomar la decisión por las personas.
Conclusión: pasar de juguete de Demo a Production-Ready#
Trata a tu Agent como una línea de producción industrial, no como un «todólogo todopoderoso». Al definir un contrato de comportamiento con RFC 2119, tu Agent por fin podrá dejar de ser un juguete de Demo y convertirse en una solución Production-Ready para producción real.