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.

Teams answers with an old version of your agent after publishing

Mitigatedsince 8 July 2026

Last verified

Details & related

Assessment

Confidence
CorroboratedMultiple independent sources describe the same behaviour.
Severity
Degrading
Typical time lost
Hours

Identification

Publish & channelsMicrosoft Teams

Verification & changes

  1. Verified

    Doc check by human: Source threads and dossier sections B1/R2 re-read during seed migration; behavior still reported as of mid-2026.

  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 reference set).

Are you in the right place?

  • You published a change, and the test pane shows the new behavior.
  • The agent in Microsoft 365 Copilot chat also answers with the new behavior.
  • Only the Teams channel keeps answering with the old logic or old content.
  • The agent's "last updated" timestamp in Teams has not changed.
  • You changed nothing else in the meantime.

If instead every question in Teams fails with the error code SystemError → see the record for that code (record planned). If instead the agent answers nothing at all → see Agent gives no answer and no error message.

What's happening

When you publish, Copilot Studio does not update every channel at the same moment. Teams keeps a cached copy of your agent, and the update travels asynchronously across Microsoft's regions. Asynchronously means: the publish command finishes before all channels are up to date. Until the Teams copy refreshes, users get the old version. Existing chat sessions are worse: they often stay on the configuration they started with. Picture a supermarket chain with a new flyer: some branches still hang last week's poster. Microsoft's documentation mentions changes appearing within about 30 minutes; makers report longer and unpredictable delays.

For technicians

Community threads from the PVA era to 2026 attribute this to caching plus asynchronous propagation across regions. The platform surfaces no propagation status. An unchanged "last updated" timestamp on the Teams agent points to pending propagation, not a broken change. Makers therefore cannot distinguish "my change is wrong" from "my change has not arrived".

How to fix it

Solution 1

Community workaround

Run the publish ritual

This is the publish ritual pattern in its Teams form.

  1. In Copilot Studio, select "Publish" and confirm.

✅ You should now see: a confirmation that publishing completed, with a fresh timestamp.

  1. In Teams, close the conversation with your agent.
  2. Start a completely new conversation.
  3. Type "start over" to reset the conversation state.
  4. Sign out of Teams.
  5. Sign back in to Teams.
  6. Remove the agent app from Teams.
  7. Re-add the agent from the Teams app catalog under "Apps".
  8. Wait at least 30 minutes before you decide the change did not arrive.

✅ You should now see: the new behavior in a fresh Teams conversation.

Check that it worked

Pick a question whose answer changed in your latest version. Ask it in Teams, in a brand-new conversation — not in the test pane. Expected: the answer reflects the new version.

If it didn't work

  • Propagation is still running. This is suspect number one. Makers report delays well beyond the documented 30 minutes. Wait, then retest in a new conversation.
  • You retested inside an old conversation. Sessions often keep the configuration they started with. Start a new conversation every time.
  • You opened the pinned app. The pinned entry can serve the cached version. Open the agent from the Teams app catalog instead.
  • The publish itself failed. Check the publish status and timestamp in Copilot Studio before you suspect Teams.

Prevent it next time

  • Run the publish ritual after every publish, before you judge any change.
  • Never close a debugging session with "the fix didn't work" until propagation is ruled out.
  • Plan publish wait time into every Teams test cycle.

Evidence

  • Community threadlearn.microsoft.com

    Makers report a published agent keeps answering with old logic in Teams while the test pane is current.

  • Community threadlearn.microsoft.com

    An independent thread confirms Teams serving stale agent versions and points to asynchronous publish propagation.