Skip to main content
Protocol WealthProtocol Wealth

Engineering substrate transparency aggregate substrate material not investment advice not advisory performance

Build in public

RIA agents — substrate for training, not launching

The substrate that lets any RIA train, operate, audit, and govern their own AI agents — on their own infrastructure, against their own client data, under their own CCO. Open-source primitives, three-tier memory, and structural answers to every agent threat model.

Last updated 2026-05-19.

Live functional view

Three-tier agent memory architecture

Each tier has a distinct data-model home, a distinct access-control posture, and a distinct retention regime. An AI agent operating against the substrate composes the three tiers in fixed order at every session turn; every read writes an audit-trail-eligible record.

Per-firm

All advisors and all clients. Firm-wide compliance posture, current architecture decisions, approved patterns, and vendor relationships.

Data home
Derived from version-controlled firm configuration; no database table
RBAC
Read-only by construction
Retention
Git history (unbounded); commit log is the audit trail

Per-advisor

One advisor across their book of business. Methodology preferences, common workflows, expertise areas, prior session decisions.

Data home
New advisor_memory table; advisor_id + memory_key + JSONB value
RBAC
Postgres RLS on advisor_id
Retention
7 years post-departure per 17 CFR §240.17a-4

Per-client

One client across all advisor sessions. Goals, decision history, document signatures, communication style.

Data home
Existing client_profile + audit_log principal-chain queries (no new schema)
RBAC
Postgres RLS on client_id + principal-chain authorization
Retention
7 years post-relationship per 17 CFR §240.17a-4

How the tiers compose

Every agent context assembly is the same shape: firm (broadest, read-only) → advisor (advisor scope) → client (most-scoped, principal-chain-authorized). Four audit rows per composition: a chain-establishment anchor plus three tier-read rows referencing the anchor.

  1. agent.context.chain_established

    Principal chain validated (advisor → session → client); audit-log anchor row written; chain returned to composer.

  2. agent.context.firm_memory_read

    Per-firm derived view read (no auth gate; public-by-construction firm-wide substrate); tier-read audit row references the anchor.

  3. agent.context.advisor_memory_read

    Per-advisor memory read via advisor_id RLS; entry count + anchor reference recorded.

  4. agent.context.client_memory_read

    Per-client memory read via RLS + principal-chain authorization; decision count + anchor reference recorded.

Substrate primitives composed

  • @protocolwealthos/audit-log — principal-chain queries + content-free audit rows + hash-chained immutability
  • @protocolwealthos/pii-guard — 4-layer PII scanner at the memory-read boundary; structural exclusion of pii.high from LLM-bound payloads
  • @protocolwealthos/ai-guardrails — workspace ZDR assertion + model-alias enforcement + buildAuditRow() content-free record builder

All Apache 2.0 under pwos-core; the architecture is the composition layer over these primitives. Adopters fork the primitives + implement the memory-store interfaces from the reference example against their own Postgres / DynamoDB / equivalent.

Canonical references

  • Open-source pattern
    Three-tier agent memory architecture

    Documented in the pwos-core open-source pattern library, alongside our PII tagging, audit-reconciliation, and data-egress safeguards.

  • Reference implementation
    pwos-core/examples/rias-agent-substrate/

    Storage-agnostic TypeScript reference implementation with a full test suite. In-memory store implementations are included; Postgres-backed stores swap in against the same contracts.

  • Architecture companion doc
    Three-tier architecture explainer

    Mermaid diagrams + tier-by-tier substrate enforcement + a guide to wiring the architecture onto a Postgres + RLS stack.

  • Architecture decision records
    Architecture decision records — design rationale and alternatives considered

    We expect to publish high-level ADR summaries over time; fuller records are available to qualified reviewers via the verification pathway on /security.

Open source

How the open source fits together

The hard part of putting an AI agent to work in an advisory firm isn't the agent — it's the substrate around it that is built to keep client data protected, every action recorded, and a human in control. We publish that substrate as three Apache-2.0 repositories. Protocol Wealth is an investment adviser, not a software vendor — these are open for any firm to read, run, fork, and verify, not a product we sell or license.

pwos-core

the governance & safety substrate

