Cómo las rules y policies centralizadas de Elastra aplican gobernanza en todos los agentes de IA

Cuando los agentes de código IA operan sin gobernanza centralizada, el comportamiento se convierte en función de la sesión individual: lo que el ingeniero escribió en el system prompt hoy, lo que el IDE captó de un archivo de configuración local, lo que el modelo decidió basándose en su comportamiento por defecto. El resultado es deriva comportamental — agentes que producen output inconsistente entre ingenieros, IDEs y sesiones, sin mecanismo para detectar, medir o corregir.

Las consecuencias operacionales son bien conocidas por los equipos que las han vivido. Inconsistencias de estilo de código que sobreviven la revisión porque los revisores no tienen contexto sobre qué se le dijo al agente. Decisiones que contradicen las guidelines de arquitectura porque el agente nunca las recibió. Prompting correctivo repetido que consume tiempo de ingeniería e introduce nueva variabilidad con cada iteración.

La causa raíz es arquitectural: si las rules viven en el cliente — en un archivo local, una configuración de IDE o un system prompt mantenido manualmente — entonces la gobernanza es por ingeniero, por sesión y por máquina. No hay single source of truth, sin precedencia aplicada, sin audit trail y sin mecanismo para que la organización ejerza control.

La respuesta de Elastra es mover la gobernanza al backend: las rules se almacenan en la base de datos, se resuelven en el servidor y se envían a los agentes a través de canales aplicados — independientemente del IDE, modelo o ingeniero involucrado en la sesión.

Elastra almacena rules en seis scopes distintos: organización, proyecto, namespace, repositorio, equipo y usuario. Cada scope sirve un propósito de gobernanza diferente. Las rules de organización definen la baseline que se aplica en todos lados. Las rules de proyecto especifican constraints y convenciones para un proyecto dado. Las rules de namespace restringen el comportamiento a un contexto de trabajo específico dentro de un proyecto. Las rules de repositorio se aplican a una codebase específica. Las rules de equipo reflejan convenciones compartidas para un equipo de ingeniería dado. Las rules de usuario permiten preferencia individual dentro de los límites establecidos por los scopes superiores.

Cuando un agente solicita su effective ruleset — mediante el comando CLI elastra rules materialize o la herramienta MCP elastra_rules — el backend resuelve todas las capas aplicables y las fusiona en un único EffectiveRuleset. La resolución sigue una precedencia determinística: las rules de usuario tienen máxima prioridad, seguidas de las rules de repositorio, rules de namespace, rules de equipo, rules de proyecto y rules de organización como baseline. El output fusionado es un único documento Markdown que el agente recibe como instrucciones de operación.

Esta arquitectura tiene una propiedad crítica: la organización siempre tiene voz. Aunque un usuario tenga rules personales o un proyecto tenga overrides específicos, la capa de organización no puede eliminarse del pipeline de resolución. La baseline siempre se aplica. Una policy establecida a nivel de organización es una constraint, no una sugerencia.

Las rules se persisten en PostgreSQL a través de la Console API de Elastra. Todas las operaciones CRUD — create, read, update y delete — requieren la capability ManageRules, que es una named role capability aplicada en la capa del servidor antes de que se ejecute cualquier lógica de handler. Un ingeniero sin esta capability no puede leer ni escribir rules para la organización, independientemente de cómo interactúe con la API.

Cada operación de rules se registra como un evento de consola auditable con un payload estructurado: el actor (sesión y usuario), la organización, el scope target (UUID de proyecto, UUID de namespace, UUID de repositorio) y la operación realizada. Estos eventos se almacenan y son consultables, proporcionando un registro trazable de quién cambió qué rule, cuándo y para qué scope. Este es el audit trail que hace que la gobernanza centralizada sea operacional y no teórica.

