Python: Session isolation does not work as expected for workflow-as-agent deployments in App Service / Container Apps

[cs609]

We are deploying a workflow created with Microsoft Agent Framework as an agent behind an HTTP endpoint on Azure App Service / Azure Container Apps, so multiple users can chat with the same deployed agent.
We are trying to implement per-user session handling based on the documentation and sample below:
• Documentation: https://learn.microsoft.com/en-us/agent-framework/agents/conversations/session?pivots=programming-l…
• Sample: https://github.com/microsoft/agent-framework/blob/main/python/samples/03-workflows/agents/workflow_…
Our goal is that each user has an isolated conversation session, with memory preserved only for that user across messages.
What we tried:

1. Shared workflow/agent instance for all users
   • We build the workflow once when the App Service starts.
   • That workflow-as-agent instance is shared by all users.
   • When User A starts chatting, we create a session and use that session ID for User A’s subsequent messages.
   • When User B starts chatting, we create a different session ID and use that for User B’s subsequent messages.
   • Expected result: memory should remain isolated per session/user.
   • Actual result: memory appears to be shared across users.
2. Rebuilding the workflow for every message / every user
   • We create the workflow/agent again for each message or user interaction.
   • We still use the same session ID for the user’s subsequent messages.
   • Expected result: user memory should persist within that session.
   • Actual result: memory is not preserved when the workflow is recreated each time.
   What we need clarification on:
   • What is the correct deployment pattern for workflow-as-agent when serving multiple concurrent users through a single HTTP endpoint?
   • Is the workflow/agent instance supposed to be shared across users, with session state handled internally by session ID?
   • Or should a separate workflow/agent instance be maintained per user/session?
   • If the workflow can be shared, what is the correct way to ensure memory isolation between sessions?
   • If the workflow must not be recreated per request, what object needs to remain alive for session memory to work correctly?
   In short, we are unable to achieve both of the following at the same time:
   • isolated memory per user/session
   • preserved memory across that user’s subsequent messages
   Could you please provide guidance on the recommended architecture for multi-user session handling for workflow-as-agent deployments in a web app / containerized endpoint scenario?

[moonbox3]

Hi @cs609, thanks for the detailed write-up. The behavior you're seeing is consistent with how Workflow and AgentExecutor are designed today, and it's documented (a bit obliquely) in the Workflow docstring: "Workflow instances contain states and states are preserved across calls to run. To execute multiple independent runs, create separate Workflow instances via WorkflowBuilder."

Concretely:

1. A Workflow instance is single-tenant and not concurrency-safe. It carries a runner, runner context, and state; calling run() while another run() is in flight on the same instance raises RuntimeError: Workflow is already running. Concurrent executions are not allowed. This is a per-instance guard inside one Python process — multi-worker deployments (for example, multiple gunicorn/uvicorn workers, multi-instance App Service plans) won't trip the flag across workers, but each worker still ends up with the per-user state-leak problem in Adding Microsoft SECURITY.MD #2 below. So a "single shared workflow for all users" pattern is not safe under any real concurrency model.

2. AgentExecutor binds one session at construction time (self._session = session or agent.create_session()) and reuses it for every inner agent.run(...) call. The AgentSession you pass to WorkflowAgent.run(session=...) is only consumed at the WorkflowAgent layer (to prepend prior turns to the input messages and to persist the new turn afterwards). It is not threaded down to the executors. So even if you supply a per-user session at the top, the inner agents are all writing/reading from the workflow-instance-scoped session — that's the cross-user memory you're seeing.

   The exact leak mechanism depends on the storage backend, but the outcome is the same:

   • Local/in-memory (default): InMemoryHistoryProvider is auto-injected on the executor's session and accumulates every user's turn in session.state["messages"].
   • Service-managed (Azure Foundry threads, OpenAI conversations with store=True): the executor's session carries the service_session_id/conversation_id, so all users share the same server-side thread.

3. AgentSession is just a serializable state bag. It has no implicit persistence — if you rebuild the workflow per request and don't session.to_dict() / AgentSession.from_dict() between turns, the user history is gone. Reusing the same session_id string alone does not preserve state.

Our current recommended pattern for multi-user HTTP/container deployments:

