You open Microsoft Foundry, choose a model, write instructions, attach a few tools, and create an agent. Then you discover Hosted Agents: agent applications built in code and deployed to Foundry.

Why would you choose the second approach? What does it give you that the agent you already created cannot do?

The difference is how much of the agent’s execution you control. With a prompt agent, you configure behavior that Foundry’s managed runtime executes. With a Hosted Agent, you supply the program that implements the behavior, and Foundry runs it.

Both approaches have a place in production. The architectural decision is deciding where configuration is sufficient and where your application needs direct control.

First, separate “portal versus code” from “prompt versus hosted”

The agent you create by selecting a model, writing instructions, and attaching tools is called a prompt agent.

You can create that same kind of agent programmatically through an SDK or REST API. Writing Python or C# to create it does not make it a Hosted Agent.

A Hosted Agent contains your own executable agent logic. You package that application for deployment, and Foundry provides the managed environment where it runs. Microsoft’s agent overview

The portal is an authoring surface. Hosted Agents are an execution model. Those are different decisions. Compare agent types

A prompt agent can already do useful work

Consider a customer-support agent with access to product documentation and an order-status tool.

A customer asks, “Where is my order?” The agent can call the tool, interpret the response, and explain the delivery status. If the customer asks a follow-up question, the conversation can preserve the earlier context.

Foundry combines the agent’s configuration, conversation history, model interactions, and tool results. Tools extend the agent beyond generating text: they let it retrieve information and interact with external systems. Foundry runtime components

For many applications, this is exactly the right level of abstraction. You concentrate on instructions, tool quality, and evaluation instead of maintaining a custom agent application.

The question becomes more interesting when the sequence of work matters as much as the final answer.

Where a Hosted Agent becomes valuable

Imagine a supplier-selection assistant.

Initially, it needs to find suppliers, compare prices, and explain a recommendation. A prompt agent with appropriate tools is a reasonable starting point.

Then the requirements grow:

1. Retrieve information from three systems.

2. Run independent lookups concurrently.

3. Exclude suppliers that fail eligibility checks.

4. Use one model for extraction and another for analysis.

5. Validate that every recommendation has supporting evidence.

6. Save progress while waiting for purchasing approval.

7. Submit an order only after that approval is recorded.

This example describes an application you would design; deploying a Hosted Agent does not automatically implement these steps.

What hosting gives you is a place to run the code that controls them. You can choose a framework such as Microsoft Agent Framework or LangGraph, implement branches and validation, and coordinate model and tool calls.

Hosted Agents also support custom dependencies, supported CPU and memory allocations, persistent session files, and protocols for interactions beyond conventional chat. Foundry supplies the surrounding endpoint, identity, scaling, and hosting infrastructure. Hosted-agent capabilities

The practical benefit is being able to express a requirement such as “validate eligibility before requesting approval” as an explicit execution path.

Custom business rules do not automatically require a Hosted Agent

There is a useful middle option: put strict rules inside the tools a prompt agent calls.

Suppose an agent can request a purchase. The purchasing API can reject every request that lacks a valid approval record. That rule remains enforceable regardless of what the model says.

This leads to a useful design question:

Does the logic belong inside one business operation, or does it coordinate the entire process?

If it belongs inside an operation, a prompt agent calling a well-designed tool may be sufficient. If it coordinates branching, retries, checkpoints, and multiple participants across the process, a Hosted Agent becomes more attractive.

For the supplier example, I would keep purchase authorization in the purchasing service even if a Hosted Agent coordinates the broader workflow.

Conversation history and workflow state are different

Remembering what a user said is different from remembering which parts of a business process have completed.

A supplier-selection workflow might need to preserve:

• The suppliers already checked.

• Evidence supporting each recommendation.

• The current approval status.

• A reference to an order already submitted.

Hosted-agent code can explicitly save this information. Microsoft’s durable state store provides storage for application data and framework checkpoints that survive container restarts. Your application decides what to write and when. An application-owned database or storage service is another option.

The durable state store is currently documented as preview. It does not automatically discover or preserve your application’s meaningful progress. Durable state store documentation

Long-running work still requires careful application design

Two requirements often get mixed together:

• Continuing work after the initiating request disconnects.

• Recovering work after the hosting process stops.

Background execution addresses the first. Resilient execution addresses the second.

Foundry’s hosted-agent resilience capabilities can preserve execution information and allow a handler to run again after an interruption. Your application still needs checkpoints or a safe way to repeat the work.

That distinction matters when actions have consequences. Recovering a purchasing workflow must not accidentally submit the same order twice.

Microsoft currently documents these resilience capabilities as preview. Hosting alone does not make an arbitrary workflow recoverable or guarantee that an external action happens exactly once. Long-running agent resilience

What changes for your development team?

A prompt agent can be edited and tested through the portal. Its configuration can also participate in a development pipeline.

For a Hosted Agent, changes to agent logic happen in the application code and are deployed as new versions. The portal still supports invoking, evaluating, monitoring, and publishing the agent, but it does not replace your development environment.

Versioning, evaluation, monitoring, and publishing are available across the agent lifecycle. You do not need to choose Hosted Agents merely to adopt disciplined production practices. Agent development lifecycle

Choose based on the control you need

My recommended starting points are:

A useful test is to finish this sentence:

“I need my program to control ______ during the agent’s execution.”

A specific answer, such as model routing, checkpoint recovery, or coordination between specialist agents, gives you a concrete reason to evaluate Hosted Agents.

If your requirements are met by instructions, knowledge, and tools, a prompt agent can remain the right production architecture.

Need help choosing an approach or building the skills to implement it? Connect with The Training Boss for enterprise AI architecture and hands-on training.