Match agent hosting to operating demands

Learning objective

Compare hosting options against scalability, reliability, operational efficiency, isolation, and cost.

Core idea

Choose a host by the workload you must operate, not by whether it can run your code. Compare five operating requirements against concrete platform controls and responsibilities.

See 1.2.1 for choosing prompt agents, hosted agents, and workflows by control and extensibility. This lesson starts after that choice: which hosting model can meet the expected concurrency, recovery target, operational capacity, security requirements, and budget? A multi-agent solution can use different hosts for its orchestrator, interactive specialists, and event-driven tools.

How it works

Identify the scaling unit

Microsoft Foundry hosted agents are generally available. They run custom code in per-session VM-isolated sandboxes, and the platform owns scaling and lifecycle management. Scaling is per session, not per replica: each session receives its own sandbox. The CPU and memory allocation on an agent version therefore describes one session, not all concurrent users.

The documented sandbox combinations are 0.5 vCPU with 1 GiB, 1 vCPU with 2 GiB, and 2 vCPU with 4 GiB. Billing reflects CPU and memory consumed across active sessions. If you select a larger size to accommodate one exceptional interaction, that allocation also affects the other active sessions. Measure representative resource peaks before increasing the version’s size.

Azure Container Apps instead scales replicas of an app revision through Kubernetes Event-driven Autoscaling (KEDA). Rules can use HTTP concurrency or event sources such as queue messages. Its scaling configuration defines minimum and maximum replicas; changing scaling rules creates a revision. A minimum of zero permits idle compute to disappear, while a minimum of one or more keeps instances running to reduce startup exposure.

The scaling unit is the difference: each Foundry session receives its own sandbox, while Container Apps scales replicas of an app revision.

Azure Functions scales through its hosting plan and trigger model. The function app is generally the scaling unit, with per-function scaling on Flex Consumption. Azure App Service scales at the App Service plan level. Azure Kubernetes Service (AKS) provides per-deployment scaling with Horizontal Pod Autoscaler (HPA) or KEDA, plus node capacity management. Compare these units when specialists need independent scaling.

Design recovery around interruptions

Foundry hosted agents deprovision idle sandbox compute and restore session state on resume. The idle timeout ranges from 2 through 60 minutes and defaults to 15 minutes; the platform permanently deletes a session after 30 days of inactivity. There is no replica count or warm pool to configure. Treat this as a documented session lifecycle, not permission to leave a business transaction halfway through an external write. See 1.2.5 for the stores that hold durable business and workflow state.

Container Apps provides health probes and supports zone redundancy. Enable zone redundancy when creating the environment in a supported region; you cannot enable or disable it afterward. To migrate an existing environment, create a zone-redundant environment and redeploy the apps. Size minimum replicas and resource requests for the capacity you must retain during failures. Replicas still need time to start and pass readiness checks. Container Apps does not replicate application data between zones, and ephemeral replica storage disappears when the replica stops. Compute redundancy and durable data are separate requirements.

Functions has two different clocks. The functionTimeout property in host.json limits function execution, while an HTTP-triggered function has a maximum response time of 230 seconds regardless of that setting. The legacy Consumption plan has a five-minute default execution timeout and ten-minute maximum; Linux Consumption is retired. For new serverless function apps, use Flex Consumption: its execution timeout defaults to 30 minutes with no enforced maximum, subject to a 60-minute grace period during scale-in and 10 minutes during platform updates. For long agent work, use the Durable Functions asynchronous pattern or return an immediate response and defer processing instead of extending the HTTP request indefinitely.

Account for operational ownership

Container Apps offers microservice capabilities without direct Kubernetes API access or cluster management. It is a candidate for containerized agent services that need independent scaling and revision-based traffic splitting but do not require Kubernetes control-plane access.

App Service suits straightforward web applications and HTTP APIs. Functions supplies triggers and bindings for event-driven work. AKS fits requirements for direct Kubernetes APIs, custom service mesh configuration, node pools, or scheduling controls. Those controls introduce operational work: the team must understand the cluster configuration and the associated deployment and observability tooling.

Foundry hosted agents move endpoint, sandbox lifecycle, scaling, and session management to Agent Service. You retain responsibility for agent code and application quality. Managed infrastructure does not decide whether a specialist is stuck, a tool result is valid, or a repeated external action is safe. Monitoring those outcomes belongs to the application design in 1.2.8.

Compare isolation and cost together

Foundry’s per-session VM isolation separates sessions at the compute layer. App Service Environment (ASE) provides full compute isolation and secure network access for App Service and Functions on a Dedicated (App Service) plan. Container Apps environments provide a secure grouping for apps and networking configuration; separate managed identities constrain each service’s downstream access. AKS offers control over networking and scheduling, but those controls require a deliberate configuration. Do not interpret a separate deployment, replica, or container as proof that every tenant’s data and permissions are isolated. See 1.2.3 and 1.2.4 for identity and compliance controls.

Estimate host cost from the traffic pattern and recovery configuration. Scale-to-zero reduces unused compute, but minimum replicas and prewarmed or always-ready instances trade idle capacity for latency. Consumption-based Container Apps and Functions on Flex Consumption can fit intermittent traffic; dedicated compute such as AKS can be more cost-effective under sustained load. Measure model calls, stores, telemetry, and operating effort alongside compute.

Key distinctions and trade-offs

The following distinctions decide the operating model:

Availability is an end-to-end property. More orchestrator replicas do not increase a downstream model’s quota, repair a failing tool, or make local state durable. Reliability requires those dependencies to satisfy the same operating target.

Architecture / decision scenario

A claims service has interactive conversations, bursty document intake, and a specialized container that requires custom Kubernetes scheduling. The team assesses each component separately.

It considers Foundry hosted agents for the interactive specialists because per-session VM isolation and platform-managed lifecycle match their execution model. It tests the documented sandbox sizes against expected concurrent sessions and includes idle-time behavior in its latency measurements. Shared claim records remain in the selected durable store, outside the session lifecycle.

Document intake uses Functions triggers for intermittent arrivals. A request returns promptly while processing continues asynchronously, so a long analysis does not depend on the 230-second HTTP response limit. The scheduling-dependent service uses AKS because direct Kubernetes control is a requirement. A containerized orchestration service without that requirement can use Container Apps with KEDA rules, readiness probes, and zone redundancy.

The final comparison includes retained capacity during failure, managed identities, workload isolation tests, deployment effort, and measured compute and model usage. Use multiple platforms only where requirements justify the operating cost.

Common exam traps

• Treating Foundry session scaling as a configurable replica pool.
• Assuming a Functions execution timeout also extends the HTTP response limit.
• Choosing AKS because Container Apps uses Kubernetes internally, without needing Kubernetes API access.
• Equating separate containers with complete tenant isolation.
• Counting scale-to-zero savings without cold starts or minimum capacity.
• Assuming compute redundancy also replicates application state or increases model quotas.

What to remember

Compare the scaling unit, recovery mechanism, operating owner, isolation controls, and full cost for each component. Foundry manages session sandboxes; Container Apps manages app replicas; Functions follows its plan and triggers; App Service follows its plan; AKS supplies Kubernetes control. Choose retained capacity and durable state deliberately, then validate the choice under realistic concurrency and failure.

Knowledge check

References

• Microsoft, Hosted agents
• Microsoft, Host agents on Microsoft Foundry
• Microsoft, Choose a compute option for microservices
• Microsoft, Set scaling rules in Azure Container Apps
• Microsoft, Azure Functions hosting options
• Microsoft, Reliability in Azure Container Apps