Hola, ¿cómo estás? Soy Lena. Hace unos meses estaba viendo a un agente trabajar en una base de código y simplemente… seguía avanzando. Sin pausas, sin verificar nada. Reescribió tres archivos sobre los que no había preguntado, luego sugirió amablemente que podría hacer lo mismo con cuatro más. El código no estaba mal, exactamente. Pero no era correcto de la manera que yo necesitaba.

Ahí fue cuando empecé a prestar más atención a cómo estos agentes están realmente restringidos, no si pueden hacer algo, sino cómo se les indica lo que deberían hacer. Y, más importante, lo que se les dice que nunca deberían hacer sin preguntar primero.

Esto es a lo que se refieren las personas cuando hablan de "superpoderes" en los flujos de trabajo de agentes. Es una palabra un poco engañosa. El superpoder no es la capacidad bruta. Es la habilidad de moldear cómo se usa esa capacidad — de manera consistente, repetible, en cada sesión que ejecuta el agente.

Qué Significa Realmente "Superpoderes" en los Flujos de Trabajo de Agentes

No son funciones — sistemas de restricción de comportamiento

Sigo viendo la palabra "superpoderes" utilizada para describir funciones: ejecución de código, búsqueda web, acceso a herramientas. Esa es una interpretación. Pero cuando observo a personas que realmente están ejecutando agentes en producción, la conversación casi siempre es sobre otra cosa.

Se trata de sistemas de restricción.

La pregunta no es "¿qué puede hacer este agente?" La pregunta es "¿cómo evito que haga lo que no quería, mientras aún le permito hacer lo que sí quería?" Ese es un problema de gobernanza. Y la gobernanza requiere reglas que se apliquen de manera consistente — no recordatorios que pegues en un prompt esperando que se sigan.

Por qué los agentes necesitan reglas, no solo herramientas

Aquí hay algo que noté bastante pronto: los agentes sin restricciones de comportamiento no son malos, son impredecibles. Obtendrán la respuesta correcta la mitad del tiempo y luego harán algo completamente inesperado la otra mitad — no porque el modelo esté roto, sino porque no hay nada que ancle el comportamiento a tus estándares.

Las herramientas le dan alcance a un agente. Las restricciones le dan dirección a un agente.

La mayoría de los equipos tropieza con esta distinción por accidente. Agregan herramientas, ven al agente trabajar, se sorprenden por algo que decidió por sí solo, y luego empiezan a escribir reglas. El modo de fallo te enseña cuál debería haber sido la restricción.

Cómo Funcionan los Superpoderes en las Principales Herramientas

Claude Code — habilidades, CLAUDE.md y alcance de permisos

Claude Code tiene lo que creo es el enfoque más estructurado para este problema. El mecanismo central es el archivo SKILL.md — un archivo markdown con frontmatter en YAML que agrupa instrucciones, scripts y referencias en algo que Claude puede cargar dinámicamente cuando sea relevante.

Lo que encuentro realmente interesante de este diseño es lo que Anthropic llama "divulgación progresiva". Cuando una sesión empieza, Claude solo carga el nombre y la descripción de cada habilidad instalada — no el contenido completo. Las instrucciones completas solo se cargan cuando Claude decide que la habilidad es relevante para la tarea actual. Como describe la documentación oficial de habilidades de agentes: la habilidad es como una guía de incorporación para un nuevo empleado, y el agente lee solo los capítulos que necesita.

También está CLAUDE.md — un archivo persistente que vive en la raíz de tu proyecto y mantiene instrucciones permanentes durante la sesión. A diferencia de las habilidades, siempre está presente. Piénsalo como el contrato base: tus decisiones de arquitectura, tus convenciones de archivos, las cosas que nunca quieres que el agente asuma o pase por alto.

El alcance de los permisos funciona a nivel de herramienta. Defines allowed-tools en el frontmatter YAML de la habilidad para restringir qué comandos de bash, operaciones de archivos o APIs puede invocar la habilidad. Ese detalle me tomó un tiempo apreciarlo completamente. No se trata solo de lo que el agente sabe — se trata de lo que el agente está permitido alcanzar.

Una cosa sobre la que aún no estoy completamente seguro: qué tan bien se mantienen estas restricciones después de que una sesión se vuelve larga y la ventana de contexto empieza a comprimirse. Los documentos de Claude Code mencionan que la auto-compacción lleva las habilidades invocadas hacia adelante, pero las habilidades más antiguas pueden ser descartadas si has cargado muchas en una sesión. He notado un cambio de comportamiento que podría estar relacionado con esto. Tal vez estoy infiriendo demasiado, pero no parece aleatorio.

Cursor — reglas, .cursorrules y el formato MDC

Cursor adopta un enfoque en capas. Tienes tres niveles: Reglas de Usuario (globales, aplican a todo), Reglas de Proyecto (controladas por versión, viven en .cursor/rules/) y el archivo más antiguo .cursorrules en la raíz del proyecto. El formato .cursorrules todavía funciona a comienzos de 2026, pero la documentación oficial de Cursor es clara en que está obsoleto — el camino recomendado es migrar al sistema de reglas de proyecto .mdc para un mejor alcance y control.

