PDX-CRDB Agent Memory

Approval-gated agent memory on CockroachDB: chatter stays ephemeral and only PDX-verified + human-approved lessons become VECTOR-recallable runbook memory via Bedrock + Managed MCP.

Comment

Inspiration

Agent memory is powerful - and dangerous. In incident response, operators paste unverified chatter into the chat (“flush the cache now”), and naive systems will promote that noise into long-term memory. Once poisoned, every future session recalls the wrong runbook.

We wanted a different contract: CockroachDB as the durable memory layer, with a hard gate between “what the agent heard” and “what the organization will trust forever.” That led to PDX-CRDB Agent Memory - dual-layer memory where transcripts stay append-only, and only PDX-verified + human-approved lessons become recallable canon.

What it does

PDX-CRDB Agent Memory is an approval-gated agent memory stack for incident-response workflows:

  1. Interaction layer: noisy chat turns append freely (they never auto-become long-term memory).
  2. Proposal layer: Amazon Bedrock (Nova) proposes a durable runbook lesson as pdx_memory_proposal_v1, after reading approved memory via CockroachDB Managed MCP (select_query on memory_item).
  3. Verification + Approve: the host runs PDX Artifact Engine verification (allow_mock=False), then a human Approve promotes proposed → written in a single CockroachDB transaction.
  4. Semantic recall: Amazon Titan Text Embeddings V2 (VECTOR(1024)) embeds the query; CockroachDB Distributed Vector Indexing ranks with embedding <=> query_vec. Poison phrases do not appear.

It ships as:

  • an embeddable Python library (AgentMemory) for third-party hosts, and
  • a live Lambda container demo (public Function URL) for judges.

How we built it

  • CockroachDB Cloud as the persistent memory layer: sessions, candidates, write requests, approval events, and memory_item + distributed vector index.
  • Managed MCP (required tool #1): host-enforced read allowlist for the Bedrock agent - select_query succeeds on memory_item; no agent INSERT/DDL.
  • Distributed Vector Indexing (required tool #2): Titan v2 1024-d embeddings stored in CRDB; next-session recall via SQL vector distance (not a side vector DB).
  • Amazon Bedrock: Nova Converse for the IR loop; Titan v2 for embeddings.
  • AWS Lambda (container image, Function URL in us-east-1) as the public demo host (Engine + app in-image).
  • PDX Artifact Engine (peer, not a fork): plan → verify → run/artifact manifests bound to the lesson payload digest.
  • Evidence-first path: local submission_demo.py + sanitized docs/evidence/; public URL Approve verified live (ir=live, MCP success, PDX written, VECTOR recall).

Challenges we ran into

  • Managed MCP ~16KB query limit: full 1024-d VECTOR literals cannot ride inside MCP select_query text. We split paths: short MCP reads for the agent; parameterized SQL for Titan vectors.
  • Honest evidence vs lucky PASS: early runs could “pass” even when MCP queried a non-existent table. We fail-closed: no successful allowlisted select_query ⇒ no submission PASS; request-scoped 0→1 memory_item checks replace fragile global counts.
  • Live Bedrock propose quality: ir=live once proposed poison after a bad table name; we require MCP success + a safe quorum lesson before Approve, and reject unsafe proposals.
  • Lambda packaging for real PDX: zip was too thin; we moved to a container image, fixed OCI attestation rejection, and run as Image package type.
  • Demo slides vs Rules: UI screenshots alone under-sold “CRDB memory layer at work”; we added explicit framework/flow/CRDB slides naming MCP + VECTOR + the promotion transaction.

Accomplishments that we're proud of

  • A clear dual-layer story judges can follow in under three minutes: poison chatter → MCP propose → PDX Approve → CRDB written → next-session VECTOR recall.
  • Live Function URL path with ir=live: Managed MCP select_query success, PDX verify, CRDB promotion, Titan 1024 recall - poison not recalled.
  • Local Full E2E publishable evidence bundle (docs/evidence/) with digest-verifiable manifests and no local secrets/paths.
  • An embeddable façade (AgentMemory) so this is a library other hosts can adopt, not only a one-off demo URL.
  • Rules-aligned tool story: ≥2 CockroachDB tools (MCP + Vector) and ≥1 AWS (Bedrock + Lambda), meaningfully integrated - not initialized-only.

What we learned

  • Agentic memory needs identity separation: agent/MCP reads ≠ ingest writer ≠ approval writer.
  • “The model called a tool” is not enough - demos need tool success gates and digest-bound promotion evidence.
  • Vector memory on CockroachDB works best when embeddings stay on the SQL path; MCP is excellent for short, allowlisted reads.
  • Treat demos as evidence products: say out loud that Titan embeds and CockroachDB stores and ranks.

What's next for PDX-CRDB Agent Memory

  • Stronger Cloud SQL GRANTs, retention/expiry, and production-shaped credential split.
  • Broader host adapters beyond the reference Lambda container while keeping the same approve-gated CRDB transaction core.
  • Optional richer IR UX on the public demo while keeping the same fail-closed memory contract.##

Built With

  • agentic-memory
  • amazon-bedrock
  • apache-2.0
  • aws-lambda
  • boto3
  • cockroachdb
  • docker
  • dual-layer-memory
  • ecr
  • function-url
  • human-in-the-loop
  • incident-response
  • managed-mcp
  • nova
  • open-source
  • pdx
  • psycopg2
  • python
  • rag
  • serverless
  • sql
  • titan-embeddings
  • vector
  • vector-search
Share this project:

Updates