CloudGPT v2

Inspiration

AWS teams can end up dealing with hundreds of alerts, and the frustrating part is that many of them are not actually new problems. An engineer may have already investigated an alert, decided that it was a known issue, or applied a remediation, only to see essentially the same alert appear again later.

That made us think about a simple question: what if the monitoring agent could actually remember?

Most alerting systems are good at detecting something, but they do not have much context about what happened the last time. We wanted to build an agent that could look at a new alert, remember similar incidents from the past, understand what decision was made, and use that experience when handling the next one.

That idea became CloudGPT v2.

What it does

CloudGPT v2 is an agentic AWS monitoring system with persistent semantic memory.

It can receive alerts from sources such as CloudWatch, Security Hub, AWS Config and Cost Explorer. Instead of treating every alert independently, it extracts the important facts from the alert and searches its previous memories for semantically similar incidents.

The agent then decides whether the memory should be ADD, UPDATE, DELETE or NOOP. Based on the resulting context, it classifies the alert as:

NEW_ALERT - something it has not seen before KNOWN_PATTERN - a previously encountered issue SUPPRESS - an issue that has already been handled ESCALATE - a recurring unresolved issue that needs attention

The important part is that these decisions are not lost after the session ends. They become part of the agent's long-term memory.

How we built it

The core of the project is the Mem0 memory architecture, implemented with CockroachDB as the unified memory backend.

When an AWS alert arrives, our ingestion layer first normalizes it into a standard format. An LLM extracts the factual information worth remembering, and the fact is converted into a 768-dimensional embedding using Ollama's nomic-embed-text.

That embedding is stored in CockroachDB and searched using its native vector indexing. For a new alert, we retrieve the most similar previous memories and give that context to the LLM. The LLM then determines the appropriate memory operation and the agent's final response.

We deliberately kept the structured memory, embeddings and decision history inside CockroachDB. This means the memory data and its metadata can be updated together instead of maintaining separate vector and SQL systems that can drift apart.

We also use Amazon S3 for the raw archive. Every processed alert, together with the agent response and decision, is stored as structured JSON. CockroachDB is therefore the agent's intelligent memory, while S3 acts as the complete event archive.

The backend is built with FastAPI and the interface with Streamlit. We also integrated CockroachDB's Managed MCP Server so that the memory can be inspected through natural-language queries during development.

Challenges we ran into

The hardest part was not simply getting an LLM to respond to an alert. The real challenge was making the agent remember correctly.

A memory system can easily become useless if it stores everything, stores duplicates, or fails to update information when circumstances change. We therefore had to design the ADD, UPDATE, DELETE and NOOP decisions around semantic similarity rather than simple keyword matching.

Another challenge was keeping the vector representation and the structured memory information consistent. This was one of the main reasons we chose CockroachDB as the unified backend instead of splitting the system across separate databases.

We also had to think carefully about the difference between a known issue and a recurring unresolved issue. Suppressing everything that looks familiar would be dangerous, so the agent needs its previous decisions and remediation history to distinguish between something that can be ignored and something that should be escalated.

Accomplishments that we're proud of

The biggest thing we are proud of is that the memory is actually part of the agent's decision-making, not just a database attached to the project.

Our demo shows this directly. In the first round, the system processes new alerts and stores their memories. When the same alerts are introduced again, the agent can recognize them and suppress issues it already knows about. When an issue continues to recur without being resolved, the system can escalate it instead.

We are also proud of the CockroachDB integration. We use its vector capabilities for semantic memory while keeping the structured memories and decision audit trail in the same database. This makes CockroachDB a core part of the reasoning pipeline rather than a cosmetic integration.

What we learned

We learned that giving an agent memory is not just about storing previous conversations. The difficult part is deciding what is worth remembering, when an existing memory should change, and how that memory should influence the next decision.

Building this also made the trade-offs around vector search, structured data and transactional consistency much clearer to us. We learned how much context can be lost when these pieces are treated as completely separate systems.

Most importantly, we learned that an agent becomes much more useful when its previous actions actually affect what it does next.

What's next for CloudGPT v2

The current system focuses on AWS alerts, memory and contextual decision-making. The next step would be to make the remediation side more autonomous while keeping appropriate human control over high-impact actions.

We also want to expand the memory beyond individual alerts so the agent can build a longer history of recurring issues, remediation outcomes and resource-level patterns.

Our long-term goal is simple: an AWS agent that does not just tell you what is happening, but remembers what happened before and gets better at deciding what deserves your attention.