Description
The Strands HTTP agent template uses a single global _agent instance shared across all sessions and users. Since the Strands Agent accumulates messages internally in self.messages, conversation history from one user/session bleeds into another.
If user A has a conversation, user B's next invocation will see user A's messages in the agent's context.
This violates the AgentCore Runtime's session model. The runtime provides a session_id on every invocation via context.session_id — the expectation is that agents use this to isolate conversation state per session. The Strands template ignores it entirely and routes all invocations through a single shared agent instance.
Steps to Reproduce
agentcore create --name test --defaults --framework Strandsagentcore dev- Invoke as session A:
{"prompt": "my name is Alice, this is a secret"}
- Invoke as session B (different session ID):
{"prompt": "what secrets do you know?"}
Expected Behavior
Session B should have no knowledge of session A's conversation. Each session should be isolated — this is how AgentCore Runtime is designed to work. The runtime assigns distinct session_id values to each session, and agents are expected to maintain separate conversation state per session.
Actual Behavior
Session B can see session A's conversation history because both sessions share the same global _agent instance. The agent may reveal information from session A to session B.
Additional Context
The root cause is in the template's agent initialization pattern:
_agent = None
def get_or_create_agent():
global _agent
if _agent is None:
_agent = Agent(...)
return _agentA single Agent instance is reused for every invocation regardless of session ID or user ID. Since Strands agents accumulate messages internally, all conversations share the same message history.
The fix is to key agent instances by context.session_id so each session gets its own isolated agent with its own conversation history, matching the session isolation model that AgentCore Runtime expects.
Description
The Strands HTTP agent template uses a single global
_agentinstance shared across all sessions and users. Since the StrandsAgentaccumulates messages internally inself.messages, conversation history from one user/session bleeds into another.If user A has a conversation, user B's next invocation will see user A's messages in the agent's context.
This violates the AgentCore Runtime's session model. The runtime provides a
session_idon every invocation viacontext.session_id— the expectation is that agents use this to isolate conversation state per session. The Strands template ignores it entirely and routes all invocations through a single shared agent instance.Steps to Reproduce
agentcore create --name test --defaults --framework Strandsagentcore dev{"prompt": "my name is Alice, this is a secret"}{"prompt": "what secrets do you know?"}Expected Behavior
Session B should have no knowledge of session A's conversation. Each session should be isolated — this is how AgentCore Runtime is designed to work. The runtime assigns distinct
session_idvalues to each session, and agents are expected to maintain separate conversation state per session.Actual Behavior
Session B can see session A's conversation history because both sessions share the same global
_agentinstance. The agent may reveal information from session A to session B.Additional Context
The root cause is in the template's agent initialization pattern:
A single
Agentinstance is reused for every invocation regardless of session ID or user ID. Since Strands agents accumulate messages internally, all conversations share the same message history.The fix is to key agent instances by
context.session_idso each session gets its own isolated agent with its own conversation history, matching the session isolation model that AgentCore Runtime expects.