Mastra•2d ago

Shared conversation memory vs agent-private memory in Mastra

Hi I have a question about memory design in Mastra.

I'm building a multi-agent group chat:

multiple agents in the same conversation

agents should share the same conversation context

each agent should still have its own private state

From my experiments:

Memory seems to be agent-scoped

Mastra only supports one storage backend

once storage is set on Mastra, agents can't have separate storage

using a shared memory leads to identity confusion (agents repeating each other)

My questions:

Is Mastra Memory intended more for agent state rather than conversation history?

Is there a recommended way to support shared conversation context + agent-private memory?

For group chat, is it expected to manage conversation storage outside Mastra and use Mastra mainly as an agent runner?

Thanks!

_roamin_•12/15/25, 7:17 PM

Hey @yongyang599 ! How are you calling your agents currently? Do you have an orchestrator/router agent that calls the other agents based on the user prompt? Or the user decides which agent to call?

When you call agent.stream/agent.generateagent.stream/agent.generate you decide what is the the thread id and resource id the agent is going to have access to, so it will be the history tied to that thread id.

What do you want your agent to have access to? The whole thread + its own memory/history?

Sebastian•12/15/25, 9:17 PM

I did some experimentation on this myself.
As far as I understand it you can use threadIdthreadId and resourceIdresourceId to automatically retrieve conversation history when running an agent as well as automatically store new messages from this agent in that conversation history (there's also a readOnlyreadOnly mode for memory that you can configure per agent run).
So if you want to break out of this default, the best way would be to manually use threadIdthreadId and resourceIdresourceId to retrieve the relevant history and provide that as input messages to each agent you want to run individually.
If you want to prevent identity confusion that should at least help in exactly controlling where each agent starts off in terms of memory.
The more interesting question is how updates to a conversation are stored in the conversation history.

Sebastian•12/15/25, 9:17 PM

One way to implement this would be an agent network where one agent is the mediator the user actually chats with while he is able to consult other agents without directly contributing to the conversation history.
If your problem is primarily agents repeating information that was already stated in the conversation you might be able to suppress that using presencePenaltypresencePenalty and frequencyPenaltyfrequencyPenalty that you can finetune using the modelSettings.
You could also use the same threadIdthreadId and different resourceIdsresourceIds per agent to isolate their memory from each other but have a mutual identifier to load the whole thread with the conversation history from all agents involved in the conversation.
But you would need to store and retrieve the relevant resourceIdsresourceIds and the threadIdthreadId on your own as Mastra doesn't handle that scenario out of the box.
One last idea that might help is to let the agents involved know that they are part of a group conversation and their memory includes messages from multiple agents. But for that to work properly you might have to additionally annotate messages to identify which of the agents authored which message to guarantee a stable identity when an agent interprets that conversation history.

Sebastian•12/15/25, 10:31 PM

Another thought: when you run an agent, besides memory and input messages you can also provide messages via

context

context

I didn't look into what difference exactly that makes, but you could try only providing the messages that belong to that specific agent via input messages or memory and provide the other agents messages as context to differentiate between them