Foundry Workflows retire on December 1. We'd start moving yours to Agent Framework now

Microsoft is pulling the visual Workflows designer out of Microsoft Foundry on December 1, 2026. If a Foundry workflow runs part of your business today, export its YAMLdefinitionIt's the text file behind every Foundry workflow. You can read it, diff it and keep it in Git, which is why the export matters. this week and pick where it will live next: Microsoft Agent FrameworkdefinitionMicrosoft's open-source SDK for agents and workflows, in .NET and Python. If you used Semantic Kernel or AutoGen, this is where they went., Azure Logic Apps or a direct agent-to-agent call. This guide explains what retires, what keeps running, and the order we'd move things in.

Nothing here breaks loudly on day one, and that's the risk. A workflow that triages support tickets or drafts approval packs keeps doing its job right up until the portal can't run it. Then the queue it feeds goes quiet, and the first person to notice is usually whoever was waiting on the output.

Microsoft's own general availability page already lists "building new production dependencies on Workflows" as a rollout pitfall. If an auditor or risk committee approved a process that runs on a preview feature, the retirement is a good reason to put it on supported ground and update the record.

For engineers: workflows stop being their own agent type. Microsoft's migration guide says the patterns you drew (sequential, group chat, branching, human-in-the-loop) all map onto Agent Framework, through declarative YAML or code, and that in many cases the exported YAML runs with minimal changes. Notice the word many. The rest of this guide is about the cases where it doesn't.

Most teams will land on Agent Framework, and that's what Microsoft recommends. Logic Apps makes sense when business analysts own the process and won't touch YAML, or when the workflow mostly calls other systems and only asks an agent to reason in one or two steps. A2AdefinitionAgent-to-agent protocol. If one agent just needs to ask another for help, it calls it directly and you skip the workflow. fits the smallest cases, where the "workflow" was really one agent forwarding questions to a specialist.

We read the workflow docs, the Agent Framework declarative reference and the hosted agentdefinitionYour own agent code in a container, run by Foundry. You don't manage servers, but you do manage the identity it gets. docs side by side. These are the gaps that turn a quick port into a real project. None of them are in Microsoft's retirement notice.

The Python one is the nastiest, because nothing fails. A branch condition such as =Local.category = "billing" just stops being evaluated, so every request takes the same path and the logs carry one warning. Your test set has to include a request for every branch, and someone has to read the warnings.

The Copilot conversion is useful for getting started. Microsoft's own page says it doesn't deploy anything and doesn't guarantee the same behavior, and it tells you to keep the original definition until the replacement is proven. We'd treat its output like a pull request from a new hire: read every branch, every variable and every approval step against the YAML.

The agents themselves don't have to move. A workflow node invokes a Foundry agent by name, and the declarative YAML in Agent Framework does the same with an InvokeAzureAgent action. What changes is the box around them: a container you build, a version you deploy and an identity you have to grant access to.

Hosted agents also change the bill. You pay for CPU and memory per active session, and every session gets its own sandbox. The smallest size is half a vCPU with 1 GiB, and an idle session shuts down after 15 minutes unless you change it. We'd start small and size up only when the tests say so, because oversizing gets multiplied by every concurrent user.

This is the second Foundry retirement in a few months, with classic agents leaving next spring and model versions retiring on their own schedule. The teams that cope best treat the portal as a test bench and keep anything that matters in their own repo.

We made these up to show common setups. None of them is a Cohash client or a real incident.

If you want a hand, we can sit with your team, port the first workflow together and build the regression set you'll reuse for the rest. The Microsoft Foundry page shows the wider platform work. You can also hire Foundry engineers for the busy weeks, or start with an assessment of what still runs on preview features.