Foundry Agent Service frequently asked questions

Basic setup stores agent state in Microsoft-managed resources.

Standard setup stores agent data (threads, files, and vector stores) in your Azure resources that you declare through capability settings.

To compare setup options and choose the right one, see Set up your environment and Configure agent capability settings.

Role requirements depend on what you're doing. Common roles include:

• Foundry Account Owner: Create accounts and projects
• Foundry User: Create and edit agents
• Role Based Access Control Administrator (or Owner): Required for standard setup to assign roles to connected resources

For standard setup, you also need the Microsoft.Authorization/roleAssignments/write permission.

For complete role requirements, see Required permissions and Role-based access control (RBAC) in Microsoft Foundry.

Start with Set up your environment, then create your first agent.

• Quickstart: Create a new agent
• New Foundry experience: Quickstart: Get started with agents in code

Voice-first agents are a type of prompt agent for real-time spoken conversations. Use them when users speak to the agent and hear spoken responses instead of primarily typing and reading text.

Voice-first agents use the same core Agent Service concepts as other prompt agents, including projects, saved agent versions, tools, identity, tracing, and monitoring. They can also have voice-specific model, audio, channel, and preview availability requirements.

For more information, see How voice-based agents work.

Yes. Foundry Agent Service is a stateful API, which means that it retains data. Two types of data are stored in the Foundry Agent Service API:

• Stateful entities: Conversations and responses created during usage.
• Files and vector stores: Data uploaded during Foundry Agent Service setup or as part of a response generation.

To learn how conversations and responses work, see Agent runtime components.

• Basic setup: Data is stored in a secure, Microsoft-managed storage account that's logically separated.
• Standard setup: Data is stored in your own Azure resources, so you have full ownership and control:
  • Azure Storage: Files and attachments
  • Azure Cosmos DB: Threads and conversation history
  • Azure AI Search: Vector stores

To learn about setup options that control where data is stored, see Set up your environment.

Data persists unless you explicitly delete it. To delete agent data, use the API or SDK to delete threads, files, or vector stores.

For concepts and terminology (for example, conversation and response), see Agent runtime components.

• Basic setup supports Microsoft-managed keys only.
• Standard setup supports customer-managed keys (CMKs).

For coverage details across Foundry capabilities, see Customer-managed key encryption in Microsoft Foundry.

No, Microsoft doesn't use your data for training models. For more information, see the Responsible AI documentation.

Foundry Agent Service endpoints are regional, and data is stored in the same region as the endpoint. For more information, see the Azure data residency documentation.

• You're charged for inference cost (input and output) of the base model that you're using for each agent (for example, gpt-4-0125). If you created multiple agents, you're charged for the base model attached to each agent.

• If you enabled the Code Interpreter tool, you're charged for its use per session. For example, if your agent calls Code Interpreter simultaneously in two threads, this activity creates two Code Interpreter sessions. Each of those sessions is charged.

  By default, each session is active for one hour. If your user keeps giving instructions to Code Interpreter in the same thread for up to one hour, you pay this fee only once.

• File search is billed based on the vector storage that you use.

For more information, see the pricing page.

Charges and limits depend on the models, tools, storage, and runtime capabilities that your agent uses. Review the Microsoft Foundry pricing page and Agent Service limits, quotas, and regional support.

The Copilot harness is an optional managed runtime for prompt agents. Your resource remains a prompt agent and uses the Responses API. Foundry operates the harness and execution environment, so you don't deploy or maintain harness code.

For supported tools, skills, limits, and setup guidance, see Use the Copilot harness with prompt agents.

Foundry operates the harness and execution environment. Data can leave Foundry when you configure an external tool, connection, or endpoint, according to that service's terms and data-handling practices.

Bring your own model (BYOM) isn't currently supported with the Copilot harness.

No. During the initial public preview, you select the Copilot harness when you create a new prompt agent. You can't switch an existing agent or change the harness by creating another version.

Conversation history remains available when the selected agent version changes.

With the default prompt-agent behavior, the next response uses the selected version. With the Copilot harness, a new conversation uses the selected version immediately. An already-running execution environment isn't restarted, so capabilities initialized when it started can continue using the previous version. After the environment goes idle, the next interaction replaces it with the selected version and continues the same conversation. If the selected version can't be applied, the interaction fails instead of silently using another version.

Start a new conversation when you need a clean version boundary. For version-selection guidance, see Configure and share your agent.

Yes. A prompt agent that uses the Copilot harness can reference a versioned skill in the same Foundry project or discover skills attached to a compatible toolbox. For setup and versioning guidance, see Use skills in Foundry. For harness compatibility and limitations, see Use the Copilot harness with prompt agents.

Region, client, tool, networking, and quota support can be narrower than Agent Service generally. See Copilot harness limits and availability.

Start with Toolbox overview, then see the tool-specific guidance:

Declare those resources in the capability settings on your Foundry account or project.

• How-to: Configure agent capability settings
• How-to: Use your own resources

To understand usage and monitoring options, see Metrics and Monitor the service.

Agent Service BCDR guidance depends on your setup and the resources you provision. For the current guidance, see Foundry Agent Service disaster recovery.

Virtual networks help secure inbound and outbound access to your Azure resources. You achieve network isolation through virtual network integrations in Azure.

For Agent Service private networking requirements and limitations, see How to use a virtual network with Foundry Agent Service.

Agent Service networking uses Azure Container Apps. When you deploy into your virtual network, you must use a dedicated subnet delegated to Microsoft.App/environments.

For details, see How to use a virtual network with Foundry Agent Service and Virtual network configuration.

Region availability for virtual network isolation can change. For the current supported regions and limitations, see How to use a virtual network with Foundry Agent Service.

Only private IP ranges are supported:

• Class A: 10.0.0.0/8
• Class B: 172.16.0.0/12
• Class C: 192.168.0.0/16

Public IP ranges aren't supported for agent subnets.

The recommended delegated agent subnet size is /24. The minimum is /27.

For sizing guidance and how IPs are consumed, see How to use a virtual network with Foundry Agent Service and Virtual network configuration.

As long as the agent subnet and private endpoints have address space, the address range for virtual networks can be anything.

Yes. The virtual network is in your subscription, and you should be able to peer with any virtual network. But data transfer is costly, so we don't recommend it. The requirement is that all resources must be in the same region as the Microsoft Foundry resource.

Yes. Allow the required fully qualified domain names (FQDNs) for managed identity as described in Use Azure Firewall with Azure Container Apps, or allow the AzureActiveDirectory service tag.

For Agent Service private networking guidance, see How to use a virtual network with Foundry Agent Service.

Yes, multiple Microsoft Foundry resources can reuse the same virtual network. However, each Foundry resource requires its own dedicated agent runtime subnet—the agent subnet can't be shared across multiple Foundry resources.

They don't need to be in the same resource group, but they do need to be in the same region.

If you're using a network-secured setup, some tools require additional configuration, such as private endpoints and resource connections.

For the current guidance and limitations, see How to use a virtual network with Foundry Agent Service.

Next steps

• What is Foundry Agent Service?
• Set up your environment
• Quickstart: Create a new agent
• Toolbox overview
• How to use a virtual network with Foundry Agent Service