RecallOps — Incident memory that closes unfinished work

Inspiration

I wanted to learn how AWS and a distributed database actually work. Tutorials only get you to "deploy a website". I wanted to build something that forces me to handle secrets, permissions, retries, and failures.

I also kept hearing the same story from ops people: an incident hits at 3 AM, someone restarts the server, everyone goes back to sleep, and the permanent fix never gets done. Months later the same incident comes back. It is not a tooling problem. It is a memory problem.

What it does

RecallOps is an approval-gated incident war room. When an incident arrives, it is stored in S3 and CockroachDB. The agent recalls similar past incidents from a vector index, asks the CockroachDB Cloud Managed MCP server to check if the old fix is still unfinished, and gets one grounded proposal from Amazon Bedrock. A human approves it. After resolution and verification, a new memory is stored. Refresh the page and everything is still there.

How we built it

Next.js frontend, two Node.js Lambda functions, a CockroachDB schema with a vector index, and AWS CDK for infrastructure. Bedrock Nova 2 Lite for assessments and Titan V2 for embeddings. Playwright tests and unit tests run in CI.

Challenges we ran into

The ccloud CLI version we had was missing some commands, so we created the MCP key through the console and verified the real role grants via the CLI instead. API Gateway v2 stores cookies differently than v1, which broke sessions until we fixed it. Bedrock also tried to invent actions, so we forced a single action schema and made the final proposal come from the MCP result, not from the model.

Accomplishments that we're proud of

The grounding pattern: the action the AI proposes comes from verified database state via MCP, not from the model guessing. Also 19 unit tests, a Playwright golden path, and a demo that honestly labels its synthetic seed history.

Built With

• amazon-web-services
• cockroachdb
• next.js