Módulo XVII — sandbox de simulación y pruebas de agentes
El módulo XVII es el sandbox de pruebas: ejecuta un escenario de agente en un entorno aislado y efímero, reproduce una sesión histórica de forma determinista y compara dos variantes antes de un despliegue. Es el hermano del módulo XII (evals) — el XVII ejecuta en aislamiento y produce salidas, el XII mide su calidad — y los dos están desacoplados: ninguno importa al otro. Esta página es la referencia de lo que hace el sandbox hoy y sus límites honestos.
El sandbox cataloga escenarios redactados por el operador: una secuencia de inputs de paso más las respuestas simuladas de las herramientas y recursos que una ejecución tiene permitido tocar. Un escenario es un fixture sintético — sin secretos, sin handles de producción — clampeado antes de persistirse. Sobre él se ejecutan tres flujos:
- Simulación de escenario — ejecuta los pasos de un escenario contra sus mocks, produciendo salidas por paso (opcionalmente puntuadas contra una suite de evals).
- Replay — reconstruye la línea temporal de inputs de una sesión histórica y la re-ejecuta de forma determinista contra mocks, de modo que el mismo input produce la misma salida.
- Comparación pre/post-deploy — ejecuta el mismo escenario contra una variante de línea base y una
candidata, puntúa ambas y registra un veredicto (
improved/regressed/unchanged/inconclusive) con el delta.
Entidades y la garantía de aislamiento
Sección titulada «Entidades y la garantía de aislamiento»El módulo es dueño de cuatro entidades: un scenario mutable, un run mutable (running →
terminal), un output por paso append-only y una comparison pre/post-deploy append-only.
Cada ejecución registra qué runner la ejecutó, si ese runner fue
isolated, si el estado efímero fue destroyed, los recuentos por paso y — si se cableó
un scorer — la suite, la puntuación y el veredicto de pase.
El aislamiento es una propiedad del cable, atestada por ejecución, no una afirmación. El runner
in-process por defecto es aislado por construcción: recibe solo la spec de paso-y-mock
y no tiene ningún handle al almacén, la red ni ningún secreto; un paso que pide un
recurso ausente de los mocks produce un marcador determinista de mock-miss y nunca
alcanza un recurso real; el estado vive en la llamada y se descarta al retornar, de modo que la ejecución
registra destroyed. Bajo aprovisionamiento del operador, un runtime a nivel de SO se sitúa tras la
misma interfaz — una instancia efímera, endurecida y con egress controlado cuyo backend
(gVisor o microVM Firecracker) se elige por política y se gatea por preflight. Cada ejecución
registra el backend real y su flag isolated, de modo que un backend degradado o portable es
visible y auditable, nunca oculto.
Qué consume y produce
Sección titulada «Qué consume y produce»El sandbox no emite en el bus de eventos; produce evidencia persistida que otros módulos leen sin acoplarse a él. Sus salidas las puntúa el módulo XII a través de un adaptador cableado solo en la raíz de composición — los dos hermanos comparten un contrato de puerto fino, no un import. Su comparación pre/post-deploy es la evidencia de decisión que lee el módulo de despliegue para gatear una promoción, y alimenta la línea base de regresión que rastrea el XII. Lanzar una ejecución, un replay o una comparación es una acción privilegiada, con ámbito de tenant y auditada (editor y superiores para ejecutar; la comparación de deploy es una decisión de admin).
Relacionado
Sección titulada «Relacionado»- Módulo XII — calidad, evals y pruebas — el hermano que puntúa las salidas.
- Catálogo de módulos — dónde encaja el XVII y la separación Govern/Actuate.
- Visión general de la arquitectura — la capa de Intelligence.
- Gobernar y aprobar — actuar sobre un veredicto pre/post-deploy.
- Honestidad y límites — los seams deny-closed a lo largo del producto.