Agent Memory Meets Graph: Introducing MemGraph

Last Tuesday, your AI agent diagnosed a Lambda-to-RDS connection storm. It found the missing connection pooling, recommended the fix and walked the team through rolling it out.

On Wednesday, the same pattern showed up in a different service, and the agent started from zero.

That's the core problem with AI agents today: they're stateless. Each conversation is a blank slate. The operational knowledge a team builds over months of incidents, optimizations and architecture decisions is gone the moment the session ends. We built MemGraph to fix that, and this post goes through how it works, down to the storage backends.

---

Why the obvious approach fails

The obvious fix is a vector store: embed past conversations and documents, retrieve the nearest ones at query time. Most agent platforms stop there. For operational knowledge, it fails in three structural ways.

01Gap 1

No relationships

Every memory is an island. Prerequisites and conflicts are invisible.

02Gap 2

No evolution

The old gp2 procedure ranks next to the gp3 guide that replaced it.

03Gap 3

No signal

A fix proven 50 times weighs the same as one used once.

No relationships. Every memory is an island. A flat document store can't express that "before you resize an EKS node group, you must understand node affinity rules." There's no notion of prerequisite knowledge, conflicting approaches or superseded procedures.

No evolution. Knowledge goes stale. The gp2 resize procedure from six months ago sits next to the current gp3 migration guide with equal weight. Outdated knowledge is worse than none, because it leads agents to give wrong answers confidently.

No signal. All memories are equal. A procedure validated 50 times in production ranks the same as one used once and never confirmed. There's no earned trust, no reinforcement, no contradiction.

Traditional RAG is a filing cabinet. You can find documents, but the cabinet doesn't know which are related, which are outdated, or which actually worked. Operational memory has to behave more like an experienced engineer: connect what it knows, prefer what's proven, and quietly retire what no longer applies.

---

Memory as a knowledge graph

MemGraph stores each piece of operational knowledge as a node in a graph, connected to other knowledge through typed relationships. Every conversation flows through the same loop: knowledge is extracted, curated against what's already there, stored with its edges, and retrieved by the next conversation that needs it.

Five memory types

Not all knowledge is the same, so MemGraph classifies memories into five types, each suited to different retrieval patterns:

• Procedural: step-by-step workflows and tool sequences
• Factual: rules, constraints and best practices
• Episodic: success stories with the reasoning behind them
• Incident: root cause analysis from real incidents
• Developer pattern: team-specific habits and preferences

Procedural memory: the how-to library

Reusable workflows that solved real problems in your environment. The agent's playbook.

Task: Resize EKS node group with zero downtime
Solution:
  1. Cordon existing nodes (prevent new pod scheduling)
  2. Create new node group with target instance type
  3. Wait for new nodes to reach Ready state
  4. Drain old nodes (graceful pod eviction with PDB respect)
  5. Verify all pods rescheduled on new nodes
  6. Delete old node group
Context: Production EKS clusters with PodDisruptionBudgets configured

Factual memory: the rulebook

Hard constraints, best practices and organizational rules. They stop an agent from suggesting a non-compliant configuration, even when it would be cheaper or simpler.

Task: RDS instance configuration requirements
Solution: Production RDS instances in us-east-1 MUST use Multi-AZ deployment.
          Single-AZ is only permitted for dev/staging environments.
          Minimum backup retention: 7 days for prod, 1 day for non-prod.
Context: Compliance requirement from SOC2 audit (2025-Q3)

Episodic memory: the war stories

Successful resolutions with the reasoning behind them, so the agent can apply the same reasoning to a new problem.

Task: Reduce EBS costs for data processing workloads
Solution: Migrated 47 gp2 volumes to gp3 with custom IOPS/throughput tuning.
          Result: 42% cost reduction ($8,400/month savings) with 15% better throughput.
Reasoning: gp2 IOPS scales linearly with volume size, forcing over-provisioning.
           gp3 decouples IOPS from size, so you only pay for what you use.

Incident memory: the post-mortems

Root cause analysis turned into reusable diagnostic patterns. When a similar pattern shows up, the agent recognizes it and applies the proven fix instead of diagnosing from scratch.

Task: Lambda-to-RDS connection exhaustion (P1 incident)
Root Cause: Lambda functions creating new DB connections per invocation.
            Under load (500 concurrent), exceeded RDS max_connections (150).
Solution: Implemented RDS Proxy with connection pooling.
          Set max_connections_percent=70 to reserve headroom.
          Added CloudWatch alarm on DatabaseConnections metric.

Developer pattern memory: the team playbook

Team-specific preferences, conventions and tooling choices, so recommendations match how your team works: not generic best practice, but your practice.

