PowerLeap Logo

Copilot Studio Friction

Get notified when this record changes

One email when the status or the fix changes — double opt-in, no tracking, unsubscribe in every email.

"Outgoing message size too big" — the answer never arrives

Mitigatedsince 8 July 2026

Last verified

Details & related

Assessment

Confidence
Confirmed officialConfirmed by Microsoft documentation or an official statement.
Severity
Blocking
Typical time lost
Hours

Identification

Topics & variablesAll channels

Verification & changes

  1. Verified

    Doc check by human: Error-code reference and variables documentation re-read during seed migration; the Direct Line cap and remedy are still documented.

  2. Change

    Provisionally approved by the Product Owner; external LLM quality review pending.

  3. Change

    Initial record created from the seed dossier (migration wave 1).

Related

Are you in the right place?

  • The agent's answer never arrives, or the turn fails with "Outgoing message size too big".
  • Logs or error details show the code MessageSizeExceeded.
  • The failing answer carries a big payload — long text, a large object, or card data.
  • Small answers in the same topic go through.

If the error names conversation state → see "Conversation state size exceeds the maximum allowed limit". That limit caps everything stored across the conversation; this record caps one outgoing message. If the chat shows raw JSON instead → see Chat shows raw JSON instead of an answer.

What's happening

Every channel caps the size of a single outgoing message. For Direct Line, the cap is 262,144 bytes — 256 KB — documented as of 2026-07-08. When your agent tries to send more, the message fails with MessageSizeExceeded. The usual culprits are variables holding large text or whole objects. Adaptive Card payloads passed between topics are a documented cause as well. Think of a mailbox slot: a normal letter fits, a parcel does not. The parcel is not returned politely — the delivery fails, and the user sees nothing. The fix is to send only what the user needs, not the whole data object.

For technicians

The error-code reference names variables with large text volumes, such as JSON.stringify results, as a typical cause. Card data handed from topic to topic travels inside the conversation payload. The documented remedy: pass only the required property onward instead of the entire object. Message caps differ per channel; treat the smallest target channel as your payload budget.

How to fix it

Solution 1

Official workaround

Pass only the needed property

  1. Find the node that sends the failing answer.
  2. Check which variable feeds it and how big that value gets.
  3. Add a "Set variable value" node before the send.
  4. Store only the property you need, for example Topic.Answer = Topic.ToolResult.responseText.
  5. Point the message node or card at that small variable.
  6. Remove the large object from anything that leaves the topic.
  7. Retest the failing case.

✅ You should now see: the answer arrives in the channel instead of failing.

Check that it worked

Trigger the request that produced the oversized answer, in the affected channel — not only the test pane. Expected: the full answer arrives, with no MessageSizeExceeded in the logs.

If it didn't work

  • Another big payload travels along. Cards and attachments count toward the same cap. Check every part of the outgoing turn, not only the text.
  • A topic handover still carries the object. Later topics inherit stored objects. Apply the single-property rule at every handover, not only at the send.
  • The target channel has a smaller cap. Caps differ per channel. Test in the channel your users use, and budget for the smallest one.
  • The channel runs the old version. Publish and propagation delay is suspect number one. See Teams answers with an old version of your agent.

Prevent it next time

  • Follow variable hygiene: single properties between topics, never whole objects or card payloads.
  • Know the payload budget of every channel you publish to before you design data-heavy answers.
  • Keep large data out of the conversation; store and fetch it through an agent flow.

Evidence

  • Official documentationlearn.microsoft.com

    The error-code reference documents 'Outgoing message size too big', names the 262,144-byte Direct Line cap, and blames variables with large text.

  • Official documentationlearn.microsoft.com

    Values move between topics through variables, which is the path oversized objects and card payloads travel on.