Nombradas y registradas
Cada acción — refund.issue, payout.send, close.case — es una entrada del registro con una clave, un esquema de entrada (claves obligatorias), un riskLevel y un indicador requiresApproval.
Action Fabric
Deja que los agentes actúen de verdad — sin correr riesgos reales.
Cada acción que un agente puede ejecutar es un objeto gobernado de primer nivel: una acción con nombre, nivel de riesgo y política de aprobación, además de un registro de invocaciones inmutable que documenta dry-run → propose → approve/deny → execute → compensate con un paquete de evidencia en cada paso.
dry-run → propose → approve/deny → execute → compensate · denegación por defecto
Action Fabric
Simulación›
Reembolso de $240
riesgo: bajo · evidencia
Propuesta›
Cerrar el caso #4471
riesgo: medio · evidencia
Pendiente de aprobación›
Pago de $5.000
riesgo: alto · evidencia
Ejecutada
Enviar correo al cliente
riesgo: bajo · evidencia
actions ▸ simulación → propuesta → aprobación → ejecución → compensación
Acciones como objetos gobernados
Una llamada a una herramienta es un deseo. Una acción gobernada rinde cuentas.
Los agentes sin gobernanza llaman a las herramientas directamente — sin nivel de riesgo, sin aprobación y sin constancia de qué se ejecutó ni de cómo deshacerlo. En Cortex, cada acción se registra con un nivel de riesgo y una política de aprobación, y cada invocación queda en un registro de solo anexado. Las acciones de alto riesgo y las que requieren aprobación nunca se ejecutan hasta que un administrador las aprueba; las acciones denegadas no se ejecutan nunca.
Por nivel de riesgo
riskLevel: high o requiresApproval envía la invocación a pending_approval; las acciones de bajo riesgo se ejecutan de inmediato. El riesgo es una propiedad de la acción, no una esperanza.
Registro inmutable
Cada dry-run, propuesta, aprobación, denegación, ejecución y compensación se añade a cortex_action_invocations — un rastro de evidencia que puedes entregar a un auditor.
Reversibles
Declara un rollbackKey y cualquier acción ejecutada podrá compensarse — el runtime ejecuta la acción compensatoria y marca la original como compensated.
El problema que resuelve
En cuanto un agente puede escribir, tu exposición cambia.
Los agentes de solo lectura son fáciles. El riesgo llega cuando un agente emite un reembolso, cierra un caso o envía un pago. Sin una capa entre la intención y el efecto, estás confiando efectos secundarios a un modelo — sin compuerta de aprobación para el pago de $5,000, sin constancia de qué se ejecutó y sin forma de revertirlo. Action Fabric coloca una capa de gobernanza que deniega por defecto entre la propuesta y el efecto secundario.
Las acciones de alto riesgo quedan en pending_approval — nunca se autoejecutandeny → se registra como denied, el ejecutor nunca se invocacompensate → el rollbackKey declarado revierte una acción ejecutada
El ciclo de vida
De la propuesta al efecto demostrable — y de vuelta.
Cada invocación recorre el mismo ciclo de vida de cinco estados. Cada transición se anexa al registro con su paquete de evidencia, de modo que la historia completa de cualquier efecto secundario puede reconstruirse a posteriori.
- 01
Dry-run
Valida la entrada contra el esquema de claves obligatorias de la acción. No se ejecuta ningún efecto secundario — es un ensayo seguro que demuestra que la llamada está bien formada antes de que ocurra nada.
- 02
Proponer
Envía la acción de verdad. Las acciones con riskLevel: high o requiresApproval quedan en pending_approval; el resto se ejecuta de inmediato bajo política.
- 03
Aprobar / Denegar
Solo para administradores, protegido por AdminGuard. Aprobar invoca al ejecutor gobernado; denegar registra denied con un motivo y el ejecutor nunca se invoca.
- 04
Ejecutar
El ejecutor gobernado emite ActionExecuted o ActionFailed (eventos P4). La regla de adaptadores P7 mantiene los mocks fuera de producción salvo que se permitan explícitamente.
- 05
Compensar
Solo para administradores. Si la acción declara un rollbackKey, el runtime ejecuta la acción compensatoria y marca la original como compensated — un deshacer limpio y auditado.
Procedencia
Cada acción se remonta a quién la pidió.
Qué incluye Action Fabric
Catálogo, registro, ejecutor y las compuertas entre ellos.
Registro de acciones
- Claves de acción con nombre
- Esquema de entrada (claves obligatorias)
- riskLevel: low / med / high
- Indicador requiresApproval
- rollbackKey opcional
Bitácora de invocaciones
- Invocaciones solo de anexado
- Paquete de evidencia por paso
- Estados dry-run → … → compensate
- Lecturas acotadas al tenant
- Rastro listo para entregar a un auditor
Bandeja de aprobaciones
- Cola pending_approval
- approve / deny solo para administradores
- Se registra el motivo del rechazo
- AdminGuard aplicado
- El tenant se toma del principal
Ejecutor gobernado
- Determinista por defecto
- ActionExecuted / ActionFailed (P4)
- Regla de adaptadores P7
- Driver en vivo tras ACTION_EXECUTOR_MODE
- Ningún sistema real sin habilitarlo
Acotado a la ontología
- objectId opcional en propose
- Resuelve el tipo del objeto
- Aplicación de las acciones permitidas
- 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- Objeto y tipo quedan en la evidencia
Compensación
- Declaración de rollbackKey
- Se ejecuta la acción compensatoria
- La original queda marcada como compensated
- Deshacer auditado y restringido a administradores
- Efectos secundarios reversibles
Demuéstralo — no te limites a afirmarlo
Denegar es lo predeterminado. El registro es el recibo.
Observa cómo la misma capa gestiona seis resultados honestos — una ejecución limpia, una retención por alto riesgo, una denegación de administrador que nunca llega a ejecutarse, una reversión compensada y una acción acotada por la ontología bloqueada de plano. Cada fila es una entrada de solo anexado en el registro, con su propio paquete de evidencia.
- Acción de alto riesgo → pending_approval hasta que un administrador la apruebe
- Acción rechazada → se registra como denied y el ejecutor nunca se llama
- Tipo de objeto incorrecto → 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- Acción ejecutada con rollbackKey → queda limpiamente compensated
Registro de invocaciones
dry-run
refund.issue · input { amount: 240 } · schema ok
validpropose
payout.send · riskLevel: high → pending_approval
pending_approvalapprove
payout.send · admin: risk-ops@northwind → executed
executeddeny
close.case · reason: requiere revisión del perito
denied · nunca se ejecutóexecute
email.customer · riskLevel: low → ActionExecuted (P4)
executedcompensate
refund.issue · rollbackKey → refund.void → compensated
compensatedpropose
delete.record · objectId: Claim/4471
403 ACTION_NOT_PERMITTED_FOR_OBJECTactions ▸ solo anexado · paquete de evidencia en cada paso · approve / deny / compensate restringidos a administradores
5Estados del ciclo de vida en cada invocación
100%De las invocaciones registradas en la bitácora
403ACTION_NOT_PERMITTED_FOR_OBJECT con el tipo incorrecto
0Acciones denegadas que llegan al ejecutor
Action Fabric
Simulación›
Reembolso de $240
riesgo: bajo · evidencia
Propuesta›
Cerrar el caso #4471
riesgo: medio · evidencia
Pendiente de aprobación›
Pago de $5.000
riesgo: alto · evidencia
Ejecutada
Enviar correo al cliente
riesgo: bajo · evidencia
actions ▸ simulación → propuesta → aprobación → ejecución → compensación
Acciones acotadas por la ontología
Una acción solo se permite sobre los objetos que tiene autorizados.
Pasa un objectId en propose y el runtime resuelve el tipo del objeto de la ontología y aplica actionPermittedForObject(allowedActions, key). Una lista de permitidos vacía en el tipo autoriza cualquier acción; si no está vacía, debe incluir la clave de la acción o la propuesta se bloquea. El objeto y su tipo se escriben en la evidencia de la invocación, y la comprobación falla abierta (dejando registro) si ontology-service no está disponible, para que la gobernanza nunca se convierta en una caída.
- allowedActions vacío en un tipo → se permite cualquier acción
- Si la lista no está vacía, debe incluir la clave de la acción; si no, se deniega
- Código de bloqueo: 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- Se registra en evidence.ontologyObject para el rastro de auditoría
Funciona con el resto del entorno de ejecución
Las acciones no se gobiernan solas — lo hace la plataforma.
Action Fabric vive dentro del mismo entorno de ejecución con denegación por defecto que la identidad, la política, la supervisión y el registro. Sigue los radios.
Policy-as-Code
Redacta reglas allow / deny / require_approval — p. ej. amountUsd ≥ 5000 → require_approval — y simúlalas antes de publicarlas.
Modos de supervisión
Los cinco modos de autonomía definen cuánto puede ejecutar un agente por su cuenta — la puerta de riesgo es un mínimo que la supervisión solo puede endurecer.
Trust Ledger
Cada acción ejecutada se encadena por hash en un registro de auditoría a prueba de manipulaciones, con recibos firmados y verificables sin conexión.
Ontología
Los permisos de objeto, propiedad y acción dan a las acciones un significado de negocio gobernado — y el alcance por objectId de arriba.
Agent IAM
Los agentes son identidades gobernadas con acciones en lista de permitidos — un agente solo puede proponer las acciones que su identidad autoriza.
Control Tower
Observa en vivo cada invocación de acción, pausa una flota de agentes y exporta un informe de gobernanza con un clic.
Seguridad y cumplimiento
Diseñado para la revisión de seguridad empresarial.
Aprobaciones restringidas a administradores, ejecución que deniega por defecto, evidencia de solo anexado y la regla de adaptadores P7 que mantiene los mocks fuera de producción — todo mapeado a los marcos que tus auditores ya utilizan.
SOC 2ISO 27001ISO 42001HIPAAGDPREU AI ActNIST AI RMFFINRA
Dale manos a tus agentes — y una correa.
Somete cada acción de agente a un ciclo de vida gobernado: simulación, aprobación, ejecución, reversión y evidencia completa en cada paso.