Task: Infrastructure deployment preferences for Platform Team
Solution: Team uses Terraform modules exclusively (no raw CloudFormation).
          Naming convention: {env}-{service}-{resource} (e.g., prod-api-rds).
          Prefers blue-green over canary for stateful services.

---

Seven relationship types: the "graph" in MemGraph

Individual memories are useful. The connections between them are what make the memory reliable. MemGraph supports seven typed relationships:

Here's why the edges matter. When an agent retrieves the EKS node resize memory, MemGraph also surfaces the prerequisite knowledge about PodDisruptionBudgets. It flags that the old EC2-based resize method has been superseded. It warns that the spot instance approach conflicts with this workload's SLA. The agent gets the answer plus the context it needs to apply it correctly.

---

The evolution pipeline: memories that learn

Most memory systems only append. Every new piece of knowledge goes on the pile, and over time the pile becomes noise. MemGraph curates: every new memory goes through an LLM-driven pipeline that decides how it fits with what's already known.

01Extract

0 to 5 patterns

An LLM distills each conversation into reusable operational knowledge.

02Search

Hybrid lookup

BM25 keywords plus dense vectors find what the graph already knows.

03Evolve

Store, combine, discard

An LLM decides whether the memory is new, overlapping or a duplicate.

04Connect

Typed edges

Prerequisites, alternatives and conflicts become relationships.

1. Extract. After each conversation, an LLM reads the dialogue and extracts 0 to 5 reusable patterns. Not raw chat logs, but distilled knowledge: the method that worked, the reasoning behind it, and the context where it applies.

2. Search. For each extracted memory, MemGraph searches the graph for related memories using hybrid search: exact keyword matching (BM25) plus semantic similarity (vector embeddings), merged through Reciprocal Rank Fusion.

3. Evolve. An LLM compares the new memory with the search results and makes one of three decisions:

• STORE: genuinely new knowledge. Add it to the graph and build typed relationships to existing memories.
• COMBINE: it overlaps with something already known. Merge the two into one stronger, more complete memory.
• DISCARD: already known. Don't pollute the graph with a duplicate.

4. Connect. For stored or combined memories, the LLM decides which existing memories have meaningful relationships (prerequisites, alternatives, conflicts) and builds typed edges. Keywords from related memories are enriched into the new node.

This is where the design pays off. Over time the graph doesn't just grow; it gets sharper. Combined memories become more complete, superseded ones get flagged, validated procedures collect reinforcement. The graph converges on a refined, high-signal picture of your team's operational expertise.

Confidence signals: earned trust, not static scores

Every memory carries confidence signals that change over time:

• Access count: how often the memory has been retrieved. Frequently used memories are likely valuable.
• Reinforcement: how often new evidence has confirmed it. Validated knowledge ranks higher.
• Contradiction: how often new evidence has conflicted with it. Flags unreliable knowledge.
• Supersession: whether a newer, better version has replaced it. Stops outdated advice from being served.

A procedure reinforced 50 times gets a 5 to 50% score boost in search results. A memory contradicted several times gets flagged for review. Trust is earned in your environment, not assigned up front.

---

Hybrid search: the right memory at the right time

When an agent needs operational knowledge, MemGraph combines three retrieval strategies:

01Keyword

BM25

Sparse vectors for exact terms: error strings, service names, configs.

02Semantic

Embeddings

Dense vectors for meaning: "database connection issues" finds RDS Proxy.

03Graph

Traversal

Follows prerequisite and enables edges to pull in the full context.

04Fusion

RRF plus boost

Reciprocal Rank Fusion merges the lists; reinforced memories rank higher.

Keyword search (BM25). Sparse vector matching that finds memories containing the exact terms in your query. Search for "RDS connection timeout" and it finds memories that mention those words. Best for known error messages, service names and specific configurations.

Semantic search (embeddings). Dense vector similarity that finds conceptually related memories even when the wording differs. A search for "database connection issues" finds memories about "connection pooling" and "RDS Proxy setup." Best for exploratory queries and "how do I..." questions.

Graph traversal. When a relevant memory is found, MemGraph follows its prerequisite and enables edges to bring in the surrounding context. Finding "RDS Proxy Setup" also pulls in "VPC Security Group Configuration" (prerequisite) and "Multi-AZ Failover Optimization" (enables). Best for complete context.

The strategies are merged with Reciprocal Rank Fusion (RRF), plus a boost for memories with high reinforcement counts. The agent gets the most relevant, proven knowledge, with its context attached.

---

What it looks like in a conversation

The same question, before and after.

Without MemGraph

You: We're seeing connection timeouts on the orders-api RDS instance

