Agent Memory in Rust: Persistence and Retrieval Choices

Rust's ownership model and explicit memory management make it a good choice for agent infrastructure that must be efficient and predictable. It also means the developer makes every storage choice deliberately: there is no hidden garbage collection or implicit persistence. For AI agent memory, that explicitness is an advantage.

A Rust agent application handles the same three memory categories as any other language: conversation state for the current session, retrieved reference material for answering specific questions, and durable project context that outlasts any run. Tools like fenbs serve the third category as a shared record any connected tool can read, without requiring it to live inside the Rust application.

Conversation state in Rust agents

Conversation state is a sequence of messages you pass to the language model API with each call. In Rust, this is a Vec<Message> or equivalent, where each message has a role (system, user, or assistant) and content. You append new messages after each turn and pass the full list to the next API call.

Managing context window size is the main ongoing task. The context window is the maximum amount of text the model can process in one call. As the message list grows, you must remove or summarize older messages to keep within the limit. Implement the trimming logic as a function that takes the message list and a token budget and returns a list that fits.

Serializing the message list to JSON or a database row at the end of a session and deserializing it at the start of the next is the straightforward persistence pattern. Test the round-trip: serialize, restart the process, deserialize, and confirm the messages are intact.

Retrieval in Rust agents

Retrieval is a read operation that fetches relevant content before or during a model call. In Rust, this typically means calling an external service: a vector database like Qdrant via HTTP, a relational database via a Rust client crate, or a custom index. The Qdrant Rust client is well maintained and supports the full Qdrant API.

Keep retrieval calls async. Rust's async ecosystem, primarily through Tokio, handles concurrent retrieval operations efficiently. If the agent needs to query multiple sources before each model call, running them concurrently reduces latency.

Async retrieval with Tokio

Rust's async ecosystem, primarily built on Tokio, handles concurrent retrieval well. If the agent needs to query multiple memory sources before a model call, running those queries concurrently reduces the time spent waiting. Use tokio::join! for a fixed set of concurrent queries, or tokio::task::JoinSet when the number of queries is determined at runtime.

Handle retrieval errors explicitly. Rust's Result type forces you to decide what to do when a retrieval call fails. The right behavior depends on the context: a failure retrieving recent task state might warrant stopping the session, while a failure retrieving an optional context note might be acceptable to skip and log. Make that decision in code, not by panicking. Logging the failure with enough detail to diagnose it later is more useful than a generic error message.

Durable context and project records

Durable context is the project's agreed decisions, standing rules, active tasks, and progress. This is not agent state: it does not change with each model call. It changes when a person makes a decision or a task is completed. It must survive process restarts, application rewrites, and model changes.

Storing durable context inside the Rust application, even in a database, makes it private to that application. Another tool, a teammate, or a different agent cannot read it without access to your deployment. The right approach is an external record with a standard connection interface.

Validation

Validate memory at each boundary. When loading conversation state from a store, confirm the deserialized messages match expected types and that no required fields are missing. When writing retrieved content to the context, check that it came from the intended source and that the retrieval was not empty.

Rust's type system makes structural validation straightforward: deserialization into a well-defined struct catches shape errors at compile time or on first parse. Semantic validation (is this content correct for this query?) requires test cases, not type checking. Write at least one integration test per memory boundary that uses realistic data, since edge cases in serialization and retrieval often surface only with content that resembles real agent output.

For patterns that apply across languages, see how to build agent memory and agent memory vs RAG.

How to do this with fenbs

1. Create a free account and add the project your Rust agent supports.
2. Add the decisions, standing rules, and active tasks to fenbs. These are the durable facts every session needs.
3. In your Rust agent, implement an MCP client that calls the fenbs endpoint at Integrations to load project context before the first model call.
4. At session end, write completed work and remaining steps back to fenbs via the same MCP connection.
5. Test the startup sequence: stop the process, restart it, and confirm the agent loads the correct context from fenbs before proceeding.

For the MCP protocol that the fenbs connection uses, see agent memory MCP. For security considerations specific to what agent memory stores, see agent memory security.