The operations manual for an AI agent: a PII guard that de-identifies client data before it reaches the model and restores it after; an append-only audit log designed to support books-and-records retention (SEC Rule 204-2); scoped access tokens that can be revoked; and a three-tier memory model.

TypeScript · Apache 2.0 · defensive provisional patent

View on GitHub

nexus-core

the capability & tool layer

The agent's toolbox: standardized Model Context Protocol tools for market and economic data, regime classification, and durability scoring, served read-only at nexusmcp.site. It takes market data and de-identified inputs only — payloads carrying a name, date of birth, or SSN are rejected.

Python · Apache 2.0 · defensive provisional patent

View on GitHub

pwplan-core

the privacy-by-construction planning engine

A planning layer whose data contract is PII-free by construction — age, not date of birth; opaque references, not names. Cash flow, decumulation, tax, and Roth analysis run against that contract, and a contract test fails if an identifying field is ever added.

TypeScript · Apache 2.0 · defensive provisional patent

View on GitHub

All three are open-source reference frameworks under active development — built for our own practice and published so any firm can read them, run them, and check our work. See the patent disclosure and how we work. Protocol Wealth LLC is an Open Invention Network 2.0 Licensee, and these repositories are covered under that license.

Where does your firm stand?

A seven-question self-assessment, scored in your browser, mapping your AI setup to the substrate dimensions above — each gap links the open-source primitive that closes it.

Take the AI Readiness assessment

RIA agents — substrate for training, not launching

Most software vendors serving RIAs are launching AI agents. Holistiplan, eMoney, Wealthbox, and others are adding "AI assistant" features. Protocol Wealth is building one layer underneath: the substrate that lets any RIA train, operate, audit, and govern their own AI agents — on their own infrastructure, against their own client data, under their own CCO. The agent UX is commodity within 18 months. The substrate that makes agents safe to deploy in a fiduciary context is the durable thesis. That substrate is what we built; it's what we open-sourced as pwos-core; it's what you can fork and run today.

The gap

Vendors give you agents. They don't give you:

  • The training-data preparation substrate (PII-safe; structurally enforced)
  • The audit substrate (every agent action recorded immutably for seven years)
  • The principal chain (which advisor authorized which agent session that invoked which tool)
  • The privacy substrate (inference-time data never trains a model; canary fail-closed)
  • The governance review queue (human-in-the-loop before client-facing output)
  • The memory layer (per-client; per-advisor; per-firm)

Without these, an AI agent in an RIA context is policy on top of a vendor's claims. With them, an agent is auditable substrate. The first major AI scandal in our industry will not come from agents that fail; it will come from agents that succeed at something they should not have done, and the firm cannot prove afterwards what happened.

The reference stack

Opinionated. Categorical. Concrete. Forkable.

Agent capability Substrate primitive Why this shape Source
Training data preparation pwos-core/pii-guard 4-layer PII defense; structural exclusion of high-PII fields from any training corpus Apache 2.0
Agent action audit pwos-core/audit-log Hash-chained immutable rows; 7-year retention horizon Apache 2.0
Authorization trace Principal chain (in audit-log) Captures advisor → session → tool; answers "who is accountable" without ambiguity Apache 2.0
Inference-time privacy Anthropic ZDR workspace + egress canary No retention; no training; byte-identical canaries across three independent surfaces Apache 2.0 (canary patterns)
Human-in-the-loop pwos-core/workflow-engine review queue Tier 2 HITL; CCO sign-off gate before client-facing output Apache 2.0
Tool authorization pwos-core/mcp-tools confirmGate 4-tier write-tool authorization; two-turn gate for client-affecting actions Apache 2.0
Compliance retention GCS bucket-level retention lock 7-year retention; empirically validated against operator override attempts Cloud-vendor primitive
Model alias enforcement ESLint rule + alias map Prevents hardcoded model strings; survives vendor model deprecations Apache 2.0

