microsoft/semantic-kernel · error · TimeoutError

Agent did not reach status {status} within the specified tim

Error message

Agent did not reach status {status} within the specified time. Current status: {self.agent_model.agent_status}

What it means

Raised by _wait_for_agent_status as a TimeoutError when the agent does not reach the target BedrockAgentStatus within max_attempts * interval seconds (default 5 attempts * 2s = 10s). Each attempt calls _get_agent to refresh the status and sleeps if it hasn't matched. Bedrock agent preparation can take longer than the default window, especially under load.

Source

Thrown at python/semantic_kernel/agents/bedrock/bedrock_agent_base.py:178

        except ClientError as e:
            logger.error(f"Failed to get agent {self.agent_model.agent_id}.")
            raise e

    async def _wait_for_agent_status(
        self,
        status: BedrockAgentStatus,
        interval: int = 2,
        max_attempts: int = 5,
    ) -> None:
        """Wait for the agent to reach a specific status."""
        for _ in range(max_attempts):
            await self._get_agent()
            if self.agent_model.agent_status == status:
                return

            await asyncio.sleep(interval)

        raise TimeoutError(
            f"Agent did not reach status {status} within the specified time."
            f" Current status: {self.agent_model.agent_status}"
        )

    # endregion Agent Management

    # region Action Group Management
    async def create_code_interpreter_action_group(self, **kwargs) -> BedrockActionGroupModel:
        """Create a code interpreter action group."""
        if not self.agent_model.agent_id:
            raise ValueError("Agent does not exist. Please create the agent before creating an action group for it.")

        try:
            response = await run_in_executor(
                None,
                partial(
                    self.bedrock_client.create_agent_action_group,
                    agentId=self.agent_model.agent_id,

View on GitHub (pinned to c028a0c7dc)

Solutions

Retry the operation — Bedrock preparation is often just slow, and a second attempt usually succeeds.
If the agent is in FAILED status, check the AWS console for the failure reason (model access, role, etc.) before retrying.
Increase the polling window by calling _wait_for_agent_status with larger interval/max_attempts if accessible, or wait and re-invoke prepare.
Verify model access is granted and the IAM role is valid, as these cause persistent FAILED status.

Example fix

// before
await agent.prepare_agent_and_wait_until_prepared()  # raises TimeoutError after 10s

// after
# Option 1: retry with backoff
for attempt in range(3):
    try:
        await agent.prepare_agent_and_wait_until_prepared()
        break
    except TimeoutError:
        await asyncio.sleep(10)
# Option 2: check status in AWS console; ensure model access + IAM role

Defensive patterns

Strategy: retry

Try / catch

import asyncio

for attempt in range(3):
    try:
        await agent.prepare_agent_and_wait_until_prepared()
        break
    except TimeoutError as e:
        if "did not reach status" in str(e):
            await asyncio.sleep(15)
        else:
            raise
else:
    # check AWS console for FAILED status; verify model access + IAM role
    raise

Prevention

Wrap prepare/create calls in a retry loop with backoff — Bedrock preparation often exceeds the default 10s window.
Confirm the agent is not in FAILED status (model access, IAM role) before retrying.
For large agents, expect longer preparation times and budget retry attempts accordingly.
Monitor the AWS console during agent creation to correlate status transitions.

When it happens

Trigger: Triggered after max_attempts iterations of the polling loop in _wait_for_agent_status without self.agent_model.agent_status equaling the target status. Called during prepare_agent_and_wait_until_prepared (waits for PREPARING then PREPARED) and create_and_prepare_agent (waits for NOT_PREPARED).

Common situations: Bedrock agent preparation taking longer than 10s (common for complex agents with many action groups); AWS region under heavy load; the agent entered FAILED status (never reaches PREPARED); network latency inflating each _get_agent round-trip; default polling window too short for production agents.

Related errors

AI-assisted analysis of microsoft/semantic-kernel@c028a0c7dc (2026-08-13). Data as JSON: /api/errors/a9fcd4770336ed08. Report an issue: GitHub.