Azure foundry Agents deployment

Question

I am designing an AgentOps platform for Azure AI Foundry Agents and would like guidance on CI/CD best practices.

Current Architecture:

• Azure AI Foundry Projects for DEV, TEST, UAT, and PROD

Agents are created and managed directly inside Azure AI Foundry

Foundry maintains agent versions, version history, published versions, and rollback capability

A custom AgentOps portal handles evaluations, LLM judge scoring, approvals, promotions, and deployments between environments

My Question:

Since Azure AI Foundry already provides agent versioning, version history, and rollback functionality, is it necessary to maintain a separate Git repository (Azure DevOps Repos/GitHub/Gitea) for agent YAML/configuration files?

What additional value does Git provide in this scenario beyond what Foundry already offers?

Specifically:

Is Azure AI Foundry considered a sufficient source of truth for agent definitions and versions?

For enterprise Agent CI/CD, is it recommended to export agent configurations to Git, or can Foundry versions be promoted directly across DEV → TEST → UAT → PROD?

What are the recommended practices for auditability, approvals, rollback, and release tracking when agents are authored directly in Foundry?

Have any organizations implemented AgentOps pipelines where Foundry serves as the primary version-control system and Git is only used for platform/application code?

I would appreciate guidance from anyone who has implemented enterprise CI/CD processes for Azure AI Foundry Agents.

Answer 1

Hello @Brahadiswaran Suresh

You’re absolutely thinking in the right direction around source of truth, promotions, and auditability.

Is Azure AI Foundry enough as a source of truth?

Azure AI Foundry provides a built-in agent lifecycle (create, test, evaluate, publish, monitor) along with versioning and publishing to a stable endpoint. This means it can act as the operational source of truth for agent runtime behavior and versions.

However, it is primarily focused on managing and operating agents, not on full enterprise CI/CD governance (such as external approvals, Git-based workflows, or repo-driven audit trails).

Does Git add value here?

Yes, especially in enterprise scenarios.

Using Git alongside Foundry helps with:

• Change reviews through pull requests
• Traceability via commit history
• Controlled promotions across environments (DEV → TEST → PROD)
• Storing agent definitions as code for reproducibility

So, while Git is not strictly required to use Foundry, it typically complements Foundry when you need structured CI/CD and compliance-driven workflows.

Promotions across environments

Foundry supports publishing and versioning of agents, but it does not currently define a complete multi-environment promotion pipeline (for example, DEV to TEST to PROD) in the same way traditional CI/CD systems do.

In practice, teams usually adopt one of these patterns:

• Use Foundry publishing for version control within a single environment
• Use external pipelines (for example, Git-based workflows) to promote configurations across environments

Recommendation

• If your requirement is simple lifecycle management and versioning, Foundry alone may be sufficient.
• If you need strong governance, approvals, and auditability, combining Foundry with Git-based CI/CD is the recommended approach.

Summary

• Foundry = agent lifecycle, publishing, runtime management
• Git = governance, approvals, audit trail, and cross-environment promotion

Using both together typically gives the most complete enterprise setup.

Hope this helps clarify. Do let me know if you have any further queries.

Thankyou!

Answer 2

Azure AI Foundry’s built-in agent versioning is not a full replacement for Git-based source control in enterprise CI/CD. Foundry should be treated as the runtime and deployment platform, while Git remains the system of record for agent definitions, instructions, and configuration.

Key points from the guidance in the context:

1. Git as source of truth for agent definitions

The baseline architecture and secure-process guidance explicitly recommend treating agents “as code” and storing all definitions in source control:

• “Define agents as code. Always store agent definitions, connections, system prompts, and configuration parameters in source control. This practice ensures traceability and reproducibility. Avoid untracked changes through the Foundry portal.”
• “Store instructions in source control repositories to maintain an audit trail of changes. Integrate automated validation steps… before deployment.”

This means:

• Foundry’s version history is valuable but is not the primary audit trail.
• Git provides:
  • Full diffing of prompts/instructions, tools, and config.
  • Branching, pull requests, and code review workflows.
  • Integration with enterprise change-management and approvals.
  • Integration with CI/CD systems for automated testing and promotion.

2. Why Git adds value beyond Foundry’s versioning

Foundry Agent Service provides:

• Immutable agent versions and automatic snapshots.
• Built-in rollback and version history.
• Publishing and promotion of agents to stable endpoints.

However, the architecture guidance adds additional expectations that are best met with Git:

