Microsoft Foundry Agent published to Teams via Bot service

Hi Nimesh,

Thanks for sharing the details and screenshots, the behavior you’re seeing is a known pattern when a Foundry agent is accessed through different channels like Playground, Copilot, and a standalone Teams app.

What’s happening here is that your agent is behaving correctly, but the retrieval step (RAG over Azure AI Search) is not consistently executing in the Teams custom app channel. Because you’ve configured the agent to answer strictly from internal knowledge bases, any retrieval failure results in “no data found,” even though the same prompt works elsewhere.

In Playground and Bot Service web chat, the agent runs in a context where the connection to Azure AI Search is fully preserved. In Copilot, Microsoft’s orchestration layer also ensures grounding works reliably. However, when you publish as a Teams custom app, the request flows through the Teams/Bot Framework channel, which can introduce differences in identity, permissions, and network access. If that channel cannot successfully query your Azure AI Search index, the agent receives no documents and returns an empty answer.

The most common cause is that the identity used by the Teams channel (managed identity or service principal associated with your Bot/agent) does not have sufficient permissions on the Azure AI Search service. I recommend going to your Azure AI Search resource in the Azure portal, opening Access Control (IAM), and assigning the appropriate role (for example, Cognitive Search Data Reader) to the identity used by your Bot/Teams integration. Once this access is in place, the agent should be able to retrieve documents consistently.

It’s also important to check networking. If your Azure AI Search service is secured with a private endpoint or restricted network access, the Teams channel may not be able to reach it unless the network path is explicitly allowed. In such cases, ensure that your configuration supports access from the channel (or consider testing temporarily with public access enabled to validate the root cause).

As a quick validation step, you can temporarily relax the “answer only from internal knowledge” restriction. If the agent starts responding in Teams (even with general knowledge), that confirms the issue is specifically with retrieval rather than the agent itself.

If the issue persists after permissions and network checks, reviewing the run traces in Foundry and Application Insights logs for your Bot Service will typically show whether the knowledge retrieval call is failing (for example, due to authorization or connectivity issues).

For reference, these Microsoft documents cover the relevant areas:

• Azure AI Foundry Agents overview https://learn.microsoft.com/azure/ai-foundry/agents/overview
• Retrieval-Augmented Generation with Azure AI Search https://learn.microsoft.com/azure/search/retrieval-augmented-generation-overview
• Azure Bot Service channels and authentication https://learn.microsoft.com/azure/bot-service/bot-service-channels-overview
• Microsoft Teams bot integration guidance https://learn.microsoft.com/microsoftteams/platform/bots/what-are-bots

In short, this isn’t an issue with your knowledge base itself, it’s typically a channel-specific access or connectivity gap affecting retrieval. Once the Teams channel can successfully reach and read from your Azure AI Search index, your custom Teams app should return the same grounded responses you see in Playground and Copilot.

Hope this helps!

Hello Nimesh,

Greetings!

Thanks for raising this question in Q&A forum.

Great question and this is a behaviour that trips up quite a few developers! The root cause here is about how the Teams standalone app sends messages to your Bot Service compared to how the Playground, Web Chat, or Copilot Chat does it. When your agent runs in the Foundry Playground or Copilot Chat, it has full access to session context, authentication tokens, and the Foundry IQ Knowledge Base connections. But when the same agent is published as a standalone Teams custom app via Bot Service, it goes through a different message pipeline — and the identity context, conversation metadata, and knowledge base query parameters can differ, causing the RAG search to return no results.

Here is a step-by-step guide to help you diagnose and fix this:

Step 1: Check the Bot Service Channel Authentication

In the Azure Portal, go to your Azure Bot resource → Channels → Microsoft Teams. Make sure the Teams channel is properly configured and that the Bot's Microsoft App ID and App Secret are valid and not expired. An authentication mismatch at the Bot Service layer can silently affect how downstream knowledge base queries are formed.

Step 2: Verify the Conversation Payload Reaching Your Agent

Enable logging on your Bot Service temporarily. Go to your Bot resource → Configuration and check if Application Insights is linked. Then trigger the failing prompt from Teams and inspect the incoming activity payload in Application Insights logs. Compare the message structure arriving from Teams vs. from Web Chat — differences in the channelId, locale, or missing properties can affect how the agent routes the query to the Knowledge Base.

Step 3: Review Your Agent's System Prompt for Context Dependencies

If your system prompt instructs the agent to "only answer from internal KBs" but the KB retrieval fails silently in Teams, the agent has no fallback and returns "no data found." Try temporarily relaxing this restriction to confirm the KB retrieval is indeed the failing part, not the agent logic itself.

Step 4: Check Azure AI Search Network and Authentication Settings

Go to your Azure AI Search resource → Networking. If it is set to restrict access to selected networks, the Bot Service may not have permission to reach it when the request comes through the Teams channel. Make sure the Bot Service's outbound IP or managed identity is allowed. Also confirm the Foundry IQ Knowledge Base connections use Managed Identity or a valid API key not a user-delegated credential that only works in interactive sessions.

Step 5: Compare the Query Being Sent to the Knowledge Base

In Foundry, go to your Agent's Tracing or Evaluation logs (if enabled) and run the same prompt from both Web Chat and the Teams app. Look at the actual search query being sent to the Azure AI Search index in each case. The Teams pipeline may be stripping or altering the query string before it reaches RAG, causing zero results.

Step 6: Test With a Simplified Knowledge Base Restriction

Temporarily change the agent so it searches both KBs instead of restricting to one. If responses start appearing in Teams, the issue is with how a specific KB is being selected in the standalone Teams context possibly a KB ID or connection name that isn't resolving correctly through the Bot channel.

Step 7: Re-Publish the Teams App After Any Configuration Change

Any time you update the agent's KB connections, system prompt, or Bot Service settings, you need to re-publish the app to Teams. Changes made in Foundry do not automatically reflect in an already-installed Teams custom app users may need to uninstall and reinstall the app, or you may need to re-upload the app manifest.

Step 8: Raise a Microsoft Support Ticket if the Issue Persists

Since the same agent works in Copilot Chat but not as a standalone Teams app, this points to a channel-specific behaviour that may need deeper investigation by the Foundry/Bot Service engineering team. Open an Azure Support Request and include your Bot resource name, Agent ID, the Teams app manifest, and side-by-side trace logs from both the working and failing scenarios.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.