Recall

• 

  memory page

• 

  recall page

• 

  home page

• 

  after generated API key

• 

  guide page

About the project

One sentence: Recall is a relationship-memory agent — you tell it in plain words about people you meet, and it remembers the facts, recalls them with citations, and nudges you to follow up before relationships go cold.

The problem. Founders, salespeople, recruiters, investors, and community builders meet dozens of people a month. They forget names, context, and — most painfully — promises. The tools that exist either don't recall (note apps) or make you do data entry (CRMs). The pain is frequent, emotionally charged (embarrassment, lost deals), and badly served.

The thesis. An AI that helps you remember people is only useful if its memory is durable, consistent, and trustworthy. That is precisely a database problem — not a prompt-engineering problem. Recall is built around one CockroachDB cluster that stores both the structured relational memory and the semantic vector memory, with no second vector store to keep in sync. No Postgres + Pinecone drift. No "the embeddings don't match the rows" failure mode. Just one strongly-consistent store where capture is one transaction and recall is one query.

What the agent does.

• Thinks — extracts the person, the durable facts, and the follow-ups you owe from a single sentence, using Amazon Bedrock (Mantle + Voxtral Mini).
• Remembers — writes the raw memory, its embedding, the derived facts, and the commitments in one CockroachDB transaction. The vector index and the relational rows can never drift out of sync.
• Recalls — answers natural-language questions with citations to the exact source memories. The answer is grounded, auditable, never invented.
• Acts — a daily "Today" feed of due/overdue follow-ups with pre-drafted reconnect messages. A serverless Lambda cron generates gentle "reconnect" nudges for relationships that have gone cold — the agent acts without being asked.

Why CockroachDB (and why it's the whole point)

The hackathon asks for "memory that never goes down" — agents that write constantly, persist across regions and failures, and never lose state. That's CockroachDB's design brief. Recall leans into the two things that make agentic memory a database problem rather than a wrapper problem:

1. Distributed Vector Indexing. memory_embedding uses the native VECTOR(1024) type with a CREATE VECTOR INDEX. Semantic recall is a KNN query (embedding <-> $query) joined to person/memory, all scoped by user_id, in one SQL statement. The vector index lives in the operational database — no separate vector store, no reindexing pipeline, no consistency gap.
2. Transactional capture. The raw memory, its embedding, the extracted facts, and the commitments are written together. If anything fails, it all rolls back. This is the anti-drift guarantee that Postgres+Pinecone architectures simply cannot give you.

Every recall answer returns citations to the source memory rows. The anti-hallucination story is structural, not cosmetic: facts carry source_memory_id, and the model is instructed to say "I don't have a memory of that yet" rather than invent relationships.

How we built it

Stack. Next.js 15 (App Router, React 19, TypeScript strict), Tailwind, CockroachDB Cloud Serverless, AWS Bedrock, pg + jose + Zod. Deployed on AWS Amplify Hosting.

The AI layer. Two paths with honest, documented fallbacks:

• Extraction & recall synthesis via the Bedrock Mantle endpoint (OpenAI-compatible chat), authenticated with a Bedrock API key.
• Embeddings via Titan Text Embeddings v2 (1024-dim) through bedrock-runtime.
• When real embeddings aren't available, Recall automatically swaps to an LLM reranker: the text model ranks a recent-memory pool by meaning, blended with KNN top candidates. Paraphrase recall — "who's recruiting frontend people?" → "hiring senior React engineers" — works in both modes. That resilience became a feature, not a workaround.

The two-agent architecture. Recall exposes its memory layer to a second agent through the CockroachDB Cloud Managed MCP Server — read-only by default, fully audited, zero custom proxy. An ops agent (Claude Code/Cursor) can inspect the same cluster the product uses: "which person has the most memories?", "what does the audit log show?" It can observe the memory engine but never modify it. Two agents, one memory layer.

Production posture. Per-user isolation on every query, parameterized SQL everywhere, signed httpOnly sessions, an append-only audit log, per-user rate limiting, structured JSON logging, a health endpoint that verifies DB + vector index at runtime, and tests for the core logic.

Challenges we faced

1. The embedding path was the hardest part. Titan embeddings through bedrock-runtime need IAM credentials and Bedrock model access; the Mantle chat endpoint needs only an API key. On a fresh account, model access is NOT_AUTHORIZED until you click it in the console — and the quota API shows 0 in some regions. We diagnosed it end-to-end: IAM is fine, the model is authorized-checkable, but the account simply isn't granted access until the one-time console step. Rather than block on that, we built the LLM reranker fallback — which turns out to make semantic recall work in both modes.
2. App Runner was deprecated mid-build (AWS stopped onboarding new customers). We pivoted the deployment to Amplify Hosting and hit its SSR sharp edges: the AWS_ env prefix is reserved, the build needs an IAM service role to read env vars from SSM, and the SSR compute doesn't reliably receive branch env vars at runtime (fixed by materializing .env.production at build time).
3. Making recall trustworthy, not just fast. The hardest product problem was ensuring the agent never fabricates relationships. Citations to source memories, a strict fallback, and grounding the synthesis in retrieved rows only — every answer is auditable back to the memory it came from.

What we learned

• "Memory is a database problem" is not a slogan — it's the architecture. Putting relational rows and vectors in one transactional store eliminates an entire class of consistency bugs that "AI + vector DB" stacks ship with.
• Resilience is a feature judges can see. Graceful degradation (mock AI, LLM reranker, no-credential demo mode) means the product is always runnable — that matters in a demo.
• Agents that act are the differentiator. The proactive nudge cron turns a passive memory tool into something that pulls you back daily.

Built With

• amazon-bedrock
• cockroachdb
• distributed-vector-index
• jose
• mcp-server
• nextjs
• pg
• rag
• semantic-search
• typescript
• vector-database
• zod