Agent flows in Copilot Studio error out if they do not answer fast. The platform throws FlowActionTimedOut around the 100 second mark for agent tools, while generic flow docs talk about a two minute window. Teams that design to 120 seconds are the ones who get paged.

The point here is simple and operational. Synchronous agent→flow calls cannot be trusted beyond about 100 seconds, so the production safe approach is an async continuation pattern: respond quickly, persist a job, finish out of band, and callback on a supported channel with the result. As of 2026-08-29, this matches Microsoft guidance and limits.

Contents

Why synchronous agent flows hit a wall at ~100 seconds

Copilot Studio agent tools use a standard harness: a flow with the When an agent calls the flow trigger and a Respond to the agent action. That pair must complete promptly. Microsoft’s error catalog lists FlowActionTimedOut for agent flows that run longer than 100 seconds. Microsoft’s tool guidance for agent flows says respond within the 100 second action limit. Treat that as your budget.

General Power Automate limits are different. The synchronous window for a single outbound or inbound request is 120 seconds, and flows that contain a response action must return within the same 120 seconds. If you see an inner error code ResponseTimeout, that is the general two minute ceiling.

So there are two timers depending on the caller. Agent calls hit a limit around 100 seconds, while generic synchronous work sees 120 seconds. The smaller budget governs the design, and teams should not assume the larger one applies to an agent tool.

This has architectural weight. Any step that might exceed that window, including long API sequences and human approvals, must run after Respond to the agent or use asynchronous responses. A flow can continue after it sends a response. That is the seam where fast acknowledgement splits from slow work.

One pattern does not work here. Increasing Action Timeout or adding retries on the response action does not extend the platform’s per request limit, so the run still fails with the documented timeout codes when the window is breached.

Architect the async continuation: respond fast, queue work, deliver results later

A pattern that survives timeouts acknowledges the agent quickly, persists a job, lets a worker finish out of band, and returns results asynchronously through supported channels.

Two features support this. First, flows can continue running after Respond to the agent. The conversational turn closes, yet the run can keep working toward a result. Second, Copilot Studio supports asynchronous responses for agent flows. As of 2026-08-29, asynchronous responses are available with Teams callbacks and channel limitations. They are not supported in Microsoft 365 Copilot or telephony channels, and environment upgrades affect availability.

A long running run can span up to 30 days. That sets an outer bound for the worker and aligns with modern approvals guidance, which stores state in Microsoft Dataverse and acts on responses after the original run has timed out.

Sequence to follow:

  • Agent calls the flow with inputs and a user context.
  • Flow generates a correlation id, persists a job row to Microsoft Dataverse, and responds quickly with a receipt that includes the correlation id.
  • A worker flow reacts to the new job, processes it, and computes a result.
  • The worker posts a callback. If the channel supports asynchronous responses, send the completion back to the agent. In Teams, post as the Copilot Studio agent into the user’s chat with the agent.

Include a resolvable identity for Teams callbacks. Store the user UPN or object id in the job record so the message reaches the user.

A minimal job payload looks like this:

{
  "jobId": "f6c1b3f1-0f94-4a83-9e2c-1b3e4a2e7a10",
  "correlationId": "agent-ACME-20260829-001234",
  "status": "Queued",
  "inputJson": { "tickets": [12345, 67890], "priority": "High" },
  "callerChannel": "Teams",
  "callbackTarget": { "type": "User", "upn": "user@contoso.com" },
  "attempts": 0,
  "nextAttemptAt": "2026-08-29T12:30:00Z"
}

Keep the first response small and deterministic. The worker does the heavy lifting.

Build it: a runnable queue/callback sample you can import

Set up three assets: a Microsoft Dataverse table for the queue, an agent flow that responds early, and a worker flow that processes jobs and posts a callback. Optionally, enable express mode on the agent tool to trim overhead.

1) Queue table in Microsoft Dataverse

  • Create a table named Agent Job in Tables > New table with columns:
  • jobid (GUID, primary column)
  • correlationid (Text, required)
  • status (Choice: Queued, Processing, Succeeded, Failed)
  • payload and result (Multiline text)
  • callbackchannel and callbacktarget (Text)
  • attempts (Whole number) and nextattemptat (Date and time)
  • Define an alternate key on correlationid in Tables > Agent Job > Keys > New key. This enforces idempotency under retries. If a duplicate correlation id appears, Microsoft Dataverse returns a 409 conflict. Treat that as a de dup and continue.

2) Agent tool flow: respond fast

  • Create a cloud flow with the When an agent calls the flow trigger in Copilot Studio.
  • Validate inputs, compose a deterministic correlationId, and upsert into Agent Job using the alternate key. If the connector action does not offer Upsert, call Create and handle 409 by getting the row by alternate key.
  • Respond to the agent with a short message that includes correlationId and a receipt. Do not send large payloads here.
  • Optional: turn on express mode for this agent flow to reduce overhead. As of 2026-08-29 this feature is in preview. Treat it as a latency optimization only.

3) Worker flow: process and callback

  • Create a cloud flow with the Microsoft Dataverse trigger When a row is added, modified or deleted on Agent Job.
  • Configure the trigger for Create only. Add a trigger condition so it fires when status equals Queued:
