Azure AI Foundry Agent Service frequently asked questions

Yes. Foundry Agent Service is a stateful API, meaning it retains data. There are two types of data stored in the Foundry Agent Service API:

• Stateful entities: Threads, messages, and runs created during usage.
• Files: Uploaded during Foundry Agent Service setup or as part of a message.

Basic Setup: Data is stored in a secure, Microsoft-managed storage account that is logically separated.
Standard Setup: Data is stored in your own Azure resources, giving you full ownership and control.

All used data persists in this system unless you explicitly delete this data. Use the delete function with the thread ID of the thread you want to delete. Clearing the Run in the Foundry Agent Service Playground doesn't delete threads, however deleting them using delete function won't list them in the thread page.

Today we support CMK for Threads and Files in Foundry Agent Service.

No. Data isn't used by Microsoft for training models. See the Responsible AI documentation for more information.

Azure AI 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.

• Inference cost (input and output) of the base model you're using for each Agent (for example gpt-4-0125). If you've created multiple agents, you'll be charged for the base model attached to each Agent.
• If you've enabled the Code Interpreter tool - for example your agent calls Code Interpreter simultaneously in two different threads, this would create two Code Interpreter sessions, each of which would be charged. Each session is active by default for one hour, which means that you would only pay this fee once if your user keeps giving instructions to Code Interpreter in the same thread for up to one hour.
• File search is billed based on the vector storage used.

For more information, see the pricing page.

No. All quotas apply to using models with Foundry Agent Service.

Virtual networks secure the inbound and outbound access of your Azure resources, preventing bad actors from accessing your resources. Network isolation is achieved through virtual network integrations in Azure. This is a fundamental requirement for security in enterprises. To learn more about virtual network isolation, see Virtual network integration of Azure services for network isolation and What is Azure Virtual Network?

Both the Agent client and compute run on Azure Container Apps (ACA). When you run the Agent client and the associated compute on Azure Container Apps (ACA) inside an existing virtual network, you must supply a dedicated subnet delegated to Microsoft.App/environments.

1. Delegation pins them to the right subnet. It tells Azure exactly where to “inject” the Agent client so ACA can create network interfaces there.
2. ACA then applies the needed plumbing - IP addresses, routing, NSGs, and service-managed identity wiring, is configured automatically.
3. Without the delegation, ACA refuses to deploy, so neither the Agent client nor the compute layer could join your Virtual Network, breaking isolation, and compliance requirements.
   In short, delegating the subnet is the prerequisite that lets ACA, and therefore your Agent runtime, live inside your private network with the correct security and routing policies in place and in your control.

Supported regions: West US, East US, East US 2, Japan East, France Central, UAE North, South Central US, Italy North, Germany West Central, Brazil South, South Africa North, Australia East, Sweden Central, Canada East, West Europe, Spain Central, UK South

Only private class A, B, and C ranges are supported. No public class ranges are supported.

The recommended subnet size is /24 (256 address) and is what we default to in our templates. The minimum subnet size is /27 (32 addresses). The reason why /24 is recommended is because of the runtime impact in the event of a container update, listed in the ACA documentation. For more information, see Configuring virtual networks Azure Container Apps environments.

We set an IP range per Azure AI Foundry account. Each project gets an IP from the range. There isn't IP address set per Agent, but per project. This means there's no limit to the number of agents to create within your project. The user isn't limited by the minimum address space of the subnet to create any number of agents.

As long as there's address space for Agent subnet and private endpoints, then virtual network address range can be anything.

Yes this is feasibly possible since the virtual network is in your subscription, and you should be able to peer with any virtual network. But data transfer is quite costly so it isn't recommended to do this. The requirement is all resources must be in the same region as the Foundry resource.

Yes, allowlist the Fully Qualified Domain Names (FQDNs) listed **Managed Identity in the Use Azure Firewall with Azure Container Apps article or add the service tag AzureActiveDirectory. Verify no TLS inspection happens in the firewall that could be adding a self-signed certificate. During failures, inspect if there's any traffic landing on the firewall and what traffic is being blocked by the firewall.

Yes, a virtual network can be reused by multiple Foundry resources, but the Agent runtime subnet is per Foundry account.

No, the same resource group isn't needed, but the same region is required.

The template provides support for the built-in tools: Code Interpreter, File Search, Azure AI Search, Cosmos DB (all tools that use the Bring-Your-Own (BYO) resource connections). To configure tools that require the creation of a new connection, you must create a private endpoint from your `peSubnet`` and create a private link from the Azure Resource.