CloudThinker: I'll investigate the RDS connection timeout issue.
              Let me check the current metrics...

              [Runs CloudWatch queries from scratch]
              [Analyzes connection count patterns]
              [Researches possible causes]
              [Eventually identifies connection pooling issue]

              Time to diagnosis: 12 minutes
              Same diagnosis your team did 3 months ago
              Knowledge lost after session ends

With MemGraph

You: We're seeing connection timeouts on the orders-api RDS instance

CloudThinker: MemGraph match: this pattern matches a P1 incident from 3 months ago
              (Lambda-to-RDS connection exhaustion, confidence: high, reinforced 12x)

              Prerequisite: checking whether RDS Proxy is configured...
              It's not. Same root cause.

              Recommended fix (proven procedure):
              1. Deploy RDS Proxy with connection pooling (max_connections_percent=70)
              2. Update Lambda security groups for proxy access
              3. Add CloudWatch alarm on DatabaseConnections metric

              Time to diagnosis: 8 seconds
              Fix validated 12 times across your infrastructure
              Related: also surfacing VPC security group prerequisites

Notice what the second run does before recommending anything: it checks the prerequisite (is RDS Proxy already there?) rather than assuming the old diagnosis still holds. The memory narrows the hypotheses; the evidence still decides.

Where it shows up in production

• Incident memory. From 12-minute diagnosis to 8-second recognition. When a known incident pattern reappears, MemGraph surfaces the proven root cause and fix. The agent learns from every P1 your team resolves.
• Cross-conversation context. Daily summaries and conversation memories carry decisions forward: "The team agreed to freeze spot instance changes until after the SOC2 audit." Nobody re-explains it.
• Personalized operations. Per-user memory files hold communication preferences, priorities and constraints. The agent knows this SRE prefers Terraform, the security lead wants compliance-first framing, and the CTO wants an executive summary.
• Team pattern recognition. MemGraph learns that your platform team uses Helm charts over raw manifests, prefers blue-green over canary, and follows specific naming conventions, and adapts its suggestions to fit.

---

Under the hood: architecture

01Agent tools

Read and write

• search_memoryHybrid search, optional include_related
• create_memoryQueues a memory for the pipeline

Called mid-conversation

02Processing

Celery pipeline

• ExtractHigh-priority workers, 300s timeout
• EmbedCohere Embed v4 on Amazon Bedrock
• EvolveStore, combine or discard
• DedupMD5 content hash, 24-hour TTL

Fully async

03Storage

Four backends

• Qdrant: knowledge graph5 memory types, 7 edge types
• Qdrant: conversationsTopics, decisions, action items
• S3/MinIO: personal contextPer-user files, daily summaries
• Redis: cache1-hour search cache, dedup tracking

Each backend fits one job

MemGraph runs on four storage backends, each picked for one job:

Technical details

Embedding model. Amazon Bedrock Cohere Embed v4 generates both dense vectors (semantic similarity) and sparse vectors (BM25-style keyword matching) in a single API call.

Search algorithm. Reciprocal Rank Fusion combines keyword and semantic results, with a configurable reinforcement boost (5 to 50%) for validated memories.

Processing pipeline. Fully async on a Celery task queue. Memory extraction runs on high-priority workers with 300-second timeouts. Search results are cached in Redis for one hour to avoid repeat computation.

Deduplication. A content hash (MD5 over normalized content) with a 24-hour TTL stops the same knowledge from being stored twice by concurrent agent sessions.

Graph traversal. With include_related=true, search results are enriched by following prerequisite and enables edges, so the full context chain comes back without extra queries.

---

How MemGraph compares

The deeper difference is that MemGraph treats memory as something to maintain, not something to accumulate. Fine-tuning is expensive, batch-oriented and hard to inspect. A vector store grows without judging what it holds. MemGraph evolves in real time, per workspace, with full auditability: you can inspect every memory node, trace every relationship, and see exactly why the agent made a recommendation.

---

The compound effect

Every conversation makes your agents a little better, and the gains stack. The graph starts sparse. After a month of operations, prerequisite chains start to appear. After three months, the evolution pipeline is actively combining related memories and superseding outdated ones. After six months, your agents carry the operational context of a senior engineer who's been on the team from the start.

That's the compound effect: connecting, validating and refining knowledge with every conversation, instead of only remembering it.

---

Getting started

MemGraph is available today for all CloudThinker workspaces. Your agents are already learning from every conversation, building a graph specific to your infrastructure, your team's practices and your operational history. Some things to try:

"What do you remember about RDS connection issues in our account, and which of those fixes has been confirmed more than once?"

"Our team now uses gp3 for every new volume. Remember that, and mark the old gp2 resize procedure as superseded."

"Before you suggest a node group resize for the payments cluster, show me the prerequisites and any conflicting memories."

Related reading

• Resolve
• Introducing CloudThinker Incidents
• Agentic orchestration and context optimization
• What is context engineering?