Best practice for handling per-user chat history with DI in agent-based REST APIs

[ahmar-husain]

I’m working on an agent-based system where a REST endpoint invokes an AI agent, and subsequent requests for the same user need to be context-aware by leveraging stored conversation history.

Current Design

• I have implemented a custom ChatHistoryProvider backed by Redis to store and retrieve chat history per user.
• I created an AgentFactory that returns an AI agent instance.
• The factory is registered with scoped lifetime in DI.

Challenge

• I ended up using a factory pattern to pass userId during agent creation.
• This makes the design feel a bit forced and less aligned with standard DI practices.
• On every new request, a new agent instance is created via the factory ,The conversation history is then rehydrated from Redis for that user/session

What I’m Trying to Understand

• Is This the recommended pattern for handling runtime values like userId in services such as chat history providers?
• Is this stateless agent per request + history rehydration the expected/recommended pattern in agent-based systems?
• Or should an agent instance be long-lived per conversation/session (e.g., cached or stored), instead of recreated on each request?

Take a loot at my redis history provider and factory class below

RedisChatHistoryProvider.txt
ShipmentAgentFactory.txt

Additional Context (Current Invocation Pattern)

From my REST endpoint, this is how I’m currently invoking the agent:

     var agent = agentFactory.Create(userInput, conversationId);
     var session = await agent.CreateSessionAsync();
     var response = await agent.RunAsync<ContainerAgentResponse>(userInput, session);
     return JsonSerializer.Deserialize<ContainerAgentResponse>(response.Text)!;

[jluocsa]

Great question — the design you've landed on is actually very close to the framework's intended pattern, but the framework has a first-class hook for exactly this scenario that lets you drop the factory altogether. Walking through your three questions:

1. The agent should be a singleton, not per-request

AIAgent instances are designed to be stateless and long-lived. All of the AddAIAgent overloads in Microsoft.Agents.AI.Hosting default to ServiceLifetime.Singleton for that reason — see AgentHostingServiceCollectionExtensions.cs:

public static IHostedAgentBuilder AddAIAgent(
    this IServiceCollection services,
    string name,
    string? instructions,
    ServiceLifetime lifetime = ServiceLifetime.Singleton) { ... }

So you don't need a factory keyed on userId — the per-user / per-conversation thing isn't the agent, it's the session.

2. The conversation state belongs in an AgentSessionStore

This is the piece you're rebuilding by hand. The framework has an abstract AgentSessionStore (AgentSessionStore.cs) that is purpose-built for "load/save a conversation by id, across requests":

public abstract class AgentSessionStore
{
    public abstract ValueTask SaveSessionAsync(AIAgent agent, string conversationId, AgentSession session, CancellationToken ct = default);
    public abstract ValueTask<AgentSession> GetSessionAsync(AIAgent agent, string conversationId, CancellationToken ct = default);
}

There's an in-memory implementation for dev (InMemoryAgentSessionStore) whose own XML doc says:

For production use with multiple instances or persistence across restarts, use a durable storage implementation such as Redis, SQL Server, or Azure Cosmos DB.

The pattern it uses is the one to copy verbatim for Redis:

public override async ValueTask SaveSessionAsync(AIAgent agent, string conversationId, AgentSession session, CancellationToken ct = default)
{
    var key = $"{agent.Id}:{conversationId}";
    _redis[key] = await agent.SerializeSessionAsync(session, cancellationToken: ct);   // JsonElement -> Redis
}

public override async ValueTask<AgentSession> GetSessionAsync(AIAgent agent, string conversationId, CancellationToken ct = default)
{
    var key = $"{agent.Id}:{conversationId}";
    return _redis.TryGet(key, out var json)
        ? await agent.DeserializeSessionAsync(json, cancellationToken: ct)
        : await agent.CreateSessionAsync(ct);   // first turn -> fresh session
}

SerializeSessionAsync/DeserializeSessionAsync are on AIAgent itself (AIAgent.cs) and they round-trip the entire session state — chat history, tool state, any AgentSessionStateBag entries — through a single JsonElement. So your store just stores JSON; you don't need a separate ChatHistoryProvider to do it.

3. Wire it up via WithSessionStore on the hosted agent builder

This is what makes the factory go away. HostedAgentBuilderExtensions.WithSessionStore registers the store as a keyed singleton bound to the agent name:

// Program.cs
builder.Services.AddSingleton<IConnectionMultiplexer>(_ => ConnectionMultiplexer.Connect(redisConnString));

builder.AddAIAgent(
        name: "shipment",
        instructions: "...",
        chatClientServiceKey: "chat-model")
    .WithSessionStore((sp, agentName) => new RedisAgentSessionStore(sp.GetRequiredService<IConnectionMultiplexer>(), agentName));

Then your endpoint becomes pure DI — no factory, no per-request agent construction:

app.MapPost("/shipment/{conversationId}", async (
    string conversationId,
    [FromBody] ContainerRequest userInput,
    [FromServices] AIAgent agent,                                    // singleton
    [FromKeyedServices("shipment")] AgentSessionStore sessions,      // singleton, keyed
    CancellationToken ct) =>
{
    var session  = await sessions.GetSessionAsync(agent, conversationId, ct);
    var response = await agent.RunAsync<ContainerAgentResponse>(userInput.Text, session, ct);
    await sessions.SaveSessionAsync(agent, conversationId, session, ct);
    return Results.Ok(JsonSerializer.Deserialize<ContainerAgentResponse>(response.Text));
});

The conversationId is just an opaque string — if you want strict per-user isolation, build it as $"{userId}:{topic}". The store namespaces by agentId:conversationId internally so multiple agents in the same app don't collide.

So, mapping back to your three questions

Your question	Recommended answer
Is passing userId via a factory the right way?	No — push that data into the conversation id the endpoint receives, and let DI hand you a singleton agent + a keyed AgentSessionStore.
Is stateless-agent + history-rehydration correct?	Yes, that's exactly the design. Just use AgentSessionStore instead of a custom ChatHistoryProvider as the rehydration boundary.
Should agents be long-lived per conversation?	No — agents are singletons. Sessions are the per-conversation thing, and they live in the store.

Bonus: if you'd rather keep ChatHistoryProvider

There's also a separate ChatHistoryProvider extensibility point hung off ChatClientAgentOptions — useful if you want the agent itself to own message persistence (e.g. for server-side responses APIs). Microsoft.Agents.AI.CosmosNoSql ships WithCosmosDBChatHistoryProvider as a reference implementation — a RedisChatHistoryProvider would follow the same shape. But for the REST scenario you described, AgentSessionStore is the cleaner fit.