Sentinel — Persistent Memory for AI Agents

An incident-response agent whose memory lives entirely in CockroachDB — durable task state, conversation history, and vector-indexed recall of past incidents — running on AWS Bedrock + Lambda

Comment

Inspiration

AI agents are moving fast from demos into real production work — writing code, triaging incidents, running pipelines. But almost every agent demo we'd seen kept its "memory" in a Python dict or a local file, which is fine for a five-minute demo and completely wrong for production. The moment the process restarts, scales past one instance, or a region blips, that memory is just gone. The CockroachDB × AWS Hackathon's framing nailed the actual problem: agents need memory that never goes down — durable, distributed, and consistent, not a toy in-memory cache.

We wanted to build something that took that literally: an agent where you could kill the process mid-task, come back an hour later from a completely different machine, and it would pick up exactly where it left off — because none of its state ever lived only in memory.

What it does

Sentinel is an incident-triage agent for DevOps teams. When an incident comes in (from an alert, a webhook, or our CLI demo), it:

  1. Embeds the incident text and searches CockroachDB's Distributed Vector Indexing for similar past incidents and how they were resolved.
  2. Sends the incident, the retrieved memories, and the full conversation history to Amazon Bedrock (Claude) for a triage decision — a root-cause hypothesis, a next diagnostic step, and whether it looks safe to resolve autonomously or needs a human.
  3. Writes the response, updated task state, and (once resolved) a full incident report back to CockroachDB — and to S3 for the longer write-up — all inside a transaction.

Because every one of those steps reads and writes through CockroachDB, any later invocation — a retry, a follow-up question hours later, a totally different Lambda cold start — resumes from exactly what's in the database. We tested this literally: killing the process mid-conversation and reopening it from a fresh terminal, and the agent picked the conversation back up with full context, because nothing lived only in memory.

How we built it

  • CockroachDB is the persistent memory layer: incidents and task_state for durable case-file/task-progress state, conversation_messages for full multi-turn history, and incident_embeddings (a VECTOR(1024) column with a CREATE VECTOR INDEX) for semantic recall of similar past incidents.
  • Amazon Bedrock provides both the reasoning (Claude Sonnet 4.5) and the embeddings (Titan Text Embeddings V2) — no separate model-hosting infrastructure.
  • AWS Lambda runs the agent step end-to-end as a stateless function, deployed via an AWS SAM template; Amazon S3 stores the longer-form incident reports, with CockroachDB keeping just the pointer.
  • The CockroachDB Cloud Managed MCP Server let us inspect the live memory store directly from Claude Code during development — read-only, fully audit-logged, with zero custom proxy code.
  • The ccloud CLI's agent-ready design informed our provisioning script for non-interactive cluster setup.

Challenges we ran into

  • CockroachDB Cloud's browser SQL Shell intermittently timed out on CREATE DATABASE specifically (while every other statement, including CREATE TABLE and CREATE VECTOR INDEX, ran fine) — we worked around it by just running everything against defaultdb instead of provisioning a separate database, which works just as well for this use case.
  • Bedrock's newest Claude models require routing through a cross-region inference profile rather than the bare model ID — on-demand InvokeModel calls kept failing until we prefixed the model ID correctly (global.anthropic.claude-sonnet-4-5-... instead of the plain model ID).
  • Windows consoles default to a legacy cp1252 encoding that can't render some characters an LLM naturally produces (em dashes, smart quotes), which crashed our first demo recording with a UnicodeEncodeError. Fixed by forcing UTF-8 stdout in the CLI (with a safe fallback) so this can't happen to anyone running the repo.
  • AWS's "new customer" free-tier eligibility didn't apply to this account, which was a bit of a scare mid-hackathon — but it turned out to be a non-issue, since Bedrock + Lambda + S3 usage for a demo like this runs to a few cents total.

Accomplishments that we're proud of

Getting genuine cross-process persistence working, not just claiming it: you can watch the agent recall a seeded incident's root cause purely from CockroachDB's vector index (with the actual cosine-distance score printed), and continue a conversation from a completely fresh process invocation with full context intact.

What we learned

That "agentic memory" isn't really a new problem — it's the same durability and consistency problem databases have always solved, just applied to a new kind of client that writes constantly and can't tolerate a maintenance window. Reaching for CockroachDB instead of a bespoke vector store + a separate state store also just... simplified everything. One connection string, one consistency model, no dual-write problem between an app DB and a vector DB.

What's next

Exposing the CockroachDB Agent Skills to the running agent (not just used at dev-time) via an MCP resource, so it can self-correct its own query patterns; a LangChain wrapper so Sentinel can drop into existing agent graphs; and multi-tenant isolation via CockroachDB row-level security for real multi-team usage.

Built With

  • amazon-web-services
  • anthropic-claude
  • aws-bedrock
  • aws-lambda
  • aws-sam
  • boto3
  • cockroachdb
  • cockroachdb-cloud
  • distributed-vector-indexing
  • llm-agent
  • model-context-protocol
  • postgresql
  • psycopg
  • python
  • vector-search
Share this project:

Updates