Azure AI Foundry New Foundry: Issues with Teams Bot

Hi Dinakar,

Thank you for reaching out on the Microsoft Q&A.

A few of us have hit very similar behavior with Agents V2 when deployed to Teams, especially when the agent works fine in the Foundry Playground but becomes unstable in Teams.

A few observations and things that helped narrow it down:

1. Teams vs Playground execution path The Playground runs the agent in a controlled Foundry context, while Teams goes through Azure Bot Service + Agents V2 invocation. Failures that only appear in Teams often point to:
   • Identity / token refresh issues
     • Downstream throttling or transient backend errors
       • Agent execution timeouts triggered by Teams’ request lifecycle
2. Logs & diagnostics (current limitations) At the moment, Agents V2 logging is unfortunately not very discoverable:
   • There’s no direct “log stream” in the Foundry portal for Teams invocations yet.
   • The ConversationId and ActivityId are mainly meant for Microsoft support correlation rather than self‑service debugging.
   • You may see partial traces in Application Insights (if enabled on the Bot Service), but they’re often high‑level and don’t always surface the root cause.
3. Things worth double‑checking

• Managed Identity permissions didn’t regress (especially after redeployments).
• No recent changes to tools, data sources, or models used by the agent.
  • Response latency, Teams is more sensitive to slow or long‑running agent executions than the Playground.

1. Known / emerging issues The new Foundry experience is still evolving, and there are known gaps around:

• Diagnostics for Agents V2
  • Correlating Teams failures back to Foundry internals If the error is persistent, opening a support ticket and sharing the ConversationId / ActivityId is currently the most reliable way to get a definitive answer.

You’re definitely not alone here several folks have reported intermittent AgentsV2InvocationUserException errors that only surface in Teams. Hopefully we’ll see improved logging and clearer diagnostics in upcoming Foundry updates.

References:

1. Azure AI Foundry Logs
2. Creating and Managing Hubs and Projects
3. Azure AI Tools and Models

I Hope this helps. Do let me know if you have any further queries.

Thankyou!

Thanks for confirming about the logging, Because I tried enabling diagnostic settings on both the bot service and the foundry resource and yet wasn't able to get useful information.
I've double checked the MI assigned and it's correct.

The bot when messaged directly gives the "Agents.ActivityProtocol.AgentsV2InvocationUserException" error only if any tool is attached to the agent , if no tool is attached to the published bot it responds properly like a chatbot.
And the bot works as intended whilst making proper tool calls if it is opened through co-pilot app.

And the bot works as intended when it is asked a question in the teams channel by using @botname and it replies in a separate thread separately to the user.

I found a related discussion describing a similar issue, where the conclusion was that there is currently no official documentation, and that agents are expected to be executed via Copilot integration.

From an architectural standpoint, if the intended and supported execution path is exclusively through Copilot, I am trying to understand why the bot operated successfully immediately after assigning the appropriate Managed Identity (MI). This suggests that, at least at that time, the authentication and authorization flow was functioning independently of Copilot.

Additionally as stated above, the bot continues to function as expected within Microsoft Teams. When a user mentions the bot in a channel using @botname, it processes the request and responds in a separate thread directly associated with that user interaction. This behavior appears consistent with a standard Teams bot invocation flow rather than a Copilot-mediated execution path.

Could you provide any technical insight into what might explain this behavior? For example, was there a recent change in enforcement policies, token validation mechanisms, execution routing logic, or overall service configuration that could account for this discrepancy?

Hi Dinakar

Good day.

There was a product group ticket reporting issue on accessing agents deployed in teams. will check the status on that ticket and do minimal replication at my side to be on same page.

Debugging

We normally look into bot service logs /application insights/ storage log analytics workspace.

You can probably enable diagnostics and leverage Kusto queries to isolate the issues.

Most of the times issues relates to

1. Tool invocation (you can test without custom MCP /MCP to isolate the issues)
2. Admin consent
3. Identity and permission issue
4. Network whitelisting (if VNET protected)
5. or Backend issue on Entra level

Relevant Troubleshooting guide for reference.

Please check Authentication capabilities and Agent Identity documentation for unattended access too.

Thank you