How to use a ConversationManager in a MultiAgent Graph (in an AgentCore context)

[mustafashabib]

Hey all -

I'm building a MultiAgent graph and wanted to understand what the best practice was to use a ConversationManager in the context of AgentCore. My agent application is a chat experience where the orchestrator graph delegates questions as appropriate and synthesizes the final response. It's unclear to me how Strands ConversationManager should or should not be used in this set up, particularly when I have AgentCore memory and memory tools in play. For example, should the AgentCore memory tools be passed to every agent in the graph? Should a ConversationManager be used in any of the agents in the graph? Is the AgentCore SessionMemory enough to handle conversation management?

Thanks for any guidance - been struggling to find a simple example that interleaves the variety of tools in use.

Mustafa

[yonib05]

Hey @mustafashabib, this trips up a lot of people because the two features sound alike but solve different problems, so it's a good question. Sorry we're only getting to it now.

A ConversationManager manages context window size: it trims or summarizes a single agent's own message list so what goes to the model stays under the token limit. AgentCore Memory is about persistence and recall: keeping conversation state across invocations and retrieving long-term facts. Neither replaces the other, so "is SessionMemory enough" depends on which problem you mean. It handles durability, not context size.

For the graph itself: every Strands agent already runs a SlidingWindowConversationManager by default, so all your nodes are covered without doing anything. Only tune where real history accumulates. In your setup that's the orchestrator carrying the chat, and SummarizingConversationManager is worth a look there if conversations run long. Worker nodes that just receive a delegated task and answer rarely need attention here.

Same logic for the AgentCore memory tools: no need to hand them to every node. Give them to the agents that actually need to recall user context, typically the orchestrator or whichever node personalizes the answer. Extra tools on worker nodes just add tool-selection noise.

One constraint to know: agents inside a Graph must not have their own session manager. Python raises a ValueError if you try. Persistence attaches at the graph level via GraphBuilder.set_session_manager instead, and today only the file and S3 session managers support multi-agent persistence. The AgentCore memory session manager doesn't yet, so in a Graph the way to use AgentCore Memory is through the memory tools as described above, not as a session manager. Docs worth skimming: conversation management, session management, graph. If anything's still fuzzy after that, follow up here and we'll dig in.