Publishing Azure AI Foundry hosted agent to Teams breaks POST /assistants API — returns 200 with empty body

Hi Ockert Goosen,

What you are seeing is expected based on how Azure AI Foundry agents behave after publishing to Teams. This is not a SDK issue or something broken in your code.

When you publish a Foundry hosted agent to Teams or Microsoft 365 Copilot, the project is converted into an Agent Application. As part of this process, Foundry creates new identities and switches the runtime to the agent pipeline that is designed for Teams and Copilot. After this switch, the project‑level Assistants API is no longer the supported surface.

That is why POST /assistants starts returning 200 with an empty body. The call is effectively ignored because assistants are no longer meant to be created or managed at the project endpoint once the project is published. This also explains why the Playground and SDK stop working if they still depend on the project Assistants API.

After publishing, you should not use the project Assistants or Responses endpoints anymore. Instead, all traffic must go through the Agent Application endpoint that is created during publishing. This endpoint is the supported way to interact with the agent after it is exposed to Teams.

This endpoint is stable and continues to work after publishing. Make sure the caller identity has the Azure AI User role assigned on the Agent Application scope, not just on the project. Publishing creates a separate agent identity, so roles may need to be reassigned for tools or downstream access to keep working.

If you still need direct access to the Assistants API for testing or programmatic agent creation, the safest approach is to keep a separate Foundry project that is never published. Use that project only for Assistants API workflows and use a different project for Teams publishing. Once a project is published, it is expected to stay in the agent application mode.

In short, publishing to Teams changes the supported API surface. After publishing, always invoke the Agent Application endpoint, and avoid using POST /assistants on the original project.
I Hope this helps. Do let me know if you have any further queries.
Thankyou!

I think publish shifts the proj onto the agent‑pipeline, so POST /assistants goes silent… safest is to keep ur api on a clean never‑published proj.

The provided information does not document any interaction where publishing an agent to Microsoft 365 Copilot or Teams changes or breaks the Assistants/Responses APIs for a Foundry project, nor does it describe a supported workaround for the specific behavior of POST /assistants returning HTTP 200 with an empty body after publishing.

The documented and supported patterns are:

• Publish an agent as an Agent Application to obtain a stable endpoint, then invoke it via:
  • Responses API protocol, or
  • Activity protocol when published to Microsoft 365 Copilot or Teams.
• After publishing, invoke the Agent Application endpoint (Responses protocol) rather than the underlying project’s Assistants/Responses endpoints.
• When publishing to Microsoft 365 Copilot and Teams, the publishing flow configures the Activity protocol and creates an Azure Bot Service resource and identities (Agent Application identity) that are distinct from the project identity.

Key supported checks and mitigations from the documentation:

1. Verify publishing and runtime state
   • Confirm the Agent Application exists and the deployment is running.
   • For REST deployments, check the deployment state and start it if needed.
   • For Teams/M365 publishing, verify:
     • The agent shows as Published in Foundry.
     • Azure Bot Service resource exists and is running.
     • Any required Azure resource providers (for example Microsoft.BotService) are registered.
2. Use the Agent Application endpoint after publishing
   • For Responses protocol, call the Agent Application endpoint as shown:
     • POST https://<foundry-resource-name>.services.ai.azure.com/api/projects/<project-name>/applications/<app-name>/protocols/openai/responses?...
   • Ensure the caller has the Azure AI User role on the Agent Application scope.
3. Identity and RBAC after publishing
   • Publishing creates a separate agent identity; tools that access Azure resources may fail until RBAC is reassigned to this identity.
   • If tools fail after publishing, reassign the required roles to the published agent identity.
4. Teams/M365-specific troubleshooting
   • If the agent does not respond in Teams, verify the Azure Bot Service resource is running and check its logs.
   • If publishing fails or the package cannot be uploaded, follow the documented checks (metadata, app policies, admin approval, etc.).

The context does not describe:

• Any expected behavior where publishing to Teams changes the behavior of POST /assistants on the project endpoint.
• Any configuration switch or rollback procedure that restores the original Assistants behavior once affected.
• Any known bug or hotfix specifically tied to Assistants returning HTTP 200 with an empty body after publishing.

Given the constraints of the available documentation, the only supported path is to:

• Treat the Agent Application endpoint (Responses protocol or Activity protocol) as the stable, supported surface after publishing.
• Use the troubleshooting guidance for Agent Applications and Teams/M365 publishing to validate configuration, identity, and RBAC.
• Continue to work with Microsoft Support for the project-level POST /assistants behavior, as this is not covered in the referenced materials.

References:

• Publish and share agents in Microsoft Foundry
• Invoke your agent application using the responses API protocol
• Publish agents to Microsoft 365 Copilot and Microsoft Teams
• Microsoft Foundry publish to Teams Bot service error - Microsoft Q&A