Contexto, no control
Cada regla en el prompt de tu agente comenzó como un error.
Alguien vio un comportamiento incorrecto, escribió una regla, y siguió adelante. Otra persona hizo lo mismo. Una tercera persona añadió un "nunca hagas X" porque el modelo hizo algo extraño un martes. Nadie eliminó nada.
Seis meses después, el agente dedica más de su ventana de contexto a navegar su reglamento que a pensar en la tarea real.
Eso es el pensamiento de control. Y creo que es uno de los errores de diseño más grandes que los equipos cometen al construir agentes de IA.
Un pequeño ejemplo que revela un patrón más grande
Nos encontramos con un problema en el que un agente activado por una tarea programada seguía creando nuevas tareas programadas desde dentro del run. Recursión infinita, pero con efectos secundarios en el mundo real.
Dos formas de responder.
Estilo control: Prohíbelo. Escribe código que bloquee los programas de crear programas. Añade una regla al prompt: "nunca crees un programa dentro de un programa." Publícalo.
Estilo contexto: Dile al agente qué está pasando realmente.
Fuiste activado por una tarea programada a las 3:00 AM hora del Pacífico. ID de programa: sched_29x8f. Un run programado es una ejecución aislada con un alcance definido que el usuario autorizó originalmente. Crear una nueva tarea programada extendería ese alcance más allá de la autorización original.
El primer enfoque parchea un comportamiento. El segundo le da al agente un modelo de la situación.
Ahora puede razonar sobre preguntas cercanas también: ¿Debería enviar una notificación a las 3 AM? ¿Debería crear un proceso de seguimiento que el usuario no pidió explícitamente? ¿Debería modificar algo que se extiende más allá del alcance del run original?
Sin regla necesaria. El agente lo resolvió por sí mismo.
Muchos equipos recurren al control cuando lo que realmente necesitan es contexto.
La misma distinción aparece dentro de los prompts
Esto no se trata solo de aplicación a nivel de sistema. La división contexto vs control también existe dentro de los prompts.
Prompting estilo contexto: principalmente hechos, mínima opinión:
Estás ejecutándote debido a una tarea programada. Activado a las 3:00 AM hora de Beijing. ID de tarea: sched_29x8f. El usuario autorizó este run para un alcance específico.
Prompting estilo control: con opinión, prescriptivo:
Evita crear programas. Debes notificar al usuario con la herramienta X. Nunca hagas Y a menos que Z.
A veces las instrucciones prescriptivas son útiles. Pero muy a menudo están compensando hechos faltantes. Y una vez que empiezas a compensar de esa manera, se vuelve adictivo.
Cómo los prompts se convierten en burocracia
Este es el modo de fallo más profundo.
Un equipo ve un problema y añade una regla. Luego otra. Luego otra. Cada una parchea un problema local, pero juntas crean un sistema lleno de proxies.
Bezos describió este patrón en su carta de accionistas de 2016: el buen proceso te sirve para que puedas servir a los clientes. Pero si no tienes cuidado, el proceso se convierte en la cosa en sí misma.
Eso es exactamente lo que sucede en los sistemas de agentes.
La regla no es la cosa. La regla es un proxy para el resultado que deseas. Y los proxies se acumulan. Uno crea casos límite que requieren más. Pronto el agente está razonando a través de capas de instrucciones acumuladas, cada una añadida por alguna razón histórica que nadie recuerda completamente.
En organizaciones humanas, esto se convierte en burocracia. En sistemas de agentes, se convierte en un prompt gigante lleno de tejido cicatrizal.
Los hechos envejecen. Las opiniones se pudren.
Un hecho como "este run fue activado por una tarea programada a las 3 AM" es estable. Sigue siendo verdad independientemente de qué modelo lo lea: Claude, GPT, Gemini, lo que sea que salga el próximo trimestre.
Una declaración como "deberías evitar crear sub-programas" es frágil. Depende de la interpretación. Puede ayudar en una situación y fallar silenciosamente en otra.
Cuando cambias de modelos, cada opinión en tu prompt es una mina potencial. El nuevo modelo tiene diferentes tendencias de razonamiento, y tu cuidadosamente calibrado "evita" podría significar algo completamente diferente para él.
Pero los hechos fundamentados sobre el entorno, los permisos, el alcance y las restricciones tienden a generalizarse entre modelos y casos límite. Por eso los hechos son el mejor material de construcción.
La trampa del Quirk del modelo
Esta podría ser la versión más insidiosa del problema de control: los equipos constantemente convierten los defectos temporales del modelo en estructura permanente del sistema.
Un modelo se comporta mal en algún caso estrecho. El equipo añade una salvaguarda: un parche de prompt, una verificación de código, una rama extraña que solo existe para detener un modo de fallo específico.
Ese parche es una apuesta a que el quirk persista. Casi nunca lo hace.
Tres meses después, el modelo cambia. El comportamiento original desaparece. Pero el parche permanece. Nadie quiere eliminarlo, porque quizás estaba ahí por una razón.
Así es como los prompts de sistema se convierten en código heredado.
Podemos reconocer fácilmente el peligro cuando se plantea de forma abstracta. Pero en la práctica, parchear las tendencias de razonamiento actuales de Sonnet en prompt tras prompt es el mismo patrón disfrazado.
Documentar el comportamiento estable del sistema es valioso. Parchear las tendencias de razonamiento de un modelo es una cinta de correr. El modelo cambiará debajo de ti más rápido de lo que puedes mantener tus parches.
Un buen caso de prueba: Permiso denegado
Puedes ver la distinción claramente en los diagnósticos de herramientas. Cuando un agente se encuentra con un error de permisos:
Estilo control:
TOKEN falta. Ejecuta "zero permissions request gmail.send" para arreglarlo.
Directo, pero el agente no aprende nada. La próxima vez que se encuentre con un error de permisos diferente, estará atascado.
Estilo contexto:
process.env.GMAIL_TOKEN → existe zero connectors inspect gmail → conectado zero permissions inspect gmail.send → denegado
Opciones:
- Solicitar aprobación del usuario para gmail.send
- Usar una ruta ya autorizada si existe una
El agente ahora sabe que el token existe, el conector funciona y el permiso específico está denegado. Entiende el estado del sistema y puede razonar sobre situaciones novedosas que el escritor de reglas nunca anticipó.
La heurística
A esto es a lo que sigo volviendo:
Cada vez que estés a punto de escribir "no", "evita" o "nunca" en un prompt. Detente. Pregunta: ¿qué hecho está compensando esta regla?
Generalmente hay un hecho faltante. El agente no entiende en qué entorno está, qué autorizó el usuario, qué acciones son irreversibles, o por qué este run difiere de una interacción normal de chat.
Escribe ese hecho. Elimina la regla.
A veces seguirás queriendo la restricción, especialmente en torno a acciones destructivas, movimiento de dinero o límites de seguridad. Los controles estrictos aún importan.
Pero muchas reglas de prompts no son verdaderos límites. Son compensaciones por comprensión faltante. Y esas son exactamente las que se acumulan y se pudren.
El objetivo
El objetivo no es un agente que memoriza una lista de verificación.
El objetivo es un agente que entiende su situación lo suficientemente bien como para tomar buenas decisiones dentro de límites claros.
Una filosofía controla el comportamiento apilando reglas. La otra mejora el comportamiento haciendo el mundo legible.
La primera tiende hacia la burocracia. La segunda tiende hacia la comprensión.
Construye contexto. Elimina el tejido cicatrizal. Entrega agentes que puedan pensar.
