Does hosting agents/workflows on Microsoft Foundry expose an endpoint? Or more than that?

[lichtjiang]

Sorry for asking this simple question. I am new to Microsoft Foundry and I want to try it out to host agents/workflows. But I have some confusion.

First of all, I want to stress the difference between an agent/workflow and an agent application here to avoid possible ambiguity or confusion for the purpose of discussion.

So, it's like your business logic (agent/workflow) vs user interface (agent application) where your customers interact with your business logic in a client-server architecture. In this sense, agents/workflows are backend while agent applications are frontend (a web application in many cases; although it can also be a backend that wraps calls to agents/workflows and tools in order to offer another layer of services/APIs). For certain user interaction, a typical agent application will send a request to run our agent/workflow and show the response.

With this difference on mind, what does agent hosting on Microsoft Foundry actually do? Does it work as a platform to run agents/workflows (the backend business logic) with observability, monitoring, security and governance benefits? Or Does it also give a web UI to interact with your agents/workflows (e.g. a playground may play this role)?

Suppose I built an agent or a workflow using Python SDK of Microsoft Agent Framework. Based on aforementioned difference, this means I have a bunch of agent and workflow definitions. I haven't built a frontend for it yet. So, no agent application (although you may have a typical test case in your if name == "main" block for a local test run).

Now I want to host this agent/workflow on Microsoft Foundry, what do I get? An endpoint?

Does hosting agents/workflows on Foundry also allows your agents to be discovered over A2A as agents and over MCP as tools? I mean is Microsoft Foundry an all-in-one service/platform that can be coded or configured to work as a compute resource to run your agents/workflows and orchestration, as a model provider, as A2A server and MCP server as well?

Next, I built an agent application (the client, maybe a web application in many cases, or another backend service) that interact with the agent/workflow. I guess I can host this application anywhere I want. But if it is a backend service itself, can it be deployed to Microsoft Foundry as well to stay close to the agent/workflow?

Any answer or insight will be helpful. Thanks in advance.

[Klay (Shyboy0499)]

Short answer: yes — a hosted agent/workflow is invoked over an endpoint, and an agent application is the UI/copilot layer that wraps it. They're separate things you deploy together.

In Microsoft Foundry (Azure AI Foundry):

• Agent/workflow = the orchestration logic (system prompt, tools, the graph). You deploy it as a Foundry agent, and it's callable programmatically via the Azure AI Foundry SDK or its REST chat/completions endpoint. That's your "endpoint."
• Agent application = the front-end where customers interact (web chat, Teams app). It authenticates the user and calls the same underlying agent endpoint.

So hosting an agent does expose an endpoint — that endpoint is what the agent application (or any client) calls. You don't have to build a UI at all; you can consume the endpoint from your own app.

Two clarifications that trip people up:

1. Workflow vs agent: if you built a Foundry workflow (a graph), it also runs server-side and can be invoked; the distinction mostly affects which SDK surface you use, not whether an endpoint exists.
2. Auth: the endpoint requires a valid identity/token — it's not anonymous. That's the main difference between calling it from your own script vs. through the agent application, which handles user auth for you.

Fastest way to "try it": deploy a simple agent in the portal, grab its endpoint, and call it from a notebook with the Foundry SDK — you'll see it's just a normal HTTP call. Then the agent application becomes an optional UI on top.