Two environments can deploy the same AI agent code and still behave like different applications. The development project may use a different model deployment, a more permissive search index, a public endpoint or a broader identity role than production. A deployment report that says “succeeded” proves the infrastructure accepted a change. It does not prove the deployed agent can retrieve the right information, follow approval boundaries or answer under the expected latency budget. That distinction is central to engineering AI systems that survive their first real release.
A team can publish the correct agent code while still deploying the wrong application: a production project may point to a stale model deployment, a different index schema or a broad identity role. The Microsoft AI-103 deployment objective is best understood as a compatibility problem across versions, network boundaries and services. Treat the Foundry project, agent configuration, search dependencies and approval contracts as one tested release even when different teams manage their infrastructure separately.
The release unit is bigger than an agent
Imagine a claims-review assistant whose job is to explain policy exceptions and prepare a proposed decision for human approval. Its prompt and tool code may be stored in a repository, but correct behavior also depends on a search index containing the latest policy documents, a role that can read those documents and a case-management API that accepts only approved draft actions. A release that updates the agent while leaving an old search schema in place can fail even if every unit test passes.
Draw the runtime path before you decide what belongs in the deployment. The application authenticates to a Foundry project, invokes a deployed model, may call a tool through an agent runtime, and retrieves evidence from Azure AI Search or another knowledge source. Each boundary has a distinct endpoint, identity, quota, network policy and failure mode. The design choices outlined in Foundry service selection determine what that release actually needs to carry.
Do not bundle every dependency into one all-or-nothing script just because they communicate. Infrastructure with infrequent changes, such as network rules, may have a different approval path than a prompt or tool-schema update. What matters is recording the compatible versions and testing their interfaces together. A release manifest should tell an operator which agent version, model deployment, index schema, prompt set and access policy were evaluated as one coherent system.
Express the environment as something reviewable
Microsoft documents deploying Foundry resources and projects through Bicep. An infrastructure-as-code template can describe the resource and project alongside supporting infrastructure so that another environment does not depend on a series of remembered portal clicks. Parameters should express genuine differences such as location or naming, while core security and network expectations remain visible to reviewers. An exported portal template is a starting point, not proof that every related resource and role assignment was captured.
Review generated templates for embedded subscription IDs, project names, network addresses and permissions before reusing them. Keep credentials outside source control and provide deployment identities only the rights needed for the tasks they perform. For production applications, separate the identity that provisions resources from the identity used by the running service. Securing AI workloads includes proving which service principal can access each model endpoint and dataset; a successful network connection alone does not establish least-privilege authorization.
Infrastructure-as-code also creates a meaningful change record. If a proposed release opens a previously private endpoint or removes a network restriction, that change can be reviewed before it reaches the environment. A portal-only modification should be detected as drift rather than quietly accepted as the new baseline. The goal is not to eliminate every manual diagnostic action, but to ensure the durable production configuration returns to a documented state.
Make model and project versions explicit
A Foundry project is a coordination boundary, not a promise that all models work identically. Deployment names, available features, context lengths, regional availability and quota conditions can differ between environments. The application should select a documented model deployment through configuration rather than burying a resource-specific address in several modules. A staging environment that substitutes a cheaper model can be useful for simple smoke tests, but it cannot validate final model behavior.
Record model version, deployment type, prompt configuration, index schema and any non-default content-filter settings as part of a release candidate. These affect generated behavior even when application code stays unchanged. A request that passes through one model may produce different tool arguments or citations when a deployment is moved to another model family. That is an application compatibility concern, not merely a purchasing decision.
Feature status matters here. Hosted-agent deployment and some management tooling have had preview-specific paths, while ordinary Foundry project/resource provisioning follows its own documented process. Do not confuse a command shown for a particular preview with a universal requirement. The release design should follow the supported path for the exact runtime in use and keep its tooling version documented so a future SDK update does not silently rewrite the infrastructure model.
Use CI/CD to test behavior, not just syntax
A sensible pipeline begins with fast checks: static analysis, dependency validation, unit tests around tool adapters and infrastructure-template validation. It then runs integration checks against controlled resources. Tests should prove an agent receives the expected tool schema, an unauthorized principal cannot call a privileged API and a retrieval request yields evidence from the intended corpus. These checks reveal contract failures long before an end user encounters a fluent but incorrect answer.
The difficult gate is behavioral. Build a small set of representative scenarios with expected evidence and allowed actions. For a policy assistant, include a straightforward approval, an ambiguous exception, a deliberately stale document, an attempted instruction embedded in retrieved material and a case where the approval service is unavailable. The pipeline should inspect the tool-call trajectory and evidence provenance, not only the final text. AI observability and evaluation is the foundation for deciding whether a release actually improved results.
Authentication to the deployment pipeline should be short-lived where supported, for example through federated workload identity rather than a static cloud secret copied into repository settings. Provisioning privileges, application runtime privileges and audit permissions should be separate. A passing smoke request is useful but insufficient; the release gate needs assertions about status, tool access, retrieval freshness and observed safety behavior.
Coordinate agent, model and retrieval changes
Search pipelines have their own deployment cycle. An index change may add a field, modify an analyzer, alter chunk structure or replace embedding models. Any of these can change what the agent retrieves. If the application expects a field that the index does not yet expose, simply releasing the agent first creates a narrow but real period of broken grounding. Use compatibility windows or a versioned index to keep old and new readers working while data is reprocessed.
Tool contracts deserve the same care. Adding a required JSON field to an API tool or changing what an approval response means may be harmless to the service author but breaking to an existing agent. Test backward compatibility using recorded tool calls, including invalid and partial responses. A multi-agent system creates even more dependency edges, which is why Multi-agent orchestration benefits from explicit handoff contracts rather than informal shared context.
For high-value workflows, classify changes by risk. Adjusting the wording of a low-impact summary prompt may permit a lighter validation path than changing a tool that can issue refunds or modify customer records. The release manifest should mark actions that require approval, the identities that may execute them and the test evidence demonstrating that the guardrails still hold.
Roll out carefully and preserve conversation continuity
A release can be technically correct and still disrupt active conversations. An agent may carry a state representation that a newer version interprets differently, or a resumed workflow may discover that a tool has changed its parameters. Decide whether existing sessions remain pinned to their original version, can migrate through a tested conversion, or must finish before a new revision receives traffic. That decision should be explicit rather than an accidental effect of deployment.
Use a staged rollout when the application warrants it: internal test users, a limited live traffic slice, and broader exposure after monitoring confirms acceptable quality. Compare safety flags, action failures, evidence coverage, token consumption and p95 latency between the candidate and a trusted baseline. Avoid judging success by one anecdotal conversation; agent behavior is probabilistic and difficult edge cases require purposeful sampling.
A rollback plan must restore compatible application behavior, not just a code commit. If a new agent depends on an updated index schema, rolling back the agent without retaining the old index may leave the original version broken. Keep an evidence trail of compatible component versions, backups and migration steps. The safer release is the one whose failure can be contained and reversed quickly.
Design for partial failure during deployment
Real rollouts encounter partial commits. Infrastructure may provision while model deployment is throttled; an updated agent may become available before the search index is warm; a deployment task may time out after a remote service accepted the request. Every stage should have a way to determine what actually changed before retrying. Repeating a non-idempotent operation blindly can create duplicates or drift that future operators cannot explain.
Prefer stable resource identities, explicit readiness checks and deployment steps that can be retried safely. For workflows that write to external business systems, carry operation identifiers and distinguish “request accepted” from “business action completed.” If a tool call’s outcome is unknown, the agent should reconcile state or route the case to review rather than issuing the same irreversible action a second time.
A deployment process also needs an operational owner. Someone should know whether a failed quality check blocks the release, whether an index refresh can be deferred and who may authorize emergency rollback. These aren’t bureaucratic details: they prevent a technically successful pipeline from leaving an AI system in an unreviewed state.
Close the release on evidence, not a green banner
After deployment, examine the actual project endpoint, configured model deployment, identity permissions, index health and telemetry. Exercise at least one typical request and the high-risk negative cases chosen during planning. Confirm that the system is recording the trace and evaluation fields needed for incident analysis without leaking sensitive prompts or document contents to unrestricted logs.
Separate deployment facts from behavioral claims. “The service returned a response” is a connectivity result; “the assistant respected approval boundaries and used current evidence across our tested scenarios” is a narrower quality result. Neither should be overstated as universal correctness. Treat unresolved issuer feature limitations or preview availability as explicit constraints instead of silently smoothing them away.
The release is ready when a deployment record can identify the model, agent, search corpus, permissions and application version that were tested together. A successful infrastructure command is only one signal. Operators also need a reversible change path, traces tied to the actual configuration and clear rules for disabling a release when quality, authorization or latency regress.