[FEATURE] Maintain consistent session ID across multi-agent execution flows

[nagabharann]

Problem Statement

Dynamically spawned agents in multi-agent scenarios may have different session IDs. This breaks tracing, debugging, and conversation history coherence when agents spawn sub-agents or delegate to other agents.

Proposed Solution

Provide a mechanism to propagate session ID across agent boundaries:

1. Automatic session ID inheritance when spawning sub-agents
2. A context propagation mechanism for multi-agent scenarios
3. Configuration option to maintain or isolate session IDs

Use Case

In multi-agent orchestration:

1. A coordinator agent receives a request (session ID: abc123)
2. It spawns specialist agents to handle subtasks
3. All agents should share session ID abc123 for:

• End-to-end request tracing
• Unified conversation history
• Correlated logging and observability
• Debugging complex multi-agent flows

Alternatives Solutions

We currently manually propagate session IDs, but this is error-prone and requires modifying agent instantiation patterns.

Additional Context

No response

[poshinchen]

/strands

[github-actions]

Repository Analysis & Clarifying Questions

I've analyzed the Strands Agents SDK repository structure and session/multi-agent architecture to understand the scope of this feature request. I have several clarifying questions before this can be refined into an implementable task.

Repository Context

Session Architecture:

• session_id is currently a property of SessionManager (specifically RepositorySessionManager), not of the Agent class itself
• Agent has an agent_id but no session_id attribute
• SessionManager is passed to Agent.__init__() via the session_manager parameter, with session_id being set during SessionManager construction
• The Session data model (types/session.py) contains session_id and session_type

Multi-Agent Patterns:

• Agent-as-tool (as_tool()): Sub-agents are independent Agent instances — no session manager inheritance or propagation occurs
• Graph: GraphBuilder.set_session_manager() sets the session manager at the orchestrator level. Individual agent nodes are explicitly blocked from having their own session managers: "Session persistence is not supported for Graph agents yet."
• Swarm: Same restriction — individual nodes cannot have their own session managers

Telemetry/Tracing:

• OpenTelemetry tracing uses span parent/child hierarchies via trace_api.get_current_span()
• ThreadingInstrumentor propagates trace context across threads
• No session_id attribute is currently added to any trace spans
• Correlation across agents relies purely on span hierarchy, not session ID

Clarifying Questions

1. Core Problem Definition

The issue mentions "session ID" but the SDK has two distinct concepts that could be relevant:

• Session persistence (sharing the same SessionManager/session_id for conversation history and state storage)
• Tracing/observability (propagating a correlation ID across agent boundaries for end-to-end request tracing)

Which aspect is the primary concern? Both? Or specifically one?

2. Multi-Agent Patterns in Scope

Which multi-agent patterns does this feature target?

• Agent-as-tool (as_tool()) — sub-agents as tools for a parent agent
• Graph — directed graph orchestration
• Swarm — collaborative agent teams
• All of the above?

Note: Graph and Swarm already have orchestrator-level session manager support but explicitly block individual agent session managers.

3. "Dynamically Spawned Agents"

Can you clarify what "dynamically spawned agents" means in your use case? Specifically:

• Agents created at runtime and added via as_tool()?
• Agents within Graph/Swarm nodes?
• Agents created inside tool functions?
• Some other pattern?

4. Expected API / Configuration

The proposal mentions "Configuration option to maintain or isolate session IDs." What does the ideal API look like? For example:

• A session_id parameter on Agent.__init__()?
• Automatic inheritance when using as_tool() (sub-agent inherits parent's session_id)?
• A shared session context propagated via invocation_state?
• Something else?

5. Tracing vs. Session Persistence

OpenTelemetry already propagates trace context (parent/child spans) across agent boundaries. Is the existing span hierarchy insufficient for your tracing/debugging needs? Or do you specifically need a session_id attribute on trace spans for correlation in your observability backend?

6. Conversation History Sharing

"Unified conversation history" — does this mean:

• All agents in a multi-agent flow should read/write to the same conversation history store (same session)?
• Each agent maintains its own conversation history but they're correlated by a shared session ID?
• Something else?

7. Scope Concerns

Based on my analysis, this feature could be quite broad. It potentially touches:

• Agent.__init__() (adding session_id as a first-class concept)
• SessionManager (session sharing/inheritance)
• _AgentAsTool (propagating session context to sub-agents)
• Graph/Swarm (lifting the restriction on individual agent session managers, or propagating session context)
• Tracer (adding session_id to trace spans)
• All corresponding tests

Should this be broken down into smaller sub-tasks? For example:

1. Add session_id as a first-class attribute on Agent
2. Propagate session context in agent-as-tool pattern
3. Add session_id to telemetry/trace spans
4. Extend Graph/Swarm session propagation

8. GitHub Workflows

Does this feature require any new CI/CD workflows or changes to existing ones? If workflows are needed, they would need to be created under a .github_temp directory since I don't have permission to push to .github.

Please respond when you have a chance. Your answers will help me scope this feature properly and create a clear implementation plan.