01 · Identidad
- El agente actúa con su propia identidad, no con una clave compartida
- Agentes caducados o revocados → 403
- Propietario, nivel de riesgo y alcance en cada ejecución
Arquitectura
Cómo gobierna Cortex cada ejecución.
Cada acción de un agente recorre el mismo ciclo de vida — de la persona al resultado — y las mismas ocho compuertas, registradas en un ledger que hace evidente cualquier manipulación. Un runtime, ~22 servicios, un solo esquema de Postgres, y los modelos y el despliegue que tú elijas.
Persona → Agente → Skill → Prompt → Política → Modelo → Herramienta → Artefacto → Resultado → Aprobación
El ciclo de vida del agente
Diez saltos, totalmente enlazados, de la intención humana a la aprobación firmada.
Cortex no ejecuta un prompt dentro de una caja negra. Cada ejecución es una cadena de saltos tipados y atribuidos, y cada eslabón queda capturado para que cualquier resultado pueda rastrearse hasta la persona que lo desencadenó y la política que lo permitió.
- 01
Humano → Agente → Skill
Una persona (o una programación, un canal o un flujo de trabajo) invoca a un agente registrado que actúa bajo su propia identidad — y a una skill declarada concreta, nunca al modelo en bruto.
- 02
Prompt → Política → Modelo
El prompt compuesto queda ligado a una decisión de política. Solo entonces la ejecución llega a un modelo permitido — proveedor y versión verificados contra la identidad del agente.
- 03
Herramienta → Artefacto → Resultado → Aprobación
Las llamadas a herramientas pasan por el MCP gateway, generan artefactos atribuidos y se consolidan en un resultado con comprobante firmado; los resultados de alto riesgo esperan aprobación humana.
La cadena de compuertas
Ocho compuertas. Denegar es lo predeterminado.
Entre el prompt y la ejecución, toda ejecución pasa por las mismas compuertas y en el mismo orden. Cualquier compuerta puede cerrarse ante un fallo, y cuando lo hace, la ejecución se detiene con un código específico y auditable en lugar de continuar en silencio.
02 · Presupuesto
- Topes en USD a 30 días por tenant y por agente
- El tope duro bloquea la ejecución al 100% → 402
- El tope blando genera una alerta y deja constancia fiel en el ledger
03 · Guardrails
- Los guardrails de entrada filtran los prompts antes del modelo
- Comprobaciones de PII / DLP y de inyección de prompts
- Reglas en lenguaje natural compiladas a controles aplicados
04 · Registro
- El modelo y la herramienta deben estar en la lista de permitidos del agente
- Modelo no permitido → ejecución denegada
- Versiones fijadas, desviaciones a la vista
05 · Control Tower
- Vista en vivo de la flota con un único interruptor de parada
- Límites de concurrencia y de tasa aplicados
- Pausa una flota sin desplegar nada
06 · Ejecución
- La llamada al modelo solo se ejecuta tras superar las compuertas 01–05
- Las llamadas a herramientas se enrutan por el MCP gateway
- Coste y latencia medidos en cada llamada
07 · Control de salida
- La salida generada se vuelve a revisar antes de salir
- Se comprueba el anclaje a fuentes y la cobertura de citas
- La salida insegura o sin fundamento queda retenida
08 · Auditoría
- Cada ejecución se encadena por hash en el Trust Ledger
- Comprobante firmado, verificable sin conexión
- verifyChain detecta cualquier modificación posterior
Cierre ante fallo, con códigos que puedes auditar
tope duro de gasto402 BUDGET_EXCEEDEDidentidad expirada403 EXPIREDpack alterado409 hashOk:false
Arquitectura del sistema
Un runtime, ~22 servicios, un solo esquema.
Cortex es una consola Next.js sobre un runtime de ~22 microservicios NestJS — agentes, acciones, ontología, política, ledger, observabilidad y más — respaldado por un único esquema cortex de Postgres. Cada lectura y cada escritura se acotan al tenant de quien llama, de modo que el aislamiento se aplica en la capa de datos, no como un añadido.
- Consola Next.js: una interfaz simple/avanzada sobre las mismas API gobernadas
- ~22 microservicios NestJS detrás de las ocho compuertas del runtime
- Un único esquema cortex de Postgres con aislamiento multi-tenant a nivel de fila
- LLM y sistemas conectados intercambiables: sin dependencia de un proveedor ni de un fabricante
Multi-tenant por diseño
La separación por tenant se aplica en la ruta de datos, no en la interfaz.
Las mismas compuertas y el mismo ledger se aplican a cada tenant, pero ningún tenant puede leer, escribir ni importar en otro. El aislamiento se comprueba en cada consulta y en cada importación de un pack.
Datos acotados
- Cada consulta queda ligada al tenant de quien llama
- Los objetos y las propiedades de la ontología pertenecen al tenant
- Nunca hay lecturas entre tenants
Runtime acotado
- Las identidades de agente viven dentro de un tenant
- Presupuestos, políticas y supervisión son por tenant
- El interruptor de parada de Control Tower distingue el tenant
Ledger acotado
- Cada tenant tiene su propia cadena de hashes
- Comprobantes verificables sin conexión por tenant
- La importación de un pack solo aterriza en el tenant de quien llama
Despliega donde quieras
Nube, VPC o totalmente air-gapped: tus datos permanecen donde tú los pones.
El mismo runtime se ejecuta en nuestra nube, dentro de tu VPC o en un entorno desconectado. Trae tus propios modelos locales, fija la residencia y mantén debajo de todo ello el ledger que hace evidente cualquier manipulación.
Cortex Cloud
Gestionado, multirregión
Región fijadaInternet
Trae tus propios modelos locales (vLLM · Ollama · TGI)
Tu VPC
Single-tenant en tu cuenta
Tu regiónEnlace privado
Trae tus propios modelos locales (vLLM · Ollama · TGI)
Air-gapped
Desconectado / on-premise
Solo on-premiseSin salida a la red
Trae tus propios modelos locales (vLLM · Ollama · TGI)
El mismo runtime por debajoocho compuertas · esquema cortex · Trust Ledger que hace evidente cualquier manipulación · fijación de residencia
~22Microservicios NestJS en un solo runtime
8Controles de gobernanza en cada ejecución
10-hopProcedencia desde la persona hasta la aprobación
1Esquema Postgres, aislado por tenant
Para desarrolladores
Gobernado por defecto: a través de la API, de la CLI o de un pack firmado.
No cambias control por productividad. Las mismas compuertas que protegen la consola protegen cada llamada programática, así que un agente que publicas por API está tan gobernado como uno que construyes a mano. Define la ontología, la política, las acciones y los agentes como código, y expórtalos como un Solution Pack firmado y verificable.
- Las mismas ocho compuertas tanto si la ejecución arranca en la interfaz, en un flujo de trabajo o en una llamada a la API
- Policy-as-Code, ontología y acciones versionadas junto a tus agentes
- Solution Packs firmados: verifyPack comprueba hashOk + signatureOk antes de importar
- Reproduce cualquier ejecución desde el ledger para revivir exactamente lo que pasó
Mira la ejecución completa, de principio a fin.
De la persona que la desencadenó a la política que la permitió y al recibo que la demuestra: Cortex hace que cada ejecución de agente rinda cuentas.