There Is No Export Button — Why Foundry Agents Need CI/CD

You've built an agent in the Microsoft Foundry portal. The instructions are tuned, the tools work, the playground conversations look great. Now your team asks the obvious grown-up question: "How do we get this into test and prod?"

So you go looking for the export button. There isn't one. No portal export/import, no "agent artifact" to promote, no package to hand to the next environment. If your mental model of deployment is build a thing, move the thing through environments, Foundry agents will feel broken.

They're not broken — the model is different, and once it clicks, agent CI/CD is simpler than what you're used to. This series walks that model end to end, and it stands on the shoulders of a reference implementation I genuinely recommend cloning: foundry-agents-lifecycle by Eric Chansen. It's an educational demo covering SDK-based agent deployment, per-environment configs, evaluation quality gates, Bicep infrastructure, and parallel GitHub Actions and Azure DevOps pipelines — the whole lifecycle in one clean repo. All credit for the reference patterns in this series goes to that project; my job here is to walk you through why it's shaped the way it is and how to put it to work on your own agents.

The core insight: the agent IS its configuration

Traditional software deploys an artifact: you compile a binary or bake a container image, and that immutable thing moves dev → test → prod. The artifact is the truth.

A Foundry prompt agent has no binary. Strip it down and an agent is just:

a system prompt (text),
tool definitions (schemas + wiring),
a model selection (which deployment it runs on),
a name and metadata.

That's it. Pure configuration. There's nothing to compile and therefore nothing to promote. As the reference repo's README puts it: CI/CD for agents means defining the agent in code and recreating it via SDK in each environment. The repo is the truth, and every environment gets a fresh agent materialized from the same source.

If you've worked with Terraform or Bicep this should feel familiar — nobody "promotes" a resource group between environments; you apply the same template with different parameters. Agents work exactly like infrastructure: desired state in git, applied per environment.

What CI/CD is NOT (portal habits to unlearn)

The reference repo opens with a list of anti-patterns worth internalizing:

❌ Exporting an agent from the Foundry portal — there's nothing to export.
❌ Promoting an "agent artifact" between environments — no artifact exists.
❌ Manually copying agent settings between projects — works once, drifts forever, and the day someone tweaks prod directly you'll have an agent nobody can reproduce.

And what it actually is:

✅ Agent config lives in your repo (Python + JSON + markdown prompts).
✅ An SDK script creates or updates the agent in each environment.
✅ Bicep provisions the infrastructure underneath (Foundry account, project, model deployments).
✅ A pipeline orchestrates the sequence: test → evaluate → deploy → approve → repeat for the next environment.

The portal doesn't become useless — it's a great prototyping surface. Sketch your agent interactively, then codify what you learned into the repo. Prototype in the portal, deploy from git. (I follow the same rule on this site: my agents were shaped in the playground, but what runs is defined in code.)

Why bother? The three failure modes of portal-managed agents

If you're tempted to just click your agent into three environments and move on, here's what that costs you:

Drift. Three hand-configured agents will diverge. Someone hotfixes the prod prompt during an incident, forgets to backport it, and now dev tests against instructions prod doesn't have. With code-first agents, a git diff answers "what's different between test and prod" — with portal agents, nothing does.

No review. A system prompt change can alter behavior as much as a code change — arguably more. Portal edits skip code review entirely. In a pipeline, prompt changes arrive as pull requests with diffs, reviewers, and (chapter 3) an evaluation score attached.

No rollback. When the new prompt turns out to be worse, what do you do — remember what the old one said? Code-first, rollback is git revert plus a pipeline run. The repo's deploy script even uses Foundry's agent versioning (create_version), so every deployment is a numbered, inspectable step in the agent's history.

What we're building across this series

The reference repo's flow, which we'll unpack chapter by chapter:

PR opened      → CI: lint, unit tests, dry-run deploy   (chapter 3)
merge to main  → CD: deploy to DEV, evaluate            (chapter 3)
approval gate  → deploy + evaluate TEST                  (chapter 3)
approval gate  → deploy + evaluate PROD                  (chapter 3)
 
same flow, Azure DevOps syntax                           (chapter 4)
the building blocks that make it possible                (chapter 2)

Three environments, one codebase, per-environment JSON configs (dev runs a cheaper model with relaxed eval thresholds; prod runs the production model behind stricter gates and more approvers). Evaluations — the topic my previous series spent a whole chapter on — reappear here as pipeline quality gates: an agent that scores below threshold simply doesn't ship.

Wrapping up

The unlock is one sentence: stop looking for the artifact — the agent is configuration, and configuration is what git and pipelines were built for. Everything else in this series is the practical consequence of taking that sentence seriously, with Eric Chansen's foundry-agents-lifecycle as our reference implementation.

Next — Chapter 2: we dissect the repo itself: the Bicep that provisions Foundry per environment, the config-per-environment pattern, and the deploy script that turns a markdown prompt and a JSON file into a live agent.