Cuando se crea o actualiza una rule, el backend sincroniza automáticamente su contenido con la knowledge base como un documento estructurado. Esto significa que las rules no solo son aplicables a través de materialización y la herramienta MCP — también son recuperables como contexto de primera clase cuando un agente realiza una búsqueda semántica. Un agente buscando convenciones de código encontrará las rules de la organización en los resultados. Esta sincronización ocurre de forma síncrona en la escritura y se registra como advertencia si falla, garantizando que el contenido de las rules sea siempre descubrible.

El primer mecanismo de aplicación es la materialización. Cuando un ingeniero ejecuta elastra rules materialize en un repositorio, el CLI obtiene el effective ruleset del endpoint del backend GET /v1/rules/effective — pasando UUID de proyecto, UUID de namespace y UUID de repositorio como parámetros — y escribe el Markdown fusionado en un conjunto de archivos específicos de agente.

Elastra mantiene una lista fija de materialization targets, uno por agente soportado. Al momento de escribir, estos incluyen: Claude Code (.claude/rules/elastra.md), Cline (.clinerules/elastra.md), Cursor (.cursor/rules/elastra.mdc), Windsurf (.windsurf/rules/elastra.md), Gemini CLI (GEMINI.md), Kiro (.kiro/steering/elastra.md), Augment (CLAUDE.md), Continue (.continue/rules/elastra.md), goose (.goosehints), Roo Code (.roo/rules/elastra.md), Amp (.agents/checks/elastra.md), GitHub Copilot (.github/copilot-instructions.md) y Kimi (.kimi/rules/elastra.md).

Cada archivo recibe el mismo contenido fusionado, envuelto en marcadores de comentario HTML estructurados (<!-- elastra:rules:v1 start --> y <!-- elastra:rules:v1 end -->) que permiten al CLI identificar, actualizar o eliminar el bloque con precisión sin tocar el resto del archivo. Si las rules se eliminan de la base de datos y la materialización se ejecuta nuevamente, los bloques se eliminan automáticamente de todos los archivos target — evitando que rules obsoletas persistan en el repositorio.

Este mecanismo garantiza que un agente operando desde contexto local — leyendo el archivo de rules específico de su IDE al inicio — ya tiene las rules efectivas actuales de la organización embebidas. No se requiere ninguna llamada de red durante la sesión para que esta capa funcione. Las rules fueron obtenidas del backend cuando el ingeniero configuró su workspace.

La materialización gestiona el inicio: las rules están embebidas en los archivos locales antes de que comience la sesión. Pero las rules cambian. Las policies de la organización evolucionan, las constraints de proyecto se actualizan, se introducen nuevas convenciones de namespace. Un archivo materializado escrito la semana pasada puede no reflejar el effective ruleset actual.

El segundo mecanismo de aplicación aborda esto: la herramienta MCP elastra_rules. Cuando un agente llama a esta herramienta durante una sesión, el servidor MCP de Elastra obtiene el effective ruleset actual directamente del backend — accediendo a GET /v1/rules/effective con el scope de proyecto, namespace y repositorio actual — y devuelve el Markdown fusionado como respuesta de herramienta. El agente recibe las rules actuales y live, no una copia local en caché.

Esto crea un modelo de gobernanza pull-on-demand. El agente puede solicitar sus rules en cualquier punto durante una sesión — al inicio de una tarea, cuando se acerca a una decisión sensible o después de detectar que el scope de la tarea cambió. Las rules devueltas son siempre la versión actual del backend, aplicadas por RBAC y auditadas a nivel de API.

Combinado con la materialización, esto da a las organizaciones dos capas de aplicación de rules: una capa de startup que embebe las rules antes de que comience la sesión y una capa live que mantiene al agente sincronizado con la policy organizacional actual durante la sesión. Ninguna capa es opcional — ambas son parte del contrato de gobernanza.

Más allá de las rules en sí, Elastra aplica un contrato comportamental al inicio de cada sesión de agente a través del archivo ELASTRA.md. Este archivo es escrito en cada workspace por el CLI durante la configuración y define las reglas de operación que el agente debe seguir antes de que comience cualquier tarea.

