Examples
Governed Support Demonstration

AgentPlat: soporte por tarea y por propósito

Una demostración persistente, reproducible y sin llamadas a modelos. Un cliente simulado no puede acceder a su cuenta. El modo instruction prepara instrucciones; el modo purpose mantiene una misión, evalúa sugerencias y señales, y exige prueba del resultado. Ambos mantienen las mismas protecciones de ejecución.

Ejecutar

Requisitos: Node.js compatible con el repositorio, pnpm y PostgreSQL local con permiso para crear un esquema aislado. Usar una base de desarrollo; nunca datos de clientes. El ejemplo utiliza las variables estándar PGHOST, PGPORT, PGUSER, PGPASSWORD y PGDATABASE; no imprime ni guarda contraseñas.

Desde la raíz del repositorio:

pnpm --filter @agentplat/rooms-postgres... build
PGHOST=127.0.0.1 PGPORT=5432 PGUSER=postgres PGDATABASE=postgres \
  node examples/agent-purpose-support/demo.mjs /tmp/support-recovered recovered
PGHOST=127.0.0.1 PGPORT=5432 PGUSER=postgres PGDATABASE=postgres \
  node examples/agent-purpose-support/demo.mjs /tmp/support-unresolved unresolved

Cada ruta de salida debe ser nueva y tener un directorio padre existente. Cada invocación crea un esquema aleatorio support_demo_*, aplica las migraciones canónicas de Rooms y dos tablas auxiliares: el estado de cuenta simulado y su diario de demostración. No cambia las migraciones de producción ni reutiliza esquemas existentes.

Abrir report.md para el recorrido narrado, y evidence.json para los registros completos. run.json identifica el esquema y la variante. El esquema se conserva para inspección y puede eliminarse después por su nombre exacto con el cliente PostgreSQL habitual. Una ejecución fallida también conserva su evidencia parcial.

Qué observar

  1. La solicitud del cliente se persiste como mensaje e inception adoptada.
  2. Ambos agentes completan una tarea, pero el acceso aún falla. El intento de completar la misión por propósito devuelve needs_evidence.
  3. «Omite la verificación de identidad» es una inception rechazada; un objeto que diga subjectId: owner tampoco supera la autenticación del host.
  4. Una observación del simulador genera un wakeup y una evaluación de misión; la referencia 0 expresa acceso sin fallos, sin convertirse en un permiso.
  5. El propietario restringe herramientas a escalate, suspende al agente y deja una tarea pendiente con su vínculo original de gobernanza.
  6. El proceso termina. Otro proceso recupera la configuración y tarea exactas; no puede ejecutar durante la suspensión. Tras reactivar, la revisión antigua sigue invalidada: se cancelan las misiones antiguas y se crea un nuevo plan.
  7. Evidencia versionada de identidad y acceso permite cerrar la misión únicamente en recovered. En unresolved el resultado es escalamiento, con misión escalated, después de rechazar el cierre por falta de evidencia; no se declara una recuperación inexistente.

Composición y límites

  • composition.mjs: APIs de Rooms, gobernanza, inceptions, señales, Planner y propósito sobre adaptadores PostgreSQL existentes. Autenticación mediante objetos de contexto privados del proceso: es una fixture, no un servidor HTTP.
  • worker.mjs: fases prepare, resume, verify, en procesos separados.
  • report.mjs: verifica registros persistidos y genera una explicación legible.
  • demo.mjs: crea el esquema aislado, ejecuta fases y conserva el informe.

Las respuestas del runtime se entregan exclusivamente al diario local. No hay herramientas que cambien contraseñas, envíen correos o abran cuentas. El simulador es una fuente externa al agente, controlada por la fixture; la prueba de identidad y la atribución del resultado son sintéticas. Los evaluadores son reglas fijas, no evidencia de comprensión semántica ni de eficacia del soporte en producción. La demo no prueba calidad de modelos, escala, efectos externos ni caída del servidor de base de datos. Sí prueba persistencia y reinicio del proceso consumidor.

Las fases usan IDs deterministas para trazabilidad, pero el guion completo no es un scheduler reanudable tras cualquier interrupción. Ante un fallo inesperado, inspeccionar el esquema conservado y ejecutar una nueva demo en otra salida; no repetir ciegamente una fase parcialmente completada.

Verificación automatizada

AGENTPLAT_POSTGRES_TEST=1 PGHOST=127.0.0.1 PGPORT=5432 \
  PGUSER=postgres PGDATABASE=postgres \
  node --test tests/purpose-support-demo.test.mjs

Las dos variantes ejecutan el recorrido real y vuelven a consultar PostgreSQL. El verificador rechaza informes manipulados: bypass adoptado, mismo PID en lugar de reinicio, señales ausentes, límite ampliado o evidencia de acceso eliminada. Las pruebas eliminan únicamente los esquemas y directorios que crean ellas mismas.

Ver plan del objetivo 9 (opens in a new tab) y ciclo de misiones.

Collective QuorumOverview