[FEATURE] Optimize session manager initialization

[Unshure]

Problem Statement

I would like to optimize the session manager so that it doesnt call get_agent if the session does not already exist. This will reduce the number of api calls needed by the underlying session repository.

Proposed Solution

Add a flag during session manager initialization that skips get_agent call during agent init if the session doesnt already exist

Use Case

reduce number of api calls needed by session manager

---

Implementation Requirements

Based on repository analysis and clarification discussion:

Overview

When a new session is created in RepositorySessionManager.__init__, we know with certainty that no agents can exist in the session yet. The subsequent read_agent() calls in initialize(), initialize_bidi_agent(), and initialize_multi_agent() will always return None, making them unnecessary API calls.

This optimization eliminates redundant S3 GetObject calls (for S3-backed sessions) or filesystem I/O operations (for file-backed sessions).

Technical Approach

Add _is_new_session flag in RepositorySessionManager:

class RepositorySessionManager(SessionManager):
    def __init__(self, session_id: str, session_repository: SessionRepository, **kwargs: Any):
        # ... existing code ...
        session = session_repository.read_session(session_id)
        if session is None:
            self._is_new_session = True  # NEW: Track new session state
            session = Session(session_id=session_id, session_type=SessionType.AGENT)
            session_repository.create_session(session)
        else:
            self._is_new_session = False  # Session existed, agents may exist
        # ... rest of init ...

Update initialization methods to check flag:

In initialize(), initialize_bidi_agent(), and initialize_multi_agent():

• If self._is_new_session is True, skip the read_agent()/read_multi_agent() call
• Directly proceed to create the agent/multi-agent
• The flag remains True for the session's lifetime (agents can't pre-exist in a new session)

Files to Modify

File	Changes
src/strands/session/repository_session_manager.py	Add _is_new_session flag and update initialize(), initialize_bidi_agent(), initialize_multi_agent() methods
tests/strands/session/test_repository_session_manager.py	Add tests for optimization behavior

Acceptance Criteria

• RepositorySessionManager.__init__ sets _is_new_session = True when creating a new session
• RepositorySessionManager.__init__ sets _is_new_session = False when using an existing session
• initialize(agent) skips read_agent() call when _is_new_session is True
• initialize_bidi_agent(agent) skips read_agent() call when _is_new_session is True
• initialize_multi_agent(source) skips read_multi_agent() call when _is_new_session is True
• Existing behavior preserved when _is_new_session is False (session already existed)
• Unit tests cover both new and existing session scenarios
• All existing tests continue to pass

Design Notes

• The _is_new_session flag remains True for the entire lifetime of the session manager instance
• This is safe because: if the session was newly created, no agents could have pre-existed in the repository
• The same session manager cannot be attached to agents with the same agent_id (enforced by existing validation)

[Unshure]

/strands

[github-actions]

Repository Analysis & Clarifying Questions

Repository Analysis

I've analyzed the session management architecture and identified the optimization opportunity:

Current Flow

In RepositorySessionManager.__init__:

1. Calls read_session(session_id) to check if session exists
2. If session doesn't exist, creates a new session

In initialize(agent), initialize_multi_agent(), initialize_bidi_agent():

1. Always calls read_agent() / read_multi_agent() to check existence
2. If None, creates the agent; otherwise restores from session

Optimization Identified

When a new session is created in __init__, we know with certainty that:

• No agents can exist in the session yet
• The read_agent() call will always return None
• This API call is unnecessary and can be skipped

For S3-backed sessions, this eliminates an S3 GetObject API call per agent initialization.

Files to Modify

• src/strands/session/repository_session_manager.py - Add flag to track new session state
• tests/strands/session/test_repository_session_manager.py - Test coverage for optimization

Proposed Implementation

class RepositorySessionManager(SessionManager):
    def __init__(self, session_id: str, session_repository: SessionRepository, **kwargs: Any):
        # ... existing code ...
        session = session_repository.read_session(session_id)
        if session is None:
            # Track that this is a new session
            self._is_new_session = True
            session = Session(session_id=session_id, session_type=SessionType.AGENT)
            session_repository.create_session(session)
        else:
            self._is_new_session = False
        # ... rest of init ...

Clarifying Questions

1. Scope of Optimization

Should this optimization apply to all agent types?

• initialize(agent) - regular Agent
• initialize_bidi_agent(agent) - BidiAgent
• initialize_multi_agent(source) - MultiAgent

I assume yes since they all use the same pattern of calling read_agent/read_multi_agent first.

2. Flag Behavior

Once the session is marked as "new", should the flag:

• Option A: Remain True for the session's lifetime (since we know no agents existed at creation)
• Option B: Be reset to False after the first agent is created

I'm leaning toward Option A since if the session was newly created, no agents could have pre-existed in the repository.

3. API Considerations

Is there a use case where an agent might be created in a "new" session by an external process between session creation and agent initialization? If so, Option A might miss restoring that agent.

I assume this is not a concern since session management is typically isolated to a single process.

Please let me know if my assumptions are correct or if you have any preferences on the implementation approach.

[Unshure]

/strands

1. yes
2. Thats fine. You should not be able to attach the same session manager to an agent with the same agent id, so this flag can stay set
3. Today no

[Unshure]

/strands implement

[github-actions]

Unable to create pull request via API. You can create it manually by clicking here.