Jesse Liberty

I am totally blown away by the combination of Spec Kit and Copilot. It is one thing to read about SDD and quite another to build with it.

[For more on the steps in SDD, please see what I wrote about Spec Kit previously.]

Today I fired up Spec Kit and pointed Copilot at it, instructing Copilot to create a constitution based on the existing code (my blog writing demo). A minute later I had a comprehensive document that listed all the immutable characteristics of the application. It was quite long, but here is the beginning:

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#)

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.