[BUG] StrandsA2AExecutor served via serve_a2a never hits AgentCore idle session timeout (causes runaway execution environments)

[matseymour28590]

SDK Language

Python

Strands Version

strands-agents[otel,a2a]==1.45.0

Language Runtime Version

Python 3.13

Operating System

python:3.13-slim-bookworm docker image running in agentcore runtime

Installation Method

other

Steps to Reproduce

• Create a minimal vanilla Strands agent using the bedrock-agentcore-sdk-python and strands-agents SDKs.
• Wrap the agent using StrandsA2AExecutor(..., enable_a2a_compliant_streaming=True) and serve it using serve_a2a().
• Deploy the application to an AWS Bedrock AgentCore Runtime.
• Invoke the agent normally.
• Monitor the AWS CloudWatch metrics and log streams for the execution environment.

import os

from bedrock_agentcore.runtime import serve_a2a
from strands import Agent
from strands.models.bedrock import BedrockModel
from strands.multiagent.a2a.executor import StrandsA2AExecutor


_MODEL_ID = os.getenv("MODEL_ID", "")
_AGENT_CARD_CONTEXT_ID = "__agent_card__"
_AGENT_DESCRIPTION = (
    "An analytics agent"
)
_SYSTEM_PROMPT = (
    "You are an analytics assistant."
)


def _build_agent() -> Agent:
    return Agent(
        model=BedrockModel(model_id=_MODEL_ID),
        name="Agent",
        description=_AGENT_DESCRIPTION,
        system_prompt=_SYSTEM_PROMPT,
    )


def _agent_factory(context_id: str) -> Agent:
    return _build_agent()


if __name__ == "__main__":
    executor = StrandsA2AExecutor(
        agent_factory=_agent_factory,
        enable_a2a_compliant_streaming=True,
    )
    serve_a2a(executor)

Expected Behavior

After the client request finishes (or the client disconnects), the underlying ASGI server should cleanly resolve the request. The AgentCore Runtime should then recognize the environment as "Idle", start the idleRuntimeSessionTimeout countdown, and cleanly shut down the microVM once the timeout is reached.

Actual Behavior

• The AgentCore Runtime considers the environment continuously "Active".
• The idleRuntimeSessionTimeout is never reached.
• Despite there being no further requests for the session, the execution environment remains alive, indefinitely racking up continuous GB-hour billing, until it hits the platform's absolute hard maximum lifetime limit (e.g., 8 hours) and is forcefully killed.

Additional Context

I don't have the same issue for regular (non-A2A) strands agents.

I originally opened a bug report to the Strands developers strands-agents/harness-sdk#3120 and they said they internally diverted it to the agentcore team. I am making this ticket so there is a publicly accessible way to track the progress.

Possible Solution

No response

Related Issues

No response

[xg-gh-25]

The root cause is likely that serve_a2a's execution loop never yields control back to AgentCore's session manager — the A2A server runs in a blocking accept() loop that handles agent-to-agent protocol messages, and while it processes each A2A request/response pair, it never signals "I'm idle" to the parent session context.

Why this matters in production:

• Each StrandsA2AExecutor that serves A2A stays alive indefinitely once spawned
• If you're spawning executors per-request (or per-session), they pile up
• No cleanup = memory/process leaks, runaway resource consumption

Tactical fix:
Check if serve_a2a has a session_context or timeout parameter that you're not passing. If StrandsA2AExecutor supports idle_timeout_seconds in its constructor, thread that through to the A2A server. Alternatively, wrap serve_a2a in a parent process that enforces a TTL and kills the executor if it hasn't received traffic in N seconds.

Strategic fix (for the SDK maintainers):
The A2A server loop should integrate with AgentCore's session lifecycle — either by checking a shared "last activity" timestamp and self-terminating, or by registering a periodic heartbeat with the session manager so it can be reaped when idle.

If you're hitting this in production right now: add process-level monitoring (e.g., a supervisor that kills stale executors based on connection idle time) as a stopgap until the SDK fix lands.

---

Context from an AI coding agent built with SwarmAI. Discussion: T-MEM