Jesse Liberty

tl;dr
If you’re building automated workflows that sometimes must pause for human judgment (approvals, moderation, triage), Microsoft Agent Framework provides first‑class HITL primitives: typed RequestPorts, durable suspended execution, emitted RequestInfoEvents, and automatic routing of responses back to the correct workflow executor.

This article explains the runtime mechanics (what happens when a workflow asks a human for input), the developer experience (what you write), concrete examples (C# + JSON contracts), integration patterns with Bot Framework/contact centers, failure modes, and testing strategies.

For those who are following along with the evolution of my Blog Writing application: after the last revision (allowing follow-up questions to a query) Copilot evaluated my Pull Request and sent me an email that the follow-up was not, in fact, being added to the research stage. This was because the original research was in place and so that step was skipped.

Copilot and I fixed this with the following changes:

The demonstration program discussed (and used) in the previous blog posts ran entirely locally as a console application. This week I set out to migrate it to Foundry. To do so, I enlisted the help of Bruno Capuano and Jon Galloway, both of Microsoft, and, of course, Copilot, as documented in these videos (part 1 and part 2).

The change log is here. The architectural design can be found here. The complete demonstration solution is here.

The tl;dr is that we created projects for each of the four agents and deployed them individually to Foundry. The rest of the code stayed on the local machine. Each agent is independently deployed and each has its own managed compute and its own Entra ID, exposing an OpenAI-compatible /responses endpoint (as explained in the architectural design document).

The demonstration program will continue to evolve, but this marks a significant milestone… let’s call it version 3.0 (1.0 was LangChain/Python, 2.0 was the port to Microsoft Agent Framework/C#)

Note: The initial draft of this post was written by BlogWriter and then edited by Jesse Liberty
Illustrations by Copilot. Caution: LLMs make mistakes; this post is offered as is.

tl;dr
Copilot code review gives every pull request a fast, consistent first pass — catching typos, missing null checks and small bugs so human reviewers can focus on architecture, design and higher‑risk decisions.

What is Copilot code review?
Copilot code review is an AI‑powered reviewer that runs inside your pull‑request workflow (GitHub and integrated Azure DevOps/Azure Repos). It reads the PR diff (and respects repository custom instructions, if configured), posts inline comments as the user “GitHub Copilot,” and — where applicable — offers suggested fixes you can apply as commits directly from the PR UI. The goal is a fast, consistent first pass on correctness, style, security and maintainability so humans can spend their time on higher‑value review work.

I wanted to deploy my demonstration program, a local console application, to Foundry. The short answer is that without a front end (e.g. a Blazer Application) it made sense only to host the agents (and the tool) on Foundry, and leave the actual application on my local machine.

To do this, I consulted with Bruno Capuano and Jon Galloway, both of Microsoft. The result is a video that you can find here: Microsoft Agent Framework and Foundry Part 2.

tl;dr
How do you reliably combine deterministic business logic, parallel retrieval, and noisy LLM calls in production? The Microsoft Agent Framework answers this by modeling workflows as directed graphs: Executors (the nodes) perform the work, and Edges (the connections) define how strongly‑typed messages move between them. That separation makes orchestration explicit, testable, and observable.

Why the graph model matters
Treating a workflow as a directed graph of Executors and Edges gives you: