Your Agent's Memory Is a Graph Problem (You Probably Built a Vector One)

A customer opens a chat and asks why their last invoice went up. Two weeks earlier, in a different session, that same customer had downgraded their plan. The agent has memory. It even retrieves something useful looking: three past messages where the customer discussed billing, all of them warm and on topic, every one of them from before the downgrade. The agent answers with full confidence, using the old plan. The customer corrects it. Trust drops a notch, and nobody logs why.

I have watched a version of this play out more than once, and the postmortem always lands in the same spot. The memory worked exactly as designed. That was the problem.

Most agent memory today recalls by similarity. You store past interactions as vectors, and at recall time you fetch the ones that sit closest to the current question. That works beautifully when the memory you need is the one that resembles what is being asked. It comes apart when the memory you need is the single fact that changed. "The customer downgraded" is not semantically louder than "the customer asked about billing." It is only newer, and tied to a different state. Similarity has no opinion about which one matters.

The questions that break vector memory have a shape to them. What did this user decide, and what has changed since? Who else is wired into this account, and does that move the answer? These are not similarity questions. They are questions about relationships and about time, and you answer them by walking edges, not by measuring distance.

That is why, when a team tells me their agent keeps forgetting what matters, I do not open with what model they run or how large their context window is. I ask what their memory is shaped like. On AWS there are three honest answers to that question, and most teams end up with the one that was easiest to wire rather than the one that fits what they are asking. The rest of this piece is about telling those three apart, and knowing which one you actually need before you commit.

Take the three in the order teams usually reach for them, easiest first.

The closest thing to hand is Amazon Bedrock AgentCore Memory. It is the managed option and it is good at its job. Short-term memory keeps the raw turns of a session as events. Long-term memory runs an asynchronous job that reads those events with a large language model (LLM) and pulls out durable records: preferences, facts, session summaries. You choose strategies, you get back consolidated insights under a namespace. What you do not get is a graph. AgentCore Memory can remember that a customer prefers email over phone. It cannot walk from that customer to the three accounts they administer to the contract that lapses next month in a single query. It was not built for that, and forcing it there is effort you will resent later.

The second thing people grab is GraphRAG inside Bedrock Knowledge Bases. This one actually is a graph, which is exactly why it gets dragged into memory discussions by mistake. The graph it builds is over your documents. During ingestion the pipeline splits each file into chunks, embeds them, runs an LLM to extract entities, and writes chunk, document, and entity nodes into Amazon Neptune Analytics. At query time it blends vector similarity with graph traversal, so a question that has to connect facts spread across several documents lands better than plain vector search would. That is a real capability and I reach for it. It is still the wrong tool for memory, for a reason the marketing skips over: the graph describes a corpus, not a conversation. You refresh it with a sync job when the documents change. It does not accumulate what the agent learns about a person, turn by turn, the way memory has to.

One constraint to flag before you design around GraphRAG: it is gated to a shorter list of regions than its own dependencies, and that gap bites if you operate under data-residency rules. I come back to it in the next section.

The third option, and the real subject of this piece, is graph memory: Mem0 backed by Amazon Neptune Analytics. Here the graph is the agent's own accumulated memory. Not a document corpus, not a managed summary. Mem0 owns the lifecycle, extracting structured facts from interactions, storing them, retrieving them, while Neptune Analytics holds the entities and relationships as a graph you can traverse. Because it is a graph, recall can run several hops: from a user, to what they decided, to what changed since, to who else is wired into that decision. Mem0's graph extension does hybrid retrieval across graph, vector, and keyword, so you are not made to choose between relationship reasoning and similarity. It runs on AgentCore Runtime and has been demonstrated with Strands agents, which means it slots into the same agentic stack you are already deploying. And it is not a lab demo. TrendMicro put this exact pairing into production, with Neptune holding the organizational knowledge graph and Mem0 handling recall across sessions.

So I do not start from the product. I start from the question the agent has to answer. Durable preferences and summaries, with the least operational weight possible? AgentCore Memory earns its keep. Grounding answers in a fixed body of documents where the links between them carry meaning? That is what GraphRAG's graph is for. But when the thing you have to remember is a web of entities and relationships that keeps growing and rearranging itself across sessions, and the questions worth asking walk several steps along that web, you need a graph that is yours to write to. On AWS today, that graph is Mem0 on Neptune Analytics.

Two things about this stack do not show up in the "a few clicks" walkthroughs, and both of them find you in production rather than in the demo.

The first is regional, and it caught me off guard. The standard line is that GraphRAG is available wherever Bedrock Knowledge Bases and Neptune Analytics both run. That sounds like a clean rule, so I treated it as one. It is not how the service behaves. GraphRAG carries its own region allow-list, and that list is shorter than either of its dependencies. As I write this, GraphRAG runs in seven regions: North Virginia, Oregon, Ireland, London, Frankfurt, Tokyo, and Singapore. Knowledge Bases runs in more than twenty. Neptune Analytics, after its January 2026 expansion, runs in São Paulo and a dozen more. And yet São Paulo is not on the GraphRAG list. Both services underneath the feature are live in sa-east-1, and GraphRAG still will not turn on there.

For anyone building under a data-residency requirement in Brazil, that is not a footnote. The managed GraphRAG path is closed to you in-region today, which leaves two real choices: run the knowledge base in a region where GraphRAG is allowed and accept that your data crosses a border, or stand up the graph yourself in São Paulo and give up the managed convenience. Neither is wrong. Both are calls you want to make on purpose, before a compliance reviewer makes them for you. Check the GraphRAG region page on the day you design, because this list moves, and the gap I am describing may have closed by the time you read this.

The second thing the walkthroughs gloss is cost, and the phrase doing the glossing is "no additional charges beyond the underlying services." That sentence is true, and it is also a misdirection, because the underlying service here is not a per-request vector store. The graph lives in Amazon Neptune Analytics, which holds your graph in memory and bills by capacity, not by query. The unit is the m-NCU, the memory-optimized Neptune Capacity Unit, and one m-NCU is one gigabyte of memory with matching compute for one hour. You provision capacity, and you pay for it the whole time the graph is running, whether you hit it a thousand times that hour or never.

That changes how you reason about a quiet knowledge base. A vector store that scales toward zero when idle costs you almost nothing between questions. A Neptune Analytics graph does not behave that way. Its lever is pause, which drops you to roughly ten percent of compute while keeping the data intact, not an automatic scale to nothing. Neptune Serverless, the thing people assume covers this, applies only to Neptune Database, not to the Analytics engine that GraphRAG runs on. A knowledge base that fields a handful of questions a day can still carry a resident memory bill around the clock unless you build pausing into how you operate it.

One smaller line deserves a mention. Building the graph is not free compute either. During ingestion, GraphRAG runs an LLM over every chunk to pull out entities before anything reaches Neptune. On a large corpus that is real model spend stacked on top of embeddings, and it returns each time you re-sync. How much of that extraction repeats on an incremental sync versus a full rebuild is the one number I could not pin down in the documentation, so if your corpus changes often, measure it before you call it cheap.

I want to spend a paragraph arguing against the rest of this article, because the failure mode that produced it has a twin going the other way. For every team that underbuilds memory with a vector store, there is one that reaches for a graph because graphs are interesting, and pays for infrastructure a simpler design would have avoided.

If your agent only needs the last several turns of the current conversation, you do not need any of this. Short-term memory, a buffer held in the session, covers it completely. Adding a graph there buys you nothing and hands you a database to run.

If what you call memory is really a handful of durable preferences and the occasional session summary, and you never have to walk from one fact to another, AgentCore Memory's managed long-term memory is plenty. You do not have to own a Neptune graph to remember that a user prefers metric units.

The sharpest version of the rule is this. If the relationship you care about already lives in a table with a foreign key, query that table. A customer-to-account mapping that your billing system holds as authoritative truth should be read from the billing system, not reconstructed by running an LLM over support transcripts and hoping the extraction came out right. Deterministic data deserves a deterministic lookup. Graph memory earns its keep when the relationships are emergent, accumulated turn by turn from unstructured interaction, and not already written down somewhere you could join against. Reach for it when a join against the tables you already have cannot answer the question, and not one step before.

Agent memory is a design decision you make before you pick a product, and it turns on one question: what is the shape of what your agent has to remember? Similarity is honest work for a vector store. Durable preferences with little traversal sit fine in AgentCore Memory. But a web of entities and relationships that grows, shifts, and has to be walked is graph memory, and on AWS that path runs through Mem0 on Neptune Analytics, with the regional and cost edges I laid out above. Get the shape right and the tool picks itself. Get it wrong and you ship an agent that remembers everything except the fact that mattered.

I am an AWS Solutions Architect with almost 15 years in cloud, focused on production ML and GenAI workloads for regulated organizations. I hold every active AWS certification, including the Generative AI Professional as an Early Adopter, the status AWS calls Golden Jacket. I am the sixth Brazilian Golden Jacket holder in the AWStronauts Global Map and co-founder of Golden Jackets Brazil.