El formato MDC añade una capa de metadatos que .cursorrules no tiene: puedes establecer si una regla es alwaysApply, vinculada a globs de archivos específicos, o solo se carga cuando el agente determina que es relevante. Esa última opción — reglas solicitadas por el agente — es más interesante de lo que parece. Significa que el sistema de reglas puede ser sensible al contexto: las reglas de frontend no se cargan para archivos de backend, las restricciones del servicio de pagos no se filtran en módulos no relacionados.

Lo que encontré cuando pasé tiempo con esto: las reglas que mejor funcionan son específicas e imperativas, no vagas y aspiracionales. "Usar TypeScript para todos los archivos nuevos" funciona. "Escribe código limpio y mantenible" no hace nada. Cuanto más precisamente describas lo que quieres — o lo que explícitamente no quieres — más consistentemente lo seguirá el agente.

También hay AGENTS.md en Cursor ahora, que es una alternativa en markdown simple para proyectos que no necesitan toda la carga de metadatos. Más simple, un poco menos flexible.

Codex CLI — AGENTS.md y descubrimiento de instrucciones en capas

La Codex CLI de OpenAI tiene una jerarquía de instrucciones clara que creo vale la pena entender. Cuando inicia una sesión, Codex construye lo que su documentación llama una "cadena de instrucciones" — lee desde tu ~/.codex/AGENTS.md global, luego recorre desde la raíz del proyecto hasta tu directorio actual, recogiendo cualquier archivo AGENTS.md que encuentre en el camino. Los archivos más cercanos a tu directorio actual sobrescriben la guía anterior.

Según la documentación de instrucciones personalizadas de Codex, también puedes colocar archivos AGENTS.override.md en cualquier nivel para hacer explícita la intención de sobrescribir. Para equipos con monorepos o servicios con requisitos muy diferentes — el equipo de pagos, por ejemplo, frente al equipo de analítica — esto significa que puedes tener reglas base compartidas y restricciones específicas de cada servicio que nunca se filtren accidentalmente entre sí.

Codex también adoptó recientemente el mismo patrón SKILL.md. La documentación de habilidades de Codex describe el mismo enfoque de divulgación progresiva: los metadatos de habilidad se cargan primero, las instrucciones completas solo cuando se invoca la habilidad. El ecosistema está convergiendo hacia un lenguaje de diseño compartido aquí, incluso entre diferentes proveedores.

Aprobaciones estrictas y permisos de sandbox limitados son el valor predeterminado correcto — aflójalos solo para flujos de trabajo específicos donde comprendas el radio de impacto.

El Patrón: GitFlow + TDD + Revisión de Código, Automatizado

brainstorming → writing-plans → executing-plans

Este es el patrón de flujo de trabajo al que sigo regresando. La estructura: dividir una tarea de agente en fases distintas, con una habilidad diferente gobernando cada fase.

Una habilidad de lluvia de ideas abre el espacio del problema, genera opciones, identifica casos límite. No se escribe ningún código. Luego, una habilidad de planificación toma el control: plan estructurado, archivos a modificar, pruebas a escribir primero. Solo después de que exista un plan, una habilidad de ejecución comienza a hacer cambios reales.

Esto refleja GitFlow + TDD + revisión de código, excepto que el agente desempeña los tres roles, con un perfil de comportamiento diferente para cada uno. La habilidad de lluvia de ideas puede especular. La habilidad de ejecución está limitada a seguir el plan aprobado.

Por qué esto reduce fallos: cada fase tiene un criterio de éxito más estrecho. Un agente que está "haciendo lluvia de ideas" no escribe accidentalmente código de producción. Un agente que está "ejecutando" no rediseña la arquitectura durante la implementación.

Comencé a usar este patrón después de ver a un agente pasar cuarenta minutos dando vueltas en círculos en una refactorización porque seguía reevaluando sus propias decisiones. Separar las fases no hizo al agente más inteligente. Hizo que el proceso fuera más estable.

Restricciones vs Gobernanza

Reglas de comportamiento local vs ciclo de vida de capacidad a nivel de red

Aquí está el vacío que sigo notando, y honestamente aún no estoy seguro de cómo interpretarlo.

Todos los sistemas de restricciones que he descrito anteriormente son con alcance de sesión. Son locales: viven en archivos, se cargan al inicio de la sesión, y se reinician cuando la sesión termina. Son excelentes para definir comportamiento para un código conocido, un equipo conocido, un conjunto de estándares conocido.

Pero no resuelven una clase diferente de problema: ¿qué pasa con el comportamiento de un agente a lo largo de todo su ciclo de vida? ¿Cómo sabes que una restricción válida hace tres meses todavía aplica después de que el modelo subyacente ha mejorado? ¿Cómo se propagan patrones de comportamiento verificados entre agentes que no comparten un código base?