• Auditability and approvals
  • Use source control to maintain an audit trail of who changed what and when.
  • Use PR-based approvals and reviews for changes to prompts, tools, and configuration.
  • Integrate automated evaluation scripts or agent evaluators in CI to validate changes before deployment.
• Controlled deployment and promotion
  • “Automate agent deployment. Use your workload’s CI/CD pipelines… Prefer agent pipelines that you can deploy independently for small, incremental changes.”
  • Pipelines can:
    • Export/update agent definitions from Git.
    • Deploy to DEV → TEST → UAT → PROD using Foundry SDKs/REST API.
    • Run evaluations and guardrails as gates.
• Traceability and release tracking
  • Git tags/releases can be aligned with Foundry agent version IDs.
  • Records of which Foundry version is deployed to which environment can be tracked in Git and/or deployment pipelines.

3. Is Foundry alone a sufficient source of truth?

From the guidance, Foundry alone is not positioned as the sole source of truth for enterprise scenarios:

• Agents are to be treated like microservices with “life cycle management requirements similar to other microservices.”
• For such workloads, the recommended pattern is:
  • Git = source of truth for definitions and instructions.
  • Foundry = runtime, hosting, and operational versioning.

Foundry’s native versioning should be used in combination with Git, not instead of it.

4. Exporting to Git vs. promoting directly in Foundry

The high-availability guidance explicitly recommends exporting agent definitions and storing them in version control:

• “Store agent JSON definitions and knowledge source references in source control.”
• “Use the Foundry REST API to periodically export agent configurations… Save each agent definition as a JSON file in your version control system.”
• “Automate this process in a CI/CD pipeline… The SDK provides methods to list agents, retrieve their configurations, and serialize them to JSON for version control.”

Recommended pattern for enterprise CI/CD:

• Authoring can happen in Foundry (especially early-stage), but:
  1. Regularly export agent definitions (JSON/YAML) to Git via SDK/REST.
  2. Treat Git as the canonical definition for promotion.
  3. Use CI/CD pipelines to:
     • Apply changes from Git to DEV.
     • Run evaluations and tests.
     • Promote to TEST/UAT/PROD using Foundry APIs.

Direct promotion solely within Foundry (without Git) is possible but not aligned with the recommended “agents as code” and auditability practices for enterprises.

5. Auditability, approvals, rollback, and release tracking

Based on the guidance:

• Auditability
  • Keep agent instructions, system messages, tool bindings, and connections in Git.
  • Use Git history and PRs as the primary audit log.
  • Use Foundry’s immutable version history as a secondary, runtime-level audit trail.
• Approvals
  • Implement approvals via PR workflows in Git.
  • Integrate automated evaluations and safety checks in CI (for example, agent evaluators, red-teaming, content safety checks) before merging and deploying.
• Rollback
  • At the platform level: use Foundry’s built-in version rollback.
  • At the configuration level: revert Git commits/tags and redeploy via pipeline.
  • For data/state: follow the backup/restore guidance (for example, Cosmos DB point-in-time restore for enterprise_memory).
• Release tracking
  • Maintain a mapping of Git commit/tag → Foundry agent version → environment.
  • Use CI/CD logs and deployment manifests to track which version is live where.

6. Patterns where Foundry is primary and Git is secondary

The context does not describe organizations using Foundry as the only version-control system. Instead, it consistently recommends:

• “Always store agent definitions… in source control.”
• “Avoid untracked changes through the Foundry portal.”

A practical compromise some teams adopt (aligned with the guidance):

• Allow interactive authoring and experimentation directly in Foundry in DEV.
• Regularly export and normalize those definitions into Git.
• Treat any change that is not exported to Git as non-production/experimental.
• Only deploy to TEST/UAT/PROD from Git-controlled definitions via pipelines.

Summary recommendations for the described AgentOps platform:

• Use Azure AI Foundry for:
  • Hosting, runtime versioning, publishing, and rollback.
  • Operational features (identity, networking, content safety, observability).
• Use Git for:
  • Canonical agent definitions, prompts, tools, and configuration.
  • Approvals, auditability, and change management.
  • CI/CD pipelines that deploy and promote agents across environments.

This aligns with the official guidance to treat agents as independently deployable units with the same DevOps rigor as microservices.

---

References:

• Baseline Microsoft Foundry chat reference architecture
• High availability and resiliency for Microsoft Foundry projects and Agent Services
• Process to build agents across your organization
• What is Microsoft Foundry?
• What is Microsoft Foundry Agent Service?