DecisionVault

An AI engineering copilot that remembers past architecture decisions, detects contradictions, and evolves project knowledge using persistent CockroachDB memory

Comment

Inspiration

Software teams make important architecture decisions every day: which authentication approach to use, which database to adopt, which framework to standardize on, or which design tradeoffs are acceptable. The problem is that those decisions often get buried in chat threads, tickets, documents, or old meetings.

Later, someone may unknowingly suggest something that directly contradicts an earlier decision.

We wanted to build an AI agent that does more than remember conversation history. We wanted an agent that could preserve important technical decisions as durable memory, retrieve them when they become relevant, and actively use them to prevent contradictory decisions.

That idea became DecisionVault.

The project was also a natural fit for the CockroachDB × AWS Hackathon because long-term agent memory is the core of the application, not an optional feature. Without persistent memory, DecisionVault loses its purpose.

What it does

DecisionVault is an AI engineering copilot that remembers architecture decisions across separate conversations and uses those memories to improve future reasoning.

A developer can record a decision such as:

We will use OAuth 2.1 with PKCE for authentication. JWT-only authentication is rejected.

DecisionVault stores that decision in CockroachDB along with structured metadata and a vector embedding.

Later, even in a completely new conversation, the developer might say:

We are switching to JWT-only authentication and removing OAuth.

DecisionVault performs semantic memory retrieval, finds the earlier OAuth decision, recognizes that the new request conflicts with it, and warns the developer.

If the developer intentionally confirms the new direction, DecisionVault stores the new decision and marks the previous one as superseded, preserving the historical relationship between the two.

This creates a simple but powerful memory lifecycle:

remember → retrieve → reason → act → update memory

DecisionVault therefore treats CockroachDB as an actual system of record for agent memory instead of simply storing chat logs.

How we built it

DecisionVault uses a lightweight full-stack architecture designed to demonstrate production-style agentic memory while remaining simple enough to deploy and understand.

The frontend is a minimal browser interface for creating workspaces, starting conversations, recording decisions, viewing memory, and testing contradictions.

The backend is built with FastAPI and implements the agent loop.

For every user message, DecisionVault:

  1. Saves the conversation context.
  2. Generates a semantic embedding using Amazon Titan Text Embeddings V2.
  3. Searches CockroachDB for related active memories.
  4. Sends the current message, relevant history, and retrieved memories to Amazon Bedrock.
  5. Uses Amazon Nova 2 Lite to generate a structured agent plan.
  6. Validates the model output before allowing any memory change.
  7. Writes the response and any new memory changes to CockroachDB.
  8. Records execution metadata for observability and debugging.

CockroachDB Distributed Vector Indexing

CockroachDB stores both operational data and semantic memory.

Each durable memory contains information such as:

  • workspace
  • source message
  • memory type
  • subject
  • content
  • stance
  • status
  • importance
  • confidence
  • embedding
  • metadata
  • supersession relationship

The memory embedding is stored as a VECTOR(256) value.

A CockroachDB vector index allows DecisionVault to retrieve memories based on semantic meaning instead of relying on exact keyword matches.

This means a new statement about "removing OAuth in favor of JWT" can still retrieve an earlier authentication decision even when the wording is different.

CockroachDB Cloud Managed MCP Server

We also integrated the CockroachDB Cloud Managed MCP Server as a safe inspection layer.

The application includes a read-only MCP inspector that can:

  • list databases
  • inspect tables
  • inspect the memory schema
  • query memory status counts

The MCP integration does not convert arbitrary user prompts into SQL. It only performs predetermined read-only operations, which makes the integration safer and easier to audit.

This gave us a second meaningful CockroachDB integration beyond the normal application database connection.

AWS

DecisionVault uses several AWS capabilities:

  • Amazon Bedrock for AI reasoning
  • Amazon Titan Text Embeddings V2 for memory embeddings
  • Amazon Nova 2 Lite for agent planning and responses
  • AWS Lambda for serverless backend execution
  • Amazon API Gateway for the public application endpoint

