wallet-memory

An AI shopping agent with its own wallet that asks a human before buying — and remembers every decision in CockroachDB, a database that never loses data even if a region goes down.

Comment

Inspiration

Most "AI agent" demos stop at giving a model tools. We wanted to go one step further: give an agent a wallet, let it spend real (test) money on a limited-stock drop, and see what breaks. The answer was memory. An agent that can spend money but forgets its own past decisions will happily repeat mistakes it already made — buy the same thing twice, ignore a lesson it learned yesterday, or have no record of why it once said no. This project builds on two of our earlier prototypes — a zero-oversell drop mechanic and an approval-gated purchase agent — and asks: what if the agent's memory itself lived in the same database that guarantees its transactions are correct?

What it does

wallet-memory watches a limited-stock "drop." When it decides there's room to buy, it first asks CockroachDB: "have I seen a situation like this before, and what did I do?" using Distributed Vector Indexing over embedded justification text. It then asks a human to approve or reject the purchase through a small web dashboard. Whatever happens next — confirmed, sold out, rejected, or timed out — gets written straight back into CockroachDB as a permanent memory, ready to be recalled the next time the agent has to decide.

How we built it

CockroachDB tools used:

  • Distributed Vector Indexing — decisions.embedding VECTOR(1024) with a VECTOR INDEX (product_id, embedding). Justifications are embedded with Bedrock Titan Text Embeddings V2, and recall_similar_decisions queries by <-> distance before every approval request.
  • CockroachDB Cloud Managed MCP Server — configured project-scoped (.mcp.json), used as a read-only audit surface: we connected Claude Code directly to the live cluster and asked it, in plain English, to explain recent purchase decisions. It queried decisions/products itself via list_databases / list_tables / select_query — no custom backend.
  • ccloud CLI (bonus) — used to grow the cluster from one region to three (Singapore, Jakarta, Mumbai) and to inspect available regions before configuring SURVIVE REGION FAILURE.

The products / inventory / orders tables also lean hard on CockroachDB's serializable transactions for the classic zero-oversell pattern (conditional UPDATE ... WHERE stock > 0, retried on 40001).

AWS services used:

  • Amazon Bedrock — Claude Sonnet 4.6 for the agent's reasoning (via the Strands Agents framework), Titan Text Embeddings V2 for the memory embeddings.
  • Amazon Bedrock AgentCore Runtime — the agent runs as a deployed container here, not on a laptop.
  • Amazon DynamoDB — holds only the short-lived PENDING approval state (with TTL); the durable memory lives in CockroachDB.

The frontend is Next.js on Vercel; the agent is Python (Strands Agents) built into a container for AgentCore Runtime.

Challenges we ran into

  • A migration script silently dropped CREATE TABLE statements that were immediately preceded by a comment with no blank line — products and decisions looked "migrated" but weren't. Found it by directly querying information_schema instead of trusting the migration log.
  • CockroachDB's integer defaults to 64-bit, so node-pg returns it as a string for precision safety — our concurrency test's strict equality check silently failed until we cast it.
  • Early on, "request approval" and "execute purchase" were separate tool calls. If the model got APPROVED but forgot to call the second tool, both the purchase and the memory of it vanished silently. We fixed this structurally — approval and execution now happen inside a single tool call — rather than trying to prompt our way out of it.
  • Deploying the agent to AgentCore Runtime surfaced a chain of real infrastructure issues: direct_code_deploy hit a 30-second init timeout (switched to a container build), the execution role had no DynamoDB permission for our table, and CockroachDB's sslmode=verify-full needed a CA certificate file that only existed on our laptop — it worked locally by accident and failed in the cloud until we bundled the cert into the image.
  • CockroachDB Cloud's official disruption-simulation feature (ccloud cluster disruption) returned a 403 for our organization, so we verified the 3-region SURVIVE REGION FAILURE setup via SHOW REGIONS / SHOW RANGES instead of a live region outage.

Accomplishments that we're proud of

  • Genuinely zero oversells under 50 concurrent purchase attempts against a stock of 3, every time we ran it.
  • All four tables verifiably replicated across three real regions, confirmed via CockroachDB's own system views, not just a config file.
  • Watching one AI (Claude Code, over the CockroachDB MCP Server) audit another AI's (the purchasing agent's) past decisions and flag a real inconsistency in the data — that's the kind of demo we didn't fully expect to work this well.

What we learned

CockroachDB's Postgres wire compatibility made porting our earlier Aurora DSQL prototype almost mechanical. Keeping the vector index in the same transactional database as the "real" data — instead of a separate vector store — removed an entire class of consistency problems we would otherwise have had to design around. And the approval gate taught us something about scope: it doesn't prevent overselling (CockroachDB's own consistency does that); it's a spending-policy control, and that distinction is exactly why it's the kind of decision worth an agent remembering.

What's next

Getting ccloud cluster disruption enabled for a genuine live region-failure demo, and exploring whether the recall step can be made a deterministic part of the flow rather than something the model chooses to do.

Built With

Share this project:

Updates