Azure AI Foundry Hosted Agents Add Source-Code Deployment Path

Microsoft has added source-code deployments for Foundry Hosted Agents, giving Azure AI Foundry teams a second packaging model for hosted agent workloads. Previously, a Hosted Agent deployment depended on a container image, typically built by CI/CD, pushed to Azure Container Registry, then referenced by the agent version. The new option lets teams deploy a .zip artifact and define a code_configuration instead of a container_configuration.

That sounds like a packaging detail, but it changes the operating model for enterprises building agents. Many application teams already understand source packaging, GitHub Actions artifacts, dependency manifests, and runtime entry points. Fewer teams are equally mature with container image builds, registry governance, base image patching, image scanning, and multi-stage Dockerfile maintenance. Microsoft is not removing the container path. It is adding a lighter deployment route for agents that do not need full image-level control.

The announcement fits into the broader Azure AI Foundry direction, where Microsoft wants agent development, model selection, deployment, and operations to live inside a managed platform rather than a collection of hand-built services. For cloud strategy leaders, the useful framing is simple: source-code Hosted Agents are not a replacement for containerized AI workloads. They are a lower-friction on-ramp for teams whose agent code is small, dependency-light, and better governed through application pipelines than container supply chains.

What changed

A Foundry Hosted Agent runs inside a Microsoft-managed Micro-VM sandbox. That abstraction matters because the platform owns the compute envelope that runs the agent, while the customer controls the agent definition, model deployment reference, code package, runtime settings, and related configuration. In the earlier container model, the Micro-VM fetched a container image from Azure Container Registry and ran that image as the executable unit.

The new source-code model changes the artifact that gets attached to an agent version. Instead of publishing an image, the deployment posts a ZIP file to the Foundry data plane. The agent version then points to source-code metadata: runtime, entry point, dependency resolution behavior, CPU, memory, environment variables, and the model deployment name. The process described in Microsoft’s Community Hub post is essentially: package the code, create or update an agent version, poll until the version becomes active, then invoke the agent.

The key technical distinction is that code_configuration and container_configuration are mutually exclusive for a single version. A team chooses one deployment model per version. A source-code agent is still a Hosted Agent, but the operational contract changes. You no longer need a Dockerfile, image build, registry push, and image reference for the simplest deployments. You do need a clean ZIP artifact, a supported runtime such as Python, an entry point such as main.py, and a dependency resolution strategy.

This also keeps infrastructure provisioning separate from agent version deployment. If a company uses Bicep, Terraform, or PowerShell to provision the Foundry project and supporting Azure resources, those infrastructure templates may not need major changes simply because the agent packaging format changed. The source-code deployment is a data plane operation against the Foundry project. That distinction is useful for platform teams because it allows infrastructure ownership and application release ownership to remain separate.

Microsoft’s example also shows how this can be automated with GitHub Actions. A workflow can create a ZIP artifact, authenticate to Azure, call the Foundry REST endpoint, upload metadata and code as multipart form data, then poll for active status. The action exposes the new agent version as an output, which can feed later deployment, test, or release steps.

For teams using the Azure Developer CLI, Microsoft also shows a command pattern using azd ai agent init with --deploy-mode code, a runtime, and an entry point. That is a convenient developer path, but the more strategic point is that source-code Hosted Agents are not tied to a single deployment tool. REST API calls, SDK-based deployment, and CI/CD automation remain viable options.

Provider comparison

Azure’s move should be compared against how the major cloud providers are packaging and operating agent workloads, not just against how Azure itself handled Hosted Agents last month.

On Azure, the main choice is now between source-code Hosted Agents and container-based Hosted Agents inside the Azure AI Foundry documentation. Source-code deployment favors speed, simpler CI/CD, and less container expertise. Container deployment favors maximum runtime control, custom binaries, pinned base images, native libraries, and enterprise container governance. If your agent is a Python service with a small dependency graph, ZIP packaging may be enough. If it relies on system packages, custom certificates, specialized network tooling, or strict image scanning policies, containers remain the cleaner fit.

AWS approaches agent deployment from a different angle. Amazon Bedrock Agents centers the agent abstraction around model orchestration, tools, knowledge bases, and action groups. For custom execution, teams often connect Bedrock Agents to AWS Lambda functions or other AWS services. That makes AWS attractive when agent actions are naturally decomposed into serverless functions, event-driven workflows, and IAM-scoped service calls. The trade-off is that the application runtime is often spread across agent configuration, Lambda code, API schemas, and supporting services. Azure’s Hosted Agent model, by contrast, makes the agent runtime itself a managed executable unit.

Google Cloud’s comparable direction is split between Vertex AI Agent Builder, Vertex AI, Cloud Run, and Cloud Build. Google’s strengths show up when teams want managed search, grounding, model orchestration, and container-native deployment through Cloud Run. Cloud Run is especially strong for stateless services with clear HTTP contracts and containerized runtime control. Azure’s new source-code path is more opinionated toward Foundry-hosted agent execution, while Google’s common path often keeps the runtime as a service that the team packages and exposes.

The strategic comparison is not that one provider has a universally better model. The question is where your enterprise wants the boundary between platform responsibility and application-team responsibility.

Azure source-code Hosted Agents shift more packaging responsibility to the platform. Developers provide source, runtime hints, and an entry point. The platform handles the hosted execution environment. Azure container Hosted Agents give developers and platform engineers more control, but also more artifact-management work. AWS Bedrock with Lambda gives strong service integration and cost isolation, but the runtime may be fragmented across functions. Google Cloud Run gives portable container execution and mature traffic controls, but the agent orchestration layer and runtime layer may be separate architectural concerns.

