Rumor Memory Village

What it does

Rumor Memory Village is a durable, provenance-aware memory layer for systems where agents exchange information of uneven reliability. Each agent holds its own memories tagged with source, confidence, and time. Information passes between agents, loses fidelity in transit, and is sometimes refused. When two accounts cannot both be true, both are kept and only the verdict moves — every verdict can be recomputed from the evidence that produced it.

The demonstration follows five villagers and one disputed afternoon. They end up holding three incompatible views of the same event, and the interface shows exactly why: who told them, how much they trusted that person, how much confidence survived each retelling, and how existing relationships affected the result.

The same substrate applies to contamination tracking in multi-agent RAG, provenance in incident response, and handover quality in customer support.

How we built it

Memories are stored in CockroachDB with 384-dimensional embeddings and searched through a cosine vector index prefixed by (world_id, owner_npc_id), so every search is scoped to one agent in one isolated demo world before distance is considered.

Agent recall runs exclusively through the CockroachDB Cloud Managed MCP Server. Transactional updates — belief re-evaluation, rumor propagation, provenance persistence, and per-visitor world forking — use a direct TLS SQL connection because Managed MCP provides read and insert operations but not the updates those transactions require. The recall path fails closed and never silently falls back to SQL.

Ranking, decay, propagation, and belief arbitration are deterministic code. Amazon Bedrock Nova Lite may rewrite a villager's sentence during pre-generation, with a clearly labelled deterministic template when no generated line exists; the model never decides what an agent believes. This makes every explanation auditable and reproducible.

The Next.js application and API run on AWS Amplify Hosting. Production credentials are retrieved server-side from AWS Secrets Manager. Each visitor receives an HMAC-signed, HttpOnly world cookie and an isolated fork of the village.

Challenges we ran into

The most useful bug was silent: with missing statistics, or in a newly forked world absent from histograms, the CockroachDB planner estimated too few matching rows and selected a primary-key scan. Recall still returned correct memories, so the Distributed Vector Index was simply not being used. The production query now names the vector index, and verification fails if the plan regresses.

Managed MCP limits also shaped the design: 16,384 characters per statement and 10 KiB per response. Ranking therefore retrieves only the fields used by scoring, groups duplicated memories by claim and provenance root, and fetches prose only for the few memories actually selected.

What we learned

Agent memory needs more than storage. Source identity, immutable provenance, independent corroboration, repetition, simulated-time decay, contradictions, refusals, and deterministic arbitration all have to remain separate if an agent's conclusion is going to be explainable.

What's next

The propagation and arbitration core is engine-agnostic and exposed behind an HTTP API, so the next step is integrating it into a game runtime and evaluating the same memory model in multi-agent RAG and operational handover workflows.

Built With

• amazon-bedrock
• aws-amplify
• aws-secrets-manager
• cockroachdb
• cockroachdb-cloud-managed-mcp-server
• cockroachdb-distributed-vector-indexing
• next.js
• typescript