HeatRecall

Inspiration

What happens when dispatch AI confidently sends workers into a 47°C corridor — and forgets it happened every single week?

That question kept me up during a heat wave. Naive dispatch optimizes for speed: I-10 Express, 14:00 departure, 47°C mean exposure. The same corridor caused three heat incidents last month. No memory. No learning. Crews keep entering hot corridors because the agent treats every dispatch as day one.

I wanted to prove that agentic memory is not chat history — it is structured, searchable, transactional state that changes how an agent acts. HeatRecall is that proof: a field dispatch agent that remembers every hot corridor before it acts.

How we built it

HeatRecall runs a Recall · Act · Persist loop on production AWS + CockroachDB Cloud:

1. Recall — Hybrid search on dispatch_memories: keyword filter on corridor_id + cosine vector similarity via dispatch_vec_idx on VECTOR(512) embeddings (Amazon Titan Embeddings V2).
2. Act — Amazon Bedrock Nova Lite reviews recalled incidents and overrides the naive fastest route when ≥2 heat incidents are found. Rules-based fallback when Bedrock quota is limited.
3. Persist — Transactional INSERT into dispatch_memories (with embedding) and memory_audit (persist_dispatch event). Every dispatch grows agentic memory.

Stack: Next.js demo UI (S3 static site) → API Gateway HTTP API → Lambda Node 20 → CockroachDB Cloud + Amazon Bedrock. Deployed with AWS SAM (pnpm deploy:aws).

The demo UI shows Naive vs HeatRecall side-by-side on the same corridor request. API responses include memoryPersisted: true, memorySource: cockroachdb, and persistedMemoryId.

CockroachDB tools (4/4)

AWS services

Lambda (Node 20), API Gateway HTTP API, S3 static website, IAM (Bedrock invoke), Amazon Bedrock (Nova Lite + Titan Embeddings V2).

What we learned

• One database for everything — CockroachDB holds structured dispatch rows, vector embeddings, and audit trail in one globally distributed store. No separate vector DB, no consistency gap between operational data and semantic recall.
• Memory must change behavior — Persisting rows is not enough. The demo proves memory changes the decision: Naive sends crew at 14:00 through 47°C I-10; HeatRecall recalls 3 incidents, overrides to Surface corridor at 06:00, −8.1°C mean exposure delta.
• Production needs fallbacks — Bedrock Nova is the primary Act layer, but rules-based threshold fallback keeps the loop alive when quota limits hit. Agentic systems degrade gracefully; they don't stop.
• Agent Skills encode expertise — Portable SKILL.md + verify scripts made Recall/Act/Persist reproducible in Cursor, not just in application code.

Challenges we faced

• Limited IAM on corporate AWS — First deploy used a corp account without iam:CreateRole or Bedrock access. Fix: personal hackathon account + SAM conditional IAM role creation.
• Hybrid recall tuning — Pure vector search missed corridor-specific context; pure keyword missed semantic similarity. Hybrid pre-filter + cosine ranking on dispatch_vec_idx was the sweet spot.
• Transactional persist — Memory write must include embedding + audit in one transaction. Partial writes would break the Recall-Act-Persist loop integrity.
• Bedrock quota — Nova Lite rate limits during heavy testing pushed agentSource to "rules" fallback. IAM and model access were correct; production resilience mattered more than always-on LLM.

Try it yourself

curl -s -X POST "https://ediqb9upjh.execute-api.us-east-1.amazonaws.com/prod/api/dispatch" \
  | jq '{memorySource, agentSource, memoryPersisted, persistedMemoryId}'

Expected: memorySource: cockroachdb, memoryPersisted: true.

Live demo: http://heatrecall-static-110156539038.s3-website-us-east-1.amazonaws.com
GitHub: https://github.com/adindamochamad/heatrecall

Built With

• amazon
• amazon-web-services
• api
• artificial
• bedrock
• cockroachdb
• cursor
• database
• gateway
• intelligence
• lambda
• learning
• machine
• mcp
• next.js
• node.js
• pnpm
• postgresql
• s3
• sam
• serverless
• services
• typescript
• vector
• web