Pricing needs the same comparative treatment. With Azure source-code Hosted Agents, teams should model four cost areas: model inference, Hosted Agent compute allocation, build or dependency resolution time, and storage or artifact retention. Source-code deployment may reduce Azure Container Registry storage and image build overhead for simple agents, but it does not remove model token costs or runtime compute costs. With container Hosted Agents, add registry costs, image scanning tools, base image maintenance, and build minutes. Azure’s current pricing entry points are best checked through the main Azure pricing page because AI service and regional pricing can change.

On AWS, pricing is usually distributed across Bedrock model usage, Lambda invocations and duration, API Gateway if used, storage, logs, and any retrieval components. On Google Cloud, the bill may include Vertex AI usage, Cloud Run CPU and memory, Cloud Build minutes, Artifact Registry storage, logging, and data services. The practical difference is that Azure’s source-code model may simplify chargeback for small agents because the runtime is closer to the Foundry agent abstraction. AWS and Google may provide more granular service-level cost visibility, but that can also require more FinOps mapping.

Migration considerations

The first migration question is whether an existing container-based Hosted Agent actually benefits from becoming a source-code deployment. If the container is only wrapping a Python script, a requirements file, and a simple entry point, migration is likely attractive. The team can remove the Dockerfile, skip registry publishing, and turn the release artifact into a ZIP generated by GitHub Actions or another pipeline. That can make development environments and production packaging look more alike.

If the container includes OS packages, browser automation, GPU-specific libraries, private package manager configuration, custom runtime hardening, or internal certificate handling, source-code deployment may not be the right target. A ZIP artifact is simpler precisely because it delegates more runtime construction to the platform. That delegation is useful until the workload needs details the platform does not expose.

Dependency management deserves special attention. Microsoft’s example uses a dependency_resolution value such as remote_build, which means the platform participates in resolving dependencies for the uploaded source. That can reduce local build complexity, but it also introduces questions platform teams should answer before standardizing on the pattern. Which package indexes are reachable? How are private packages authenticated? How are dependency versions pinned? How are failed builds diagnosed? How are software supply chain controls applied when there is no container image to scan?

A sensible migration plan starts with a low-risk internal agent. Package the current source directory as a ZIP, define the runtime and entry point, deploy a parallel -src agent version, then compare behavior against the containerized version. Measure cold start behavior, dependency install time, active-version deployment latency, memory consumption, and failure diagnostics. Do not migrate a business-critical agent purely to reduce CI/CD steps until observability and rollback are proven.

Governance also changes. Container governance is familiar to many security teams: approved base images, vulnerability scanning, signed images, registry policies, and promotion between environments. Source-code governance needs equivalent controls: signed release artifacts, dependency lock files, software bill of materials where possible, restricted deployment identities, review gates, and retention policies. The artifact changed, but the audit requirement did not.

For multi-cloud organizations, portability is another consideration. Containers remain the most portable packaging unit across Azure, AWS, Google Cloud, Kubernetes, and on-premises platforms. A ZIP-based Foundry Hosted Agent is easier inside Azure Foundry, but less portable outside that service boundary. That does not make it a bad choice. It means architects should classify agents by portability requirement. Internal productivity agents tightly coupled to Azure AI Foundry may be good source-code candidates. Customer-facing agent services that may move across clouds or run on Kubernetes may still justify containers.

Business impact

The business value is speed with fewer platform prerequisites. Source-code Hosted Agents make Azure AI Foundry more accessible to teams that are ready to build agents but not ready to operate a container delivery chain. That matters in large organizations where AI adoption is often gated less by model access and more by deployment process, security review, and ownership boundaries.

From a cloud strategy perspective, this feature gives Azure a stronger story for progressive maturity. A team can begin with source-code packaging, prove the agent pattern, then move selected workloads to containers when runtime control becomes necessary. That is better than forcing every team into the heavier path from day one. It also lets platform engineering define two paved roads: a standard ZIP deployment for simple agents and a container deployment for advanced agents.

The pricing impact will vary by workload. Some teams may see lower pipeline and registry overhead because they no longer build and store images for every small agent. Others may see little change because model inference dominates the cost profile. The real savings may be operational rather than purely financial: fewer Dockerfile issues, fewer registry permissions, fewer base image updates, and simpler developer onboarding. Those savings are meaningful, but they should be tracked as cycle time, failure rate, and support burden, not just cloud invoice deltas.

The risk is fragmentation. If every team invents its own ZIP layout, dependency policy, action wrapper, and naming convention, the organization simply trades container complexity for source-package sprawl. Platform teams should publish a standard GitHub Action or reusable workflow, define required metadata, enforce artifact naming, and document when to choose source code versus containers. Microsoft’s sample action is a useful pattern because it packages the deployment flow into a repeatable step: create metadata, upload the ZIP, poll until active, and expose the version ID.

The provider comparison also affects sourcing decisions. Enterprises standardized on Azure AI Foundry now have a more approachable agent deployment model. Enterprises split across AWS and Google should treat this as an Azure-specific convenience, not a universal packaging standard. For workloads that must stay cloud-portable, containers remain the safer long-term unit. For workloads that are intentionally Azure-native, source-code Hosted Agents can reduce friction and help teams ship useful agents faster.

The practical recommendation is to adopt the feature selectively. Use source-code deployments for small to medium Azure Foundry agents with clear runtime requirements, pinned dependencies, and simple entry points. Keep containers for agents with custom system dependencies, strict portability requirements, or mature image governance. Build both paths into the platform catalog, then let workload characteristics decide the packaging model.

Microsoft’s update does not change the strategic question every cloud team faces with agent platforms: how much of the runtime do you want the provider to manage? Source-code Hosted Agents move that boundary further toward Azure AI Foundry. For many enterprise agent workloads, that is exactly the right trade.