Last verified: 28 September 2026

Agent estate disclosure

Sovern's agent-as-estate-asset model — auto-projected from canonical §NN registries. Every agent template is org-authored; every agent instance is org-owned; every agent memory store is estate-local. No participant-keyed agents, no substrate-side agents, no shared mutable memory.

Generated from lib/registry/agent-strata-registry.ts, lib/registry/agent-template-visibility-registry.ts, lib/registry/agent-template-manifest-version-registry.ts, lib/registry/agent-memory-store-backend-registry.ts, lib/registry/agent-memory-encryption-scope-registry.ts

The NN-1 estate-asset invariant

Every public.agents row carries a non-nullable owner_org_id. There are no “floating” agents, no substrate-owned agents, no system-tier agents. Transfer of an agent between orgs is an attestation-backed ceremony (deferred to §ZAY J6.NN.7). Memory written under one owner cannot leak to a new owner without an explicit signed memory-transfer record (NN.sub4).

Agent strata (5)

The closed 5-stratum agent taxonomy per NN.sub1 + PP.sub1. Kernel + core agents ship with every deployment; addon variants install via marketplace entitlement; expression-specific agents require an attached expression manifest.

Stratum 1 — Kernel

key: kernel
Substrate-universal agents present in every deployment (e.g., system-prompt scaffolding, model-routing agents). Owned by the substrate operator.
ships with every deployment: yes
requires expression attachment: no

Stratum 2 — Core

key: core
Substrate-shipped baseline agents bundled with all OS baselines (e.g., a default writing-assistant). Owned by the substrate operator; instantiated automatically into every org.
ships with every deployment: yes
requires expression attachment: no

Stratum 3 — Add-on (general)

key: addon-general
Optional add-on agent templates available across baselines (e.g., a generic legal-review agent). Installed per-org via marketplace entitlement; not tied to a specific expression.
ships with every deployment: no
requires expression attachment: no

Stratum 4 — Add-on (bound)

key: addon-bound
Optional add-on agent templates bound to a specific add-on module (e.g., an HR-payroll agent that requires the HR add-on). Marketplace install requires both the add-on entitlement and the agent-template entitlement.
ships with every deployment: no
requires expression attachment: no

Stratum 5 — Expression-specific

key: expression-specific
Agent templates published against a specific expression manifest (e.g., a 'Sovern Business OS' sales co-pilot). Installation requires the org to be running that expression.
ships with every deployment: no
requires expression attachment: yes

Agent template visibility (4)

The closed 4-way template visibility taxonomy per NN.sub5. Maps to §AA products.access_scope per C-NN-10; cross-checked by guard:agent-template-in-product-registry at CI.

sovern-catalog — Sovern Catalog

First-party expert agent templates authored by Sovern Digital or an approved operator (e.g., legal-reviewer, compliance-auditor). Visible to all orgs across the deployment.
listed in marketplace: yes
§AA access-scope mapping: public

internal-market — Internal Market

Templates sold org-to-org within the deployment (e.g., a consulting firm sells its proven audit-sampling template to peer firms). Visible to orgs participating in the internal market.
listed in marketplace: yes
§AA access-scope mapping: federated

external-store — External Store

Commercial templates sold to external customers (e.g., an expression steward sells consumer-facing templates to end-orgs). Visible across federation boundaries.
listed in marketplace: yes
§AA access-scope mapping: federated

private — Private

Template visible only to the author org. Not listed in any marketplace surface. Used for internal-only templates or templates in pre-publish development.
listed in marketplace: no
§AA access-scope mapping: private

Agent template manifest

Manifest schema version: v1. The envelope shape (schema_version, key, name, description, stratum, author.org_id, author.display_name) is enforced by the NN-iii Zod schema; canonical bytes via deterministic JSON sort (JCS-lite per C-NN-12); SHA-256 hash stored at registerTemplate time. Substrate never trusts a hash that doesn't match the canonicalized manifest.

Agent memory store backends (4)

The closed 4-backend agent memory store taxonomy per NN.sub4.a. Default at v1: postgres-jsonb. Vector-index backends require the pgvector extension (enabled via migrations/V200__enable_pgvector.sql).

postgres-jsonb — PostgreSQL JSONB

Heap table storage in `public.agent_memory_records` with `content jsonb`. Default at v1; minimal infrastructure footprint.
requires pgvector: no
external dependency: none

vector-index — Vector index

Heap table with `embedding vector(1536)` column populated for semantic retrieval (requires pgvector extension; HNSW or IVF index applied post-v1).
requires pgvector: yes
external dependency: none

external-kv — External key-value

Memory records stored in an external KV store (e.g., Redis, Cloudflare KV) referenced by the row. Per-record TTL supported.
requires pgvector: no
external dependency: external-kv-adapter

hybrid — Hybrid

Mixed-backend layout: structured records in PostgreSQL JSONB + vector embeddings in pgvector + ephemeral state in external KV. Reserved for high-volume tenants; deferred to §ZBA.
requires pgvector: yes
external dependency: external-kv-adapter

Agent memory encryption scopes (3)

The closed 3-scope memory encryption taxonomy per NN.sub4.a. Default at v1: org-key. Estate-local memory isolated per NN-1 (owner-only decryption) and NN.sub4 inheritance rules.

org-key — Org key

Memory records encrypted with the owning org's KMS key. Default at v1; ensures memory is decryptable only with org-scoped credentials.
key controlled by: org-owner

env-key — Environment key

Memory records encrypted with the environment's master key (substrate-operator-controlled). Used for substrate-managed kernel agents whose owner is the substrate-operator org itself.
key controlled by: substrate-operator

external-managed — External-managed

Memory records encrypted with an external KMS managed by the owning org (e.g., AWS KMS, HashiCorp Vault). Used for compliance-regulated tenants requiring HSM-backed keys.
key controlled by: org-owner

This page is generated by a server component and is auto-validated against the five §NN registries by guard:trust-agents-page-matches-registry (BLOCKING). A future amendment can never silently drift from the substrate surface.