Power Platform Community Forum Thread Details

Subject

Copilot Studio – SystemError on first API invocation (cold start / first‑turn failure)

Issue Summary

We are consistently encountering a SystemError on the first API call made by a Copilot Studio agent. The same input succeeds on the second attempt, without any configuration or code changes. This behavior reproduces reliably and appears tied to first‑turn initialization rather than API logic.

Environment

Product: Microsoft Copilot Studio

Channel: (Teams / Web – specify if needed)

Execution model:
- External API invoked via Connector / Power Automate Flow / Tool action (same behavior observed)

Authentication: Configured and working (validated via second call success)

Agent status: Published and stable

Error Details

Sorry, something unexpected happened.
Error code: SystemError
Conversation ID: a:1mH9TDQMQF27Xs58UtF_xXpIHZQ72XZ8pjcdbsdgOOs0P598pPWcWkGwADbyVdgCkvFZxoofOenPVvYX09MyOiBj8RqjouGfwX2iyPYKbF8FTlQ6HS6bTcDVG7-25kckl
Time (UTC): 2026‑02‑25 06:57:30

Repro Steps (100% reproducible)

Start a new conversation with the Copilot Studio agent

Send a prompt that triggers an external API / Flow / Tool

Agent returns SystemError

Send the exact same prompt again

API executes successfully and returns expected output

Clear chat → issue reproduces again on first message

Expected Behavior

First API invocation should succeed, or

Connector / Flow / Tool error should surface explicitly (auth / timeout / payload), not as a generic SystemError

Actual Behavior

Copilot fails during the first turn, before meaningful error handling

Error is surfaced as generic SystemError, with no connector‑level or flow‑level detail

Subsequent turns work reliably

Observations

This occurs only on the first turn of a new conversation

Second call works without changes → rules out API defects

Disabling Dynamic chaining with generative actions significantly reduces frequency

Introducing a warm‑up (non‑API) step before the first external call avoids the issue entirely

Indicates a cold‑start / initialization gap in Copilot Studio orchestration

Business Impact

Poor first‑time user experience

Appears as instability to end users

Requires artificial warm‑up patterns to ensure reliability

Not acceptable for production‑grade enterprise workflows

Request to Microsoft

Confirm whether this is a known first‑turn initialization defect in Copilot Studio

Clarify expected behavior for first API / Flow / Tool invocation

Provide a platform‑level fix or guidance so agents do not fail on first turn

Improve error surfacing so connector / flow failures are not masked as SystemError

Temporary Mitigation (for reference)

We have implemented a two‑phase execution pattern:

First turn: initialize conversation state (no external calls)

Second turn: invoke API

This avoids the error but should not be required.

Additional Notes

Happy to provide:

Agent export

Connector / Flow definitions

Run history screenshots

HAR / telemetry if needed

Issue in first AP...

Categories:

Calling actions from Copilot Studio

This behavior is consistent with a first-turn cold start / initialization delay in Copilot Studio when invoking external actions (Connector / Flow / Tool).

On the first message of a new conversation, the runtime initializes:

Conversation context
Authentication tokens
Connector bindings
Generative orchestration

If the external call executes before initialization completes, Copilot may surface a generic SystemError. The second attempt succeeds because the runtime is already warm.

Microsoft documentation confirms:

Generative orchestration and tool execution behavior
https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-orchestration
Use Power Automate flows in Copilot Studio
https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-flow
Known limitations and runtime behavior
https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-tools-custom-agent

Recommended mitigation (Microsoft-supported patterns):

Add a non-API welcome/initialization turn
Disable Dynamic chaining with generative actions (if not required)
Implement retry logic inside Power Automate
Add timeout handling in connector

If reproducible across environments, open a Microsoft support ticket with Conversation ID and UTC timestamp, as first-turn SystemError is not expected production behavior.

Your two-phase execution workaround is architecturally correct until Microsoft provides a platform fix.

Thanks,

Karan Shewale