Build a Workflow per request (or cache one per user) and persist the user's AgentSession externally. This is the only pattern today that gives you both per-user isolation and per-user memory:

# On request:
# 1) Look up or create the user's persisted session.
raw = await session_store.get(user_id)  # e.g. Redis/DB/blob
session = AgentSession.from_dict(raw) if raw else AgentSession(session_id=user_id)

# 2) Build a fresh workflow + agent for this request.
workflow = SequentialBuilder(participants=[assistant, summarizer]).build()
agent = workflow.as_agent()

# 3) Run with the user's session.
response = await agent.run(user_message, session=session)

# 4) Persist the updated session back to your store.
await session_store.set(user_id, session.to_dict())

Notes:

• WorkflowAgent will auto-attach an InMemoryHistoryProvider on the first call when you pass a session and no provider is registered, and it persists the response into session.state after the run. So to_dict()/from_dict() is the right boundary.
• If construction cost is a concern, you can cache one workflow per user in process memory (keyed by user/session id) instead of rebuilding per request — but you must still avoid concurrent run() calls on the same workflow instance, and you'll need an eviction policy.
• For long-running flows or pause/resume (HITL, etc.), use checkpoint_storage and checkpoint_id on agent.run(...) — the workflow's execution state can be persisted out and restored on a fresh instance.
• The chat-client agents (assistant, summarizer in your example) themselves are safe to share across users, because the per-turn history flows through the session you pass in. Cross-user leakage today comes from the AgentExecutor's captured session, not from the agents you author.

We'll take this back as a docs gap (the workflow-as-agent guide should call out the deployment model explicitly) and as a design question on whether WorkflowAgent.run(session=...) should propagate the caller's session into AgentExecutor so that a shared workflow could be used in multi-user scenarios. For now, the per-request build + external session persistence pattern above is what we recommend.

[kinthaiofficial]

Session isolation for multi-user agent deployments: common pitfalls

We run 31 agents behind a single HTTP endpoint serving multiple user groups at KinthAI (built on OpenClaw, but the session isolation challenges are identical to what you describe with Agent Framework on Azure).

The three levels where session isolation breaks:

1. Chat history leakage (the obvious one)
User A's conversation messages appearing in User B's context. This is usually a bug in the session store — the session ID is not being correctly scoped to the user.

Our fix: composite session keys: {agent_id}:{user_id}:{channel_id}. A single user_id key is not enough if the same user talks to the agent through different channels (web, API, etc.).

2. Memory/state leakage (the subtle one)
Even with proper chat history isolation, if your agents use persistent memory or state, one user's facts can leak to another via:

• Shared memory store without user-scoped namespacing
• Vector similarity search that ignores user boundaries (the vector DB returns the closest match regardless of who stored it)
• Shared workspace files that are modified by one user's session and visible to another

Our fix: namespace everything by user: memory/{user_id}/, state files in workspace/{user_id}/, and vector store collections per user (not just a user_id filter on a shared collection).

3. Model context contamination (the hardest one)
If two users send requests concurrently and your framework processes them in the same event loop, one request's system prompt or tool results can bleed into another's context. This is a race condition in the message assembly pipeline.

Our fix: per-request deep copy of the agent config and message history before building the LLM request. No shared mutable state in the request path.

For Azure App Service specifically:
The container restart/scale-out pattern can also break session isolation if sessions are stored in-memory (not externalized). When a new instance spins up, it has no session state. Use Redis or a database-backed session store, not in-process memory.

Related architecture: OpenClaw Multi-Tenancy: Why VM-Per-User Does Not Scale

[cs609]

@moonbox3
We appreciate the recommendation. We followed your suggested approach of constructing a Workflow for each request and it works seamlessly. For state management, we are persisting the AgentSession in Azure Blob Storage and appending to the workflow object as needed during the request lifecycle.

While this is currently operating successfully via a custom endpoint, our roadmap includes integrating this workflow with CopilotKit and AG-UI. Could you share your thoughts on the feasibility of this integration? We are particularly interested in knowing if you anticipate any challenges connecting CopilotKit/AG-UI to a backend that handles session state and streaming in this custom manner.