Share via

Azure AI Foundry - Agent replies never reach Teams/web chat after new bot agent migration

SriramN 20 Reputation points
2026-05-05T16:44:11.9566667+00:00

Background — regression after unannounced migration

We had an agent published to Microsoft Teams via the AI Foundry native connector that was working correctly. Around May 4 2026, We were trying some changes changes to our agent or bot configuration, but see that the bot agent migration happened. We see in the previous agents there is a different publish to teams option and if we create a new one, there there is an endpoint and a different option.

Issue 1 — Publish fails: BotId does not match instance_identity

Error message:

Failed to publish agent BotId '<guid-X>' does not match the application's default instance identity ClientId '<guid-Y>'
[Status: 400, Code: UserError, Location: swedencentral]

What I observe:

  1. I create a new agent in the AI Foundry portal and save it.
  2. AI Foundry auto-provisions a bot service with App ID X (matching the agent's instance_identity.client_id at creation time).
  3. I open Publish → Microsoft Teams and click Publish.
  4. The publish flow appears to rotate the agent's instance_identity to a new GUID Y.
  5. Publish validation checks: bot App ID (X) vs current instance_identity (Y) → mismatch → 400.

Why I cannot fix this manually:

  • The Microsoft App ID on an Azure Bot Service is immutable after creation.
  • The publish dialog shows only the AI Foundry-provisioned bot — there is no option to select a different existing bot service.
  • Deleting the bot service and retrying causes AI Foundry to regenerate a new bot with the same original App ID X — the mismatch persists.

Question: Is there a supported way to keep the bot App ID and the agent's instance_identity in sync, or is this a known issue in the preview?

Issue 2 — Agent replies never reach web chat (even when publish succeeds)

After the migration: Error message in web chat:*

We apologize, but something went wrong. Please try again.
ConversationId=<id>, ActivityId=<id>|0000000

What the traces confirm:

AI Foundry → Traces shows the agent processes every message and generates a correct response. The response is simply never delivered back to Teams.

Name Status Duration Tokens In Tokens Out
invoke_agent my-agent:1 Completed 4–8s 6359 125–221
chat gpt-5.4-2026-03-05 Completed <1s — —

What I have investigated and ruled out:

Attempt 1 — Use the AI Foundry auto-created bot (Single Tenant)

AI Foundry auto-creates the bot as Single Tenant type with the agent's ServiceIdentity as the App ID. Single Tenant bots require a client secret (App Password) to authenticate outbound Bot Framework replies:

POST https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token
  client_id     = <ServiceIdentity App ID>
  client_secret = <App Password>   ← not set / not valid
  grant_type    = client_credentials
  scope         = https://api.botframework.com/.default

The ServiceIdentity has servicePrincipalType: "ServiceIdentity" in Entra — it has no App Registration object and no client secret can be added manually. Outbound token acquisition fails silently → reply never sent → "We apologize."

Attempt 2 — Create a custom UAMI-type bot

Created a bot service via REST API with msaAppType: UserAssignedMSI using a fresh User-Assigned Managed Identity, pointed at the same activity protocol endpoint, with Teams channel added. Result: no traces, no response.

Direct POST to the activity protocol returned:

HTTP 401 — "Token not supported"

The activity protocol validates Bot Framework JWTs only and checks that token.appid matches the agent's ServiceIdentity App ID. Any other App ID — including a custom UAMI — is rejected before the agent is invoked. RBAC role assignments have no effect; the check never reaches the authorization layer.

Attempt 3 — Use the Blueprint App Registration instead

Each agent has a paired AgentIdentityBlueprint application (type: Application in Entra, can have client secrets). However the activity protocol validates tokens against the ServiceIdentity, not the Blueprint. A bot registered with the Blueprint's App ID also receives 401 Token not supported.

Questions for Microsoft:*

  1. Why does the auto-created bot service have no valid App Password configured, given its ServiceIdentity cannot support client secrets?
  2. Is there an internal mechanism AI Foundry uses for outbound Bot Framework authentication that is currently broken or not wired up for new agents?
  3. Will the publish flow be updated to use User-Assigned Managed Identity bot type (already GA in Azure Bot Service) so that both directions work without a client secret?

Environment

  • Region: swedencentral
  • API version: 2025-11-15-preview
Foundry Agent Service
Foundry Agent Service

A fully managed platform in Microsoft Foundry for hosting, scaling, and securing AI agents built with any supported framework or model

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-05-05T16:44:49.3966667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The behavior described matches migration and identity limitations in the current preview. The issues are known side effects of the transition from legacy Agent Applications to the new agents model and publishing flow.

    For Issue 1 (BotId does not match instance_identity):

    • New agents must have a non-null agent.identity (unique identity) to be publishable to Microsoft 365/Teams. Legacy agents (with agent.identity == null) and legacy Agent Applications are being phased out in favor of the new model.
    • There is currently no supported in-place upgrade path that preserves the old identity; the documented guidance is to create a new agent using the same definition. The new agent automatically receives a unique identity and stable endpoint.
    • Publishing to M365/Teams requires that the agent’s identity and the publishing metadata are consistent. If the agent does not have a unique identity or the identity is in an inconsistent state, publishing fails with an identity-related error. The official troubleshooting guidance for “Publishing fails with identity error” is to follow the migration guide and ensure the agent has a unique identity.
    • The platform explicitly notes that an in-place identity upgrade gesture for legacy agents is “coming soon,” and that Agent Applications are planned for deprecation. During this transition, identity mismatches and the need to recreate agents are expected limitations.

    Given the documentation:

    • The supported path is to create a new agent (Path 2 / Path 3 in the migration guide) and ensure agent.identity is non-null, then publish that new agent.
    • There is no documented mechanism to manually align or override the Bot Service App ID with a rotated instance_identity, nor to select an arbitrary existing Bot resource in the new publish flow.
    • When publishing fails with an identity-related error, the prescribed resolution is to follow the migration steps and use a new agent with a valid unique identity.

    For Issue 2 (Agent replies not reaching Teams/web chat after migration):

    • The documentation confirms that:
      • Legacy Agent Applications continue to serve traffic through their existing endpoints.
      • New agents use a different, stable agent endpoint (.../agents/{agent}/protocols/...) instead of the legacy application endpoint.
      • Published agents do not support streaming responses or citations, but there is no documented functional limitation that would prevent replies from being delivered when the agent is correctly published and the identity is valid.
    • When agents are published to M365/Teams and then fail after publishing, the documented root cause is typically missing permissions on the agent’s identity, not a general failure of the reply path. The guidance is to assign the necessary RBAC roles to the agent identity for any Azure resources it accesses.
    • For Teams/M365 publishing, a common failure mode is that the agent does not have a unique identity (agent.identity is null or invalid). In that case, publishing or invocation can fail, and the remedy is again to follow the migration guide and ensure the agent is a “new agent” with a valid identity.

    From the available documentation:

    • There is no explicit description of the internal Bot Framework authentication wiring (ServiceIdentity vs. User-Assigned Managed Identity) or of the exact token flow for outbound replies.
    • There is no documented configuration surface in the Foundry portal to switch the Bot Service to use User-Assigned Managed Identity or to manage client secrets for the auto-created bot.
    • The docs treat the Bot Service creation and wiring as an implementation detail of the publishing flow; the supported knobs are at the agent level (identity, endpoint, permissions), not at the bot-auth level.

    Answers to the specific questions, based only on documented behavior:

    1. There is no documented way to control or inspect how the auto-created bot’s credentials are configured. The platform requires that the agent has a unique identity and uses that identity for publishing; credential wiring for the Bot Service is not exposed as a supported configuration surface.
    2. When an agent works in Foundry but fails after publishing, the documented cause is typically identity or permissions (for example, missing RBAC roles on the agent identity). The official guidance is to:
      • Ensure agent.identity is non-null (new agent, not legacy).
      • Assign required RBAC roles to the agent’s identity for any Azure resources it accesses.
      • If publishing fails with an identity error, follow the migration guide and recreate the agent as needed. The documentation does not describe or expose any internal mechanism for Bot Framework authentication beyond these identity requirements.
    3. The documentation does not state that the publish flow supports configuring Azure Bot Service to use User-Assigned Managed Identity, nor does it describe any roadmap to switch to that model. The only supported and documented path is to:
      • Use new agents with non-null agent.identity.
      • Publish via the Foundry portal’s built-in Teams/M365 publishing experience.
      • Rely on the platform’s automatic Bot Service provisioning and wiring.

    In summary, the supported actions are:

    • Treat legacy Agent Applications and legacy agents as transitional; do not rely on their identities.
    • Create new agents with non-null agent.identity and use the new agent endpoints.
    • If publishing fails with identity-related errors, follow the migration guide (Path 2/3) and recreate the agent so that it has a valid unique identity.
    • For post-publish failures, verify the agent identity’s RBAC permissions as documented.

    Details such as Bot Service App ID/secret management, ServiceIdentity vs. UAMI, and the internal reply token flow are not configurable or documented in the current preview.

    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.