El constraint más crítico en ELASTRA.md es la regla obligatoria de contexto primero: la primera acción del agente en cualquier tarea debe ser llamar a elastra_context. No puede hacer grep de archivos, glob de directorios o leer código local como primer paso. Debe consultar la knowledge base de Elastra para arquitectura, flujos y contexto relevante antes de tocar archivos locales. Esto no es una preferencia — es un paso obligatorio, y el archivo bootstrap lo hace explícito con un marcador de advertencia.

El bloque bootstrap también especifica la política de write-back obligatoria: si la sesión produce hallazgos duraderos, cambios de código o conclusiones, el agente debe llamar a elastra_sync o elastra_memory_write antes de responder. Esto crea un ciclo de gobernanza que va más allá de leer rules — gobierna cómo se preserva el conocimiento producido durante la sesión y se pone a disposición de sesiones futuras.

Este modelo contract-first garantiza que la gobernanza no es meramente inyectada como instrucciones que el agente puede o no seguir. Las instrucciones son obligatorias, auditables y estructuralmente colocadas antes de cualquier lógica de tarea. Un agente que las viola debe reconocer y explicar explícitamente la violación al usuario.

Las rules gobiernan lo que el agente debe y no debe hacer. El sistema de personas gobierna lo que el agente es. Una persona es un AgentProfile almacenado en la base de datos con un slug, un nombre, un system prompt, una lista de herramientas permitidas y flags operacionales como enabled e isDefault. Las personas tienen scope de organización, son controladas por RBAC y se resuelven centralmente.

Cuando comienza una sesión de agente, el system prompt de la persona activa se inyecta junto con las rules en los archivos materializados, envuelto en sus propios marcadores de bloque (<!-- elastra:persona:v1 start --> y <!-- elastra:persona:v1 end -->). Esto significa que la identidad del agente — su rol, su formato de output, su modo de operación — también es definida por la organización, no dejada a la configuración individual.

La combinación de rules y persona crea una especificación comportamental completa. Las rules definen las constraints de operación. La persona define el contexto de operación, el formato de output y el rol. Juntas describen exactamente qué tipo de agente está ejecutando la organización en esta sesión, y ambas son trazables al backend, versionadas a través de operaciones de update y auditables a través del registro de eventos de la consola.

La arquitectura descrita anteriormente tiene una implicación práctica: la superficie de control de la organización sobre el comportamiento de los agentes de IA es real y operacional, no aspiracional. Las rules están en una base de datos. Están versionadas. Están auditadas. Se aplican a través de dos canales complementarios — materialización en el inicio y recuperación MCP live. Se aplican a todos los agentes, todos los IDEs y todas las sesiones sin requerir configuración individual por cada ingeniero.

Esto cambia la economía de la ingeniería asistida por IA. Sin gobernanza centralizada, el agente de cada miembro del equipo se comporta de manera diferente, la deriva se acumula invisiblemente y el esfuerzo correctivo escala con el tamaño del equipo. Con gobernanza centralizada, la consistencia comportamental se convierte en una propiedad de la infraestructura, no en una función de la disciplina individual. El costo marginal de agregar un nuevo ingeniero a un equipo asistido por IA cae porque la capa de gobernanza absorbe el overhead de configuración.

También cambia el perfil de riesgo. Rules y personas están auditadas. Los cambios son trazables. Cuando ocurre un incidente de producción que involucra el comportamiento del agente, la pregunta '¿qué rules estaba operando el agente en ese momento?' tiene una respuesta precisa, respaldada por la base de datos. Esa trazabilidad no es una conveniencia de debugging — es un requisito de gobernanza para equipos que operan IA a escala de producción.

La organización que despliega Elastra no solo está usando una herramienta de IA. Está operando un sistema gobernado: uno donde los límites comportamentales se definen centralmente, se aplican automáticamente, se actualizan sin interrumpir flujos de trabajo individuales y se auditan sin requerir procesos manuales de compliance. Eso es lo que hace que la ingeniería asistida por IA sea una capacidad operacional repetible y no un experimento de productividad.