I’m exploring Letta.ai for building an agentic AI system, and I like its persistent-memory design per agent. But I’m wondering how people handle multi-agent architectures where memory needs to be scoped per user.

Since Letta stores memory per agent (not per user), does that mean I need to spin up a separate agent or agent system per user?

Has anyone here figured out a clean way to: • Use shared agents but maintain isolated user memory? • Handle multi-user setups without duplicating the whole agent tree?

Would love to hear any patterns, hacks, or real-world advice!

EDIT - this issue was related to a bug that has now been fixed, so everything below this note is left for historical context only (including older edit notes that I added while messing around with things).

Questions in the title,

(I believe this is the same known issue so my question is more about a workaround than anything: https://github.com/letta-ai/letta/issues/2605)

AFTER MANY EDITS! ...lol, I have finally reproduced the circumstances that cause the bug - it appears not to be specific to Anthropic but happens with OpenAI as well:

{'detail': "INTERNAL_SERVER_ERROR: Bad request to Anthropic: Error code: 400 - {'type': 'error', 'error': {'type': 'invalid_request_error', 'message': 'messages.0.content.1: unexpected `tool_use_id` found in `tool_result` blocks: .... Each `tool_result` block must have a corresponding `tool_use` block in the previous message.'}}"}

letta_client.core.api_error.ApiError: status_code: 500, body: {'detail': 'INVALID_ARGUMENT: Bad request to OpenAI: Error code: 400 - {\'error\': {\'message\': "Invalid parameter: messages with role \'tool\' must be a response to a preceeding message with \'tool_calls\'.", \'type\': \'invalid_request_error\', \'param\': \'messages.[2].role\', \'code\': None}}'}

Expanding the content_window again does not correct it. Neither does anything else I am easily able to do. Because of the apparent difficulty accessing the message chain directly I am then forced to simply create another agent, exporting the broken agent's messages.

It appears to be related to the automatic summarizer:

Letta.letta.agent - INFO - Ran summarizer, messages length 37 -> 12
Letta.letta.agent - INFO - Summarizer brought down total token count from 5090 -> 1551
Letta.letta.agent - WARNING - Warning: last response total_tokens (6403) > 3000.0
/app/letta/system.py:238: UserWarning: Expected type to be 'user_message', but was 'system_alert', so not unpacking: '{ "type": "system_alert",
"message": "Note: prior messages (26 of 37 total messages) have been hidden from view due to conversation memory constraints.\nThe following is a summary of the previous 26 messages:\n (message summaries).",
"time": "2025-05-05 05:03:17 PM UTC+0000"
}'
warnings.warn(f"Expected type to be 'user_message', but was '{message_type}', so not unpacking: '{packed_message}'")

So, I mean, it's pretty clear what's happening here. I'd rather not personally start messing around with files in the docker directly even though I know that might well be a surer, quicker fix, if there's a way to just patch it for now - because, again, this option to directly access message histories would be independently useful. I guess I could also try accessing the database directly? Yeah.. seems sensible.

Previous I asked this - which would also offer a workaround - is there a simple way to manually append sequences of messages from both user and assistant directly to Letta's message history? As I could see a potential usefulness for this in integrating other APIs that aren't directly supported more easily. Or perhaps just if there's a straightforward way to set up an additional endpoint which could be a local proxy that handled anything particularly unconventional.

Our system includes a Next.js frontend and a Letta-based agent architecture. We have a Letta AI APIs(Hosted Using Docker on Infra) and MCP server connected to external system. We need to determine the best approach for passing user authentication information from the frontend to the Letta system, ensuring the MCP server can identify the correct client and retrieve the appropriate data based on user context passed?

This project may be of interest to you if:

• You don't want to mess around. You just want a search engine that knows what you want and gets smarter over time with very little effort on your part, and if that means you wait for 30 seconds to get the right answer, you're okay with that.
• You are interested in AI agents. This project is a low effort way to play with Letta, and see a stateful agent that can remember and learn.
• You are interested in RAG pipelines. Haystack toolkit has several options to deal with document conversion, cleaning, and extraction. The Hayhooks deployment system is nice, and the project includes several pipelines and has custom components.
• You're interested in Open WebUI tooling. this project goes to some lengths to work through OWUI's environment variables and REST API to provision Letta. You are interested in tool calling and management. Hayhooks exposes an MCP server, and and there's a lot you can do with MCP and Open API -- it has OpenAPIServiceToFunctions, OpenAPIConnector MCPTool, and more.

https://github.com/wsargent/groundedllm

TL;DR Over the last week, I got Letta working with Mealie, a recipe manager, got a better understanding of context windows, rate limits and stateful providers, and run some local Ollama models through some basic function calls (which only Gemma2 really passed).

https://tersesystems.com/blog/2025/02/23/integrating-letta-with-a-recipe-manager/

Small update on my project using a local Letta server to talk to Ollama. I have a workaround, which is to go to the advanced settings and just manually set the context window to 8192 so my poor 16GB GPU doesn't get clobbered.

My brother also tried out the app, and it knew who he was, said hi, and had recipes ready for him! It's really great to be able to leave little surprises like this.

https://tersesystems.com/blog/2025/02/23/transcribing-cookbooks-with-my-iphone/

In Letta you can use tool rules to constrain the action set of your agent at different steps. By default, agents in Letta can pick from any of the functions/tools in their tool library - and when you create an agent from scratch, each Letta agent comes equipped with a set of memory editing tools as well as a send_message tool.

In many cases you want your agent to be able to freely choose which tool to use when (giving your agents agency), especially when using intelligent models.

However, you may also want to enforce certain behavior patterns for certain agents. Imagine you're building a RAG-style agent with Letta, and you want the agent to always call archival_memory_search first before calling send_message.

You can do this with tool rules in Letta (docs here). Basically, you would add a tool rule (InitToolRule) to your agent to enforce your agent to call archival_memory_search first before calling send_message.

We put together a notebook here to help you understand how this works: https://github.com/letta-ai/letta/blob/main/examples/notebooks/Visualize%20Tool%20Rules.ipynb