The project also includes an AWS SAM template so the application can be deployed as a reproducible serverless stack.

Challenges we ran into

One of the biggest challenges was deciding what should count as "memory."

Simply saving every conversation message would technically create persistence, but it would not demonstrate meaningful agentic memory. We therefore separated normal conversation history from durable structured memories such as architecture decisions.

Another challenge was safely allowing the model to modify memory.

We did not want an LLM to arbitrarily overwrite historical decisions. The backend therefore validates the model's plan and only permits memory references that were actually retrieved during that turn.

We also needed to handle changes in technical decisions correctly.

Deleting an old memory would remove valuable history, so instead we modeled decision evolution explicitly. When a newer decision replaces an older one, the original record becomes superseded and points to its replacement.

Vector search introduced another design challenge. Memory retrieval needed to remain isolated between workspaces, so semantic search is filtered by workspace before active memories are used by the agent.

Finally, integrating an AI application across CockroachDB, Bedrock, Lambda, API Gateway, embeddings, MCP, and a browser frontend required us to keep the architecture intentionally small. Given the limited hackathon window, we prioritized a reliable end-to-end memory workflow over adding many unrelated features.

Accomplishments that we're proud of

The feature we are most proud of is the fresh-session contradiction demo.

A user can record a technical decision, close that context, start a completely separate conversation, and then propose an incompatible architecture change.

DecisionVault retrieves the earlier memory semantically and uses it to change the agent's behavior.

That demonstrates that the memory is not decorative. The agent genuinely depends on CockroachDB memory to reason correctly.

We are also proud of the decision supersession model.

Instead of destroying history, DecisionVault preserves both the previous and current decisions and creates an explicit relationship between them. This makes the agent's memory explainable and auditable.

Other accomplishments include:

  • semantic long-term memory using CockroachDB vector indexing
  • integration with CockroachDB Cloud Managed MCP
  • Bedrock-powered reasoning and embeddings
  • transactional memory updates
  • workspace-level memory isolation
  • retry handling for database transactions
  • structured execution logs
  • serverless AWS deployment configuration
  • automated tests for the core memory lifecycle
  • a reproducible migration and deployment workflow

What we learned

The biggest lesson was that good agent memory is not the same thing as storing more text.

Useful memory needs structure, relevance, lifecycle management, and clear rules for how an agent is allowed to act on it.

We learned that semantic search works especially well when combined with structured relational data. The embedding helps find a relevant memory, while normal database fields provide status, ownership, provenance, confidence, and relationships.

That combination is one of the reasons CockroachDB worked well for DecisionVault: both operational state and vector memory can live in the same database.

We also learned the importance of making memory changes auditable. An agent should not silently rewrite its understanding of a project. Preserving previous decisions and showing when they were superseded makes the system much easier to trust.

Finally, building with Amazon Bedrock reinforced the value of separating model reasoning from deterministic application logic. The model proposes actions, while the backend validates and executes them.

What's next for DecisionVault

The next step is to evolve DecisionVault from a focused architecture-memory prototype into a collaborative engineering memory platform.

We would like to add integrations with tools such as GitHub, Slack, Jira, and documentation platforms so architecture decisions can be captured automatically from real engineering workflows.

We also want to add richer memory types, including:

  • architectural constraints
  • incidents and resolutions
  • rejected alternatives
  • security requirements
  • infrastructure decisions
  • performance findings
  • project conventions

Another future direction is team-aware memory. Different engineers could contribute evidence, challenge existing decisions, and review why a decision changed.

We would also like to add temporal reasoning so the agent understands not only what a team decided, but when it was valid and what later events caused it to change.

Long term, we see DecisionVault becoming a persistent engineering knowledge layer: an AI system that does not just answer questions about a software project, but actually remembers how and why that project evolved.

Built With

Share this project:

Updates

Submission history