Las restricciones basadas en archivos no tienen respuesta a esas preguntas. No fueron diseñadas para ello. Aquí es donde la gobernanza, no solo las reglas, comienza a importar. Las restricciones locales son el primer paso. Pero la gobernanza significa rastrear si las restricciones aún funcionan y tener un mecanismo para propagar actualizaciones a través de una red de agentes en lugar de un proyecto a la vez.

Todavía estoy trabajando en cómo se ve eso en la práctica.

Qué pasa cuando las restricciones no son suficientes

Una restricción le dice a un agente cómo comportarse. No te dice si el agente se comportó correctamente después del hecho. Esos son problemas diferentes.

El modo de fallo que veo más a menudo no es un agente que ignora sus reglas. Es un agente que sigue sus reglas a la perfección — en un contexto para el que no se escribieron. Las reglas eran correctas; simplemente no cubrían la nueva situación.

! [imagen] (https://cdn.10b.ai/1776238763277-4.png)

Límites y compensaciones

Deriva de restricciones — reglas que se vuelven obsoletas

Las reglas se vuelven aburridas. Una regla que era exactamente correcta hace seis meses puede estar un poco equivocada ahora: los valores predeterminados del modelo cambiaron, la base de código cambió o el estándar al que hacía referencia se actualizó aguas arriba.

Ningún archivo de reglas se mantiene solo. Los sistemas de restricciones en Claude Code, Cursor y Codex comparten el mismo punto ciego: no hay ningún mecanismo para detectar que una regla se ha vuelto obsoleta. Simplemente deja de funcionar silenciosamente como se esperaba. [Documentación de Cursor] (https://stevekinney.com/courses/ai-development/cursor-rules) y varios profesionales recomiendan auditorías periódicas de reglas — no porque las reglas sean frágiles, sino porque el entorno que las rodea sigue cambiando.

Sin persistencia — las restricciones se reinician en cada sesión

Este es el que sigo volviendo.

Cada sesión empieza de cero. CLAUDE.md vuelve a leer. AGENTS.md se relee. Las habilidades se redescubren. El agente no recuerda qué funcionó la última vez, dónde están los modos de fallo sutiles, qué aprendiste tras tres semanas de depuración.

Puedes codificar ese aprendizaje en tus archivos de reglas — y deberías. Pero codificarlo es manual. El sistema de restricciones no aprende. Aprendes, luego escribes lo que aprendiste, y el sistema de restricciones lo refleja.

Eso es una limitación real. No estoy seguro de que se pueda arreglar dentro de la arquitectura actual. Pero vale la pena dejarlo claro.

Preguntas frecuentes

¿Qué son los superpoderes en los flujos de trabajo de los agentes de IA?

No incluye — sistemas de restricciones. La capacidad de definir reglas de comportamiento consistentes, ámbitos de permisos e instrucciones específicas de fase que el agente sigue en cada sesión.
¿Cómo establezco restricciones de comportamiento en Claude Code?

A través de SKILL.md archivos (frontmatter YAML + instrucciones de markdown, almacenadas en .claude/skills/) y un archivo CLAUDE.md para instrucciones permanentes. Los permisos a nivel de herramienta van en el campo allowed-tools. El repositorio de GitHub de habilidades oficiales de Anthropic tiene ejemplos reales.
¿Cuál es la diferencia entre .cursorrules y CLAUDE.md?

Son para diferentes herramientas. .cursorrules (obsoleto a favor de .cursor/rules/*.mdc) es el formato de Cursor; CLAUDE.md es el archivo de instrucciones persistentes de Claude Code. Ambos mantienen reglas permanentes durante una sesión, pero los mecanismos de alcance son diferentes.

¿Pueden las restricciones del agente persistir entre sesiones?

No de forma nativa. Los archivos de reglas se vuelven a leer al inicio de la sesión. El agente no tiene memoria de sesiones anteriores. Se codifica el comportamiento aprendido en esos archivos manualmente —lo cual es el enfoque correcto—, pero el sistema de restricciones en sí no acumula experiencia.
¿Cuál es el patrón de habilidad brainstorming-escritura-ejecución?

Un flujo de trabajo donde diferentes habilidades rigen diferentes fases: el brainstorming abre el espacio del problema sin escribir código; la planificación produce una propuesta estructurada; la ejecución implementa conforme al plan aprobado. Cada fase tiene criterios de éxito más específicos, lo que reduce los bucles y los cambios de arquitectura a mitad de la implementación.

Probablemente seguiré observando cómo evoluciona esto. Los sistemas de restricciones se están volviendo más sofisticados, y la convergencia entre herramientas hacia SKILL.md como formato compartido es algo que quiero seguir más de cerca. Pero la limitación del alcance de la sesión se siente como un techo que ninguna de las herramientas actuales ha sabido superar. Algo está ocurriendo aquí —solo que aún no lo veo completamente.

Superpoderes de los agentes: Restricciones de comportamiento que funcionan