Edit

Hosting Agent Framework applications

After you build an agent or workflow, first choose who operates its infrastructure. This is an operational choice between Microsoft-managed Foundry Hosted Agents and self-hosting; it is separate from the protocol that clients use to reach your agent.

Choose a hosting model

Foundry Hosted Agents Self-hosting
Who operates the infrastructure? Microsoft Foundry Agent Service runs the container, scaling, session lifecycle, and platform integration. Your application runs in your web service, container, runtime, or existing infrastructure.
What do you operate? Your agent code and Foundry configuration. Routes, identity, authorization, request policy, storage, deployment, scaling, and native client libraries.
Choose this when You want Microsoft-managed agent hosting. You need application-level control or must integrate with your existing infrastructure.
Start here Host an agent in Foundry Self-host an Agent Framework application

Microsoft Foundry Hosted Agents is generally available. The current Python self-hosting packages are prerelease; see the self-hosting guide for package-specific lifecycle information.

For Azure Functions triggers, durable execution, or long-running orchestration, use the Durable Extension. It is a self-managed hosting path with Durable Task infrastructure.

Choose a protocol separately

The hosting model does not determine the protocol. For example, the OpenAI Responses protocol works with both models:

  • Foundry Hosted Agents expose managed Responses and Invocations endpoints and support the Activity protocol for Microsoft 365 channels.
  • Self-hosting lets your application use the Responses helpers to expose a /responses endpoint with its own framework, routing, and policy.

After choosing a host, select the client integration that fits your scenario:

Next steps

Choose Foundry Hosted Agents

Go deeper:

  • Last updated on