If you were building an AI agent for an RIA today, here is the stack:

  • Cloud: GCP (single-cloud sovereignty posture)
  • LLM provider: Anthropic, with ZDR contractually enforced at the workspace level; US-only inference
  • Database: Postgres with hash-chained audit substrate
  • Audit mirror: GCS with bucket-level retention lock
  • Edge: Cloudflare for marketing surfaces; direct-to-GCP for authenticated surfaces
  • Substrate primitives: pwos-core (Apache 2.0)
  • MCP foundation: nexus-core (Apache 2.0; deployed at nexusmcp.site)

The three-tier memory model

An AI agent in an RIA context has three legitimate memory scopes. Each requires different substrate enforcement.

Memory tier Scope What it remembers Substrate enforcement
Per-client One client across all advisor sessions touching that relationship Goals, history, preferences, prior decisions, document signatures, communication style Row-level security on shared schema + principal-chain queries against audit-log
Per-advisor One advisor across their book of business Methodology preferences, common workflows, expertise areas, prior interactions Session-scoped + advisor-scoped derived from audit-log views
Per-firm All advisors and clients; firm-wide state Compliance state, vendor relationships, policies, ADRs, CCO-approved patterns Derived from firm-wide compliance state, policy records, and the architecture-decision index

Aspirational: each client portal of the future surfaces this organized around the client's own goals, not around our internal data model. The substrate is what makes that aspiration tractable rather than a marketing claim.

What makes substrate-based training safe

Every agent threat model has a structural answer:

Threat Structural answer
Agent sees PII it shouldn't PII canary fail-closed; 4-layer defense across three byte-identical re-implementations; layers cannot share a single bug
Agent recommends a product it has been engineered to sell Governance review queue routes every client-facing output through CCO sign-off; Marketing Rule §206(4)-1 review applies pre-delivery
Agent retains client conversation outside ZDR window Workspace-level ZDR contractually enforced; no inference data crosses retention boundary
Agent action goes unrecorded audit-log write is structurally enforced at the application layer; no agent path bypasses
Agent operates without human signoff Tier 2 HITL substrate; principal chain captures who authorized the AI session
Agent's model gets deprecated mid-deployment ESLint-blocked hardcoded model strings; a model alias map survives vendor changes
Agent's audit records get tampered with GCS retention lock; bucket-level immutability empirically validated against operator-level access

These are not features. They are substrate. The difference matters: features can be turned off, deprecated, or de-prioritized when vendor economics shift. Substrate enforces commitments structurally and survives every kind of operator failure.

How to verify

The substrate is publicly inspectable:

We expect to publish high-level ADR summaries and posture attestations over time; fuller records — ADRs, specific audit_log row samples, the vendor due-diligence bundle, and signed posture attestations — are available to qualified reviewers via the verification pathway on the /security page.

Three concrete actions any RIA can take today

  1. Fork pwos-core. Apache 2.0; no NDA, no contact form. Run the audit substrate against their own GCP project. Audit the patterns.
  2. Use the advisor's AI vendor audit checklist at /factsheets/advisor-ai-vendor-audit-checklist. Twenty structural questions any RIA can run against any AI-enabled vendor.
  3. Subscribe to /changelog. If we ship something compliance-interesting, they see it. If we ship something rough, they see that too. Build-in-public both ways.

A note on scope

This page describes the substrate Protocol Wealth built and operates for AI agents in an RIA context. It does not describe specific agent products, performance, or advisory services. Anyone evaluating Protocol Wealth as an investment adviser should read our Form ADV Part 2A at adviserinfo.sec.gov/firm/brochure/335298.

The Marketing Rule §206(4)-1 framework treats engineering substrate transparency as separable from advertising of advisory services. We hold to that separation deliberately.

Related reading

Engineering substrate transparency aggregate substrate material not investment advice not advisory performance

What this page is. A plain-English description of the engineering substrate Protocol Wealth built for training and operating AI agents in an RIA context. Aggregate substrate material; not investment advice; not advisory performance; not a description of any individual client engagement.

What this page is not. Not an offer to provide advisory services. Not a personalized recommendation. Not a description of investment process, methodology, or portfolio construction. Engagement with Protocol Wealth as an advisory client is governed by a signed advisory agreement; nothing on this page creates one.

Protocol Wealth, LLC is an SEC-registered investment adviser (CRD #335298). Registration with the SEC does not imply a certain level of skill or training. Full regulatory disclosures are linked from the site footer.