@equals(triggerOutputs()?['body/<status_logical_name>'], 'Queued')

Replace <status_logical_name> with your status column’s logical name (for example, crd1a_status). You can find it on the column’s details pane in the maker portal under Name.

  • In Trigger > Settings, enable Concurrency Control and set a degree of parallelism the downstream APIs can absorb. Enabling trigger concurrency reduces SplitOn capacity and, for some triggers, you cannot undo the change without rebuilding the trigger.
  • Steps:
  • Update status to Processing and increment attempts.
  • Perform the long running work. Keep per action timeouts within limits. Use per action retry policies for transient faults.
  • Update status to Succeeded or Failed and store result.
  • Callback. In Teams, use the Teams connector to post as «Microsoft Copilot Studio agent» into «Chat with agent» for the user. If the channel supports asynchronous responses, send the completion back to the agent.

Keep the Teams message concise and include the correlation id.

Make it durable: idempotency, retries, and concurrency that won’t bite at scale

Idempotency is not negotiable for queues. The alternate key on correlationid is the enforcement point in Microsoft Dataverse. Every enqueue attempt with the same correlation id must resolve to the same row. The simplest pattern is: try to create; on 409 conflict, get by alternate key and proceed.

Retries should be explicit and scoped. The designer lets you set a retry policy per action and a timeout per action. Use fixed or exponential backoff for transient failures, and stop retrying well before the 30 day outer limit for a run. The Action Timeout setting controls how long an action waits. It does not change the platform’s 120 second ceiling for a single synchronous request or the ~100 second agent tool budget.

Concurrency belongs on the trigger. Turn on trigger concurrency at a level the downstream systems can handle without throttling. Enabling it reduces SplitOn capacity. In some triggers, toggling concurrency is not reversible without rebuilding the trigger, so choose carefully.

Quotas still apply at every layer. Copilot Studio agent quotas and Power Platform request limits both count, and connector specific throttles often bind first. Expect 429 responses under load. Use backoff and, where possible, honor Retry-After headers.

Instrument your runs. Use tracking properties for correlation ids on key steps and export telemetry to Application Insights in managed environments. The worker must expose stuck jobs and repeated failures for operations to act.

What to watch carefully

  • 100 seconds versus 120 seconds. For agent tools, treat 100 seconds as your budget with FlowActionTimedOut on breach. General synchronous flows will surface ResponseTimeout at 120 seconds. The caller matters.
  • Asynchronous responses. As of 2026-08-29, asynchronous responses are available with Teams callbacks and channel limitations. They are not supported in Microsoft 365 Copilot or telephony channels. Availability depends on upgraded environment infrastructure.
  • Express mode. Preview status. It reduces overhead and can improve time to first response. It does not change the synchronous window. Validate payload sizes and loops against the documented caps and test under load.
  • Trigger concurrency. Enabling it reduces SplitOn capacity and is not trivially reversible on some triggers. Plan capacity before you flip it on.
  • Idempotency. Without an alternate key on correlationid, duplicate enqueue under retries is likely at scale and produces double work.
  • Run duration. A single flow run can last up to 30 days. Any longer human waits must split into separate flows backed by Microsoft Dataverse rows.
  • Telemetry sources. The Power Automate Management connector is throttled at 5 calls per 60 seconds and non GET at 300 per hour per connection. For higher volume reads, prefer the Power Platform API or Application Insights export in managed environments.
  • Throttling. Connector specific request limits usually bind before tenant caps. Shape worker throughput around those limits.
  • Licensing and capacity. As of 2026-08-29, agent flows consume Copilot Studio capacity. Express mode is available on upgraded environments under the Copilot Studio plan and is billed per action like other runs. Power Platform request limits still enforce sliding windows. Teams messaging depends on DLP and premium licensing where applicable.

Important: The Teams callback must target a resolvable identity. Ensure the job carries a UPN or object id that the Teams connector can address.

Warning: Do not try to extend the synchronous window with long retries on response actions. The per request limit still applies and will fail the run after the ceiling.

Note: Application Insights maps flow runs to Requests and actions to Dependencies. That makes stuck runs and hot connectors visible with no custom schema.

My take

Default to the queue and callback architecture for agent tools. It maps to what the platform guarantees, and it isolates latency from the conversational turn. Keep the turn short.

Favor Teams callbacks where the business accepts them. They’re supported and look native to users, and they let the agent deliver status and results without keeping the turn open.

Use express mode only as a latency optimization for the early response. It helps with cold starts and overhead in some environments, but it does not relax ceilings and it brings preview constraints that you need to test and carry into change control.

Design for failure.

Invest in telemetry and response time objectives early. Define targets for time to first response and time to completion by job type. Back those with alerts on stuck statuses and repeated failures, and make the correlation id the thread that ties the conversational turn, the job row, and the worker run together. Prefer Teams for callbacks when it is allowed by DLP and licensing, and fall back to agent asynchronous responses where the channel supports them.

There are costs. More flow runs, Microsoft Dataverse storage for jobs and results, more operational work, exposure to request quotas, and DLP enforcement on Teams messaging. Budget for these and decide where you want to pay: a little engineering up front, or pagers when the 100 second wall is hit.

Sources

Categorizado en:

Copilot Studio,

Etiquetado en:

, , , , ,