Jesse Liberty

Run a full Microsoft Agent Framework (MAF) agent entirely on-device to eliminate round trips to the cloud, reduce latency, avoid egress costs, and keep sensitive data private. With Foundry Local you can run optimized local model variants (ONNX/WinML) and wire them directly into MAF.

In this guide you’ll get a working quickstart (Windows .NET 7 + WinML and a cross-platform Python example), exact commands to install and download a model, copy‑and‑paste code, hardware/driver tips, observability and troubleshooting checks, CI/CD advice, and production‑ready recommendations.

TL;DR
Use the Responses client for new projects if you want the newest, richest hosted tools and structured outputs; use the Chat Completion client when you need maximum backward compatibility or are constrained to the Chat-completions API (for example, Go-only paths or older models).

Why this matters
Choosing between a Responses client and a Chat Completion client in Microsoft Agent Framework affects which provider API and hosted tools your agent can use, how easy it is to migrate, and what models/back ends you can target. That can influence development effort, feature availability (hosted code execution, file search, image generation, structured outputs), and runtime portability.

BlogWriter uses the Responses API which can help with state maintenance. BlogWriter, however, implements important state (context) using a session object, and manages long-term memory by writing to a Cosmos Database.

I’m reusing this image because (a) it is apt and (b) he’s so cute!

In a previous blog post I promised to take apart the BlogWriter architecture and implementation. I thought today I’d start with the architecture.

The original design was to have 4 agents:
* BlogWriter (orchestrates the other agents)
* Researcher (searches the web and Microsoft Learn)
* Author (writes the blog post)
* Reviewer (either accepts the post or sends back fixes to the author)

Subsequently we moved the agents to Foundry (see this video and the diagram above). Critical to this new architecture is that the four Foundry-based agents are fully independent, and each lives in its own project. All the work is done by these agents.

I’ve been writing quite a bit about Spec Kit. Mostly because I can’t get over how effective it is when combined with Copilot. Spec Kit essentially “forces” you into Spec Driven Development best practices.

Spec‑Driven Development (SDD) flips the usual order of product work: start with a clear, testable spec that captures intent, evidence, and acceptance criteria, then drive planning and implementation from that spec. GitHub’s open-source Spec Kit is a practical toolkit for doing SDD consistently. It defines a small set of core phases you’ll use for most features and a fuller, production‑ready flow that adds project‑level setup and quality‑gate steps.

For the past six weeks I’ve been developing my demonstration program as a console application. Today I decided to give it a nice front end using Blazor (I don’t know Blazor). In the time it took to listen to Tommy (The Who, 1969) and half of The Wall (Pink Floyd, 1979) I had my first, second, and third drafts. That represents almost 30,000 lines of new code and documentation in well under 3 hours.

Yesterday I set out to add Cosmos to my demonstration project. The goal was to keep track of all queries, even after the browser is closed. My plan was to work with Spec Kit and Copilot, as described in my previous blog post. I didn’t know enough about working with Cosmos, but I was not intimidated; I had help.

The first step was to create a specification, saying what I wanted to build. (I reused the existing Constitution).

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: