Chronicle

Your AI agents forget why. Chronicle remembers.

Comment

About the project

AI agents are becoming capable enough to write code, investigate failures, and operate production workflows. The context they need, however, often disappears when a chat, task, or deployment ends. I built Chronicle to make that context durable: a system where agents can capture an engineering decision, incident, deployment, or experiment and retrieve it later with the evidence that explains why it happened.

Chronicle treats memory as more than a conversation transcript. Each memory is a structured record with a title, summary, repository and branch context, tags, confidence, importance, timestamps, provenance, metadata, vector embedding, and optional relationship edges. The result is a practical memory layer that remains useful across agent runs and production changes.

What inspired it

The inspiration came from a simple failure mode in agentic development: an agent can produce a useful answer today, then lose the reasoning behind that answer tomorrow. Engineering teams already struggle with lost decisions, incomplete incident context, and undocumented deployment history. Agents amplify that problem because they can create and consume context much faster than people.

I wanted to build a product that gives an agent durable organizational memory without splitting operational facts and embeddings into separate systems. CockroachDB was a natural fit because it can hold the transactionally correct record, the embedding used for retrieval, and the relationships between memories in one distributed SQL database.

How I built it

Chronicle has three live components:

  1. A Next.js frontend hosted as a static application in Amazon S3.
  2. A FastAPI service running on AWS Lambda behind Amazon API Gateway.
  3. A CockroachDB Cloud cluster that stores the persistent memory records, relationship graph, access audit events, and VECTOR(512) embeddings.

The frontend sends a search request to the Lambda API. The API writes and retrieves memories from CockroachDB Cloud. Retrieval supports keyword, semantic, and hybrid modes. Hybrid search combines cosine-similarity ranking over stored vectors with keyword relevance, keeping both retrieval methods close to the transactional engineering record.

The deployed app is configured with a narrow CORS policy, verified TLS to CockroachDB Cloud, and no required model-inference calls. This keeps the demo practical to run while still demonstrating persistent vector-backed agent memory.

CockroachDB tools used

  • Distributed Vector Indexing: I created a project-prefixed cosine vector index over the memories.embedding column. Chronicle writes a vector with every durable memory and uses vector similarity during semantic and hybrid retrieval.
  • ccloud CLI: I used the agent-ready CockroachDB Cloud CLI to connect to the live cluster, apply the production vector index, and validate the deployed schema and database access.
  • Cloud Managed MCP Server: The repository includes a safe MCP configuration template for CockroachDB Cloud. This lets MCP-compatible coding agents inspect the Chronicle schema and work with the database through the Cloud MCP integration.

AWS services used

  • AWS Lambda runs the Chronicle API without maintaining servers.
  • Amazon API Gateway exposes the API to the browser client.
  • Amazon S3 hosts the static frontend demo.
  • AWS CloudFormation / SAM packages and deploys the serverless infrastructure.

Challenges I faced

The most important challenge was making the vector layer genuinely production-oriented rather than treating it as a separate demo database. CockroachDB Cloud's web SQL shell could not build the vector index in this environment, so I used the ccloud CLI to apply the index successfully.

I also had to adapt the schema and query approach to the managed cluster's supported SQL features. Finally, the Lambda runtime needed an explicit trusted CA bundle for CockroachDB Cloud so that the app could preserve strict TLS certificate verification rather than weakening database security.

What I learned

I learned that reliable agent memory is a systems problem, not only an LLM problem. The memory record needs transactional correctness, durable writes, security, retrieval quality, and operational visibility. Combining structured data, vector search, and relationship context in CockroachDB simplified the architecture and avoided consistency gaps between an operational database and a separate vector store.

I also learned that a live demo is stronger when it proves the full path: browser search, AWS-hosted API, CockroachDB-backed retrieval, and a persistent record visible in the interface.

Live persistent-memory dashboard

Chronicle running live on AWS. The interface shows CockroachDB connected, one persisted engineering memory, and the memory inspector with provenance, branch, confidence, and supporting context.

Hybrid vector and keyword retrieval

A live search for “production deployment” returns the persisted deployment memory. Chronicle labels the retrieval path as Vector + keyword retrieval, demonstrating hybrid search over CockroachDB-backed agent memory.

Causal-context graph

Chronicle's graph view provides the foundation for linking incidents, experiments, decisions, and fixes as durable causal context accumulates.

Built With

  • agent-memory
  • ai-agents
  • amazon-api-gateway
  • amazon-web-services
  • aws-cloudformation
  • aws-lambda
  • aws-sam
  • ccloud-cli
  • cockroachdb
  • cockroachdb-cloud
  • distributed
  • distributed-vector-indexing
  • fastapi
  • hybrid-search
  • model-context-protocol
  • next.js
  • postgresql
  • python
  • serverless
  • typescript
  • vector-search
Share this project:

Updates

Submission history