The art of simplicity

The GitHub Copilot SDK just shipped a new feature: optional memory configuration on session create and resume. Here is what it does, and how it is different from persisted sessions. The wrong mental model first When I heared "session memory" my first thought was "persisted sessions" — the ResumeSessionAsync flow that lets you reload an existing session by ID and continue where you left off. That is not what this is. Persisted sessions are about durability of the conversation itself: close the app, reopen it, pick up the thread. Memory configuration is something different. What memory configuration actually does Memory is a feature of the Copilot runtime that lets the agent read and write facts across turns — a kind of long-running knowledge store that the agent can consult and update during a session. Think of it as the agent's notepad, not the conversation log. The new MemoryConfiguration type exposes a single Enabled flag today. You opt in per se...

This final post continues on the multi-agent path: instead of one agent doing more things, we compose multiple agents doing the right things. Yesterday I demonstrated how to do this inside the Copilot SDK itself, today we look the broader ecosystem and I’ll show you how to integrate your Copilot SDK agent in the Microsoft Agent Framework. Microsoft Agent Framework The Microsoft Agent Framework(MAF) is the unified successor to Semantic Kernel and AutoGen. It provides a standard interface for building, orchestrating, and deploying AI agents. Dedicated integration packages let you wrap a Copilot SDK client as a first-class MAF agent — interchangeable with any other agent provider in the framework. The key distinction from Part 1: custom agents inside the SDK work within a single Copilot session, with the Copilot runtime as orchestrator. MAF operates at a higher level — it can compose a Copilot SDK agent with agents backed by Azure OpenAI, Anthropic, or any other provider, using st...

We've covered a lot of ground in this series: sessions and lifecycle, deployment and scaling, MCP integration, and skills. Each post added a new capability layer to a single agent. This post changes the shape of the problem: instead of one agent doing more things, we compose multiple agents doing the right things. There are two different levels at which you can do this. Inside the Copilot SDK itself, custom agents let the Copilot runtime orchestrate specialised sub-agents automatically within a single session. Beyond the SDK, the Microsoft Agent Framework lets you compose Copilot SDK agents with agents from any other provider in structured multi-agent workflows. In this post we stay inside the SDK. Our next and final post will look at the broader ecosystem and Microsoft Agent Framework integration. The problem with a single agent A single session with a broad system prompt is fine for many use cases. But as tasks grow more complex, the cracks show: A general agent need...

Up to this point in the series, we've extended the agent's capabilities in two ways: custom C# tools that execute code, and MCP servers that connect to external systems. Both are about what the agent can do . Skills are about what the agent knows and more specifically, how to apply that knowledge in a repeatable, composable way. A skill is a folder containing a SKILL.md file with specialised instructions, and optionally supporting files like scripts, templates, or examples. You point the SDK at a directory, the agent scans for skills automatically, and when a task matches a skill's description, that skill's instructions are injected into the session context. The agent gains focused expertise — without you writing any C#, and without redeploying your application. Why skills exist Think about a development task you repeat across projects: scaffolding a solution, writing a particular kind of test, generating API documentation in a house style, following a specific ...

After a short break, I'm back with my series about the GitHub Copilot SDK. So far, we have covered: You don't need to build your own agent harness Getting started with the GitHub Copilot SDK in .NET Sessions in the GitHub Copilot SDK: What they are and how to manage them Deploying and scaling Authentication and observability Today, we cover MCP integration — connecting your agent to external context and services via the Model Context Protocol, so your agent can reach databases, APIs, and cloud services without you having to build the glue. The agent we've built so far knows how to reason and plan, and can call C# tools you define directly. But there's a whole ecosystem of pre-built capabilities out there. Servers that talk to Azure, GitHub, databases, Slack, internal systems — all speaking the same open standard. MCP is how your agent connects to that ecosystem. Instead of writing tool integrations from scratch, you point the SDK at an MCP serv...

In the previous post I set the stage on deploying to production. We covered managing the CLI process, different isolation patterns and how to scale horizontally. This post covers 2 other aspects important when putting your GitHub Copilot SDK enabled application into production; how to tackle authentication and how to get insights into what is going inside your agentic system. Authentication in production Development uses your personal GitHub credentials via gh auth login . Production backends need a different approach. Service account token (shared CLI): Set COPILOT_GITHUB_TOKEN as an environment variable on the CLI process. All sessions on that CLI use the same token. Simple, but every user is acting as the service account. export COPILOT_GITHUB_TOKEN="gho_service_account_token" copilot --headless --port 4321 Per-user tokens (GitHub OAuth): For multi-tenant applications where users authenticate with their own GitHub identities, pass each user's token wh...

Techorama 2026 was a blast! Great content, great atmosphere and great people. And of course, the main conversation topic was AI and how it will shape our industry. Nobody knows what is coming next but at least we already got a glimpse into the future. I delivered a presentation about integrating the GitHub Copilot SDK into your application and hopefully proved how easy it is to get an agent running inside your systems. AI is moving from assistants we query to agents that collaborate with us inside our applications. By reusing the same agentic loop behind the Copilot CLI, the Copilot SDK makes that shift practical for every developer. In this session, we explore how to embed GitHub Copilot–powered agents directly into your apps, extend them with custom skills, and connect them to your own data and workflows. You’ll see how to design agent behaviors, orchestrate tool use, and create safe, reliable interactions that feel native to your product. Whether you’re building personal ...

If you looked at an older GitHub Copilot SDK example online and copied it over, there is a chance that you see the following error message when you try to execute the code: Unhandled exception. System.ArgumentException: An OnPermissionRequest handler is required when creating a session. For example, to allow all permissions, use CreateSessionAsync(new() { OnPermissionRequest = PermissionHandler.ApproveAll }); at GitHub.Copilot.SDK.CopilotClient.CreateSessionAsync(SessionConfig config, CancellationToken cancellationToken) So, what exactly is happening here? The important part is this: An OnPermissionRequest handler is required when creating a session. The GitHub Copilot SDK is designed with a permission-based execution model . Whenever Copilot wants to execute a tool, access resources, or perform potentially impactful operations, the SDK expects the host application to decide whether that action is allowed. This is done through the OnPermissionRequest callback. With older...

In the previous post we got a working .NET app talking to the Copilot agent runtime. We created a CopilotSession , sent messages through it, and saw how multi-turn conversations just work — the agent remembered what you said three messages ago without you having to manage that state yourself. That "just works" quality is deliberate, and it's worth understanding what's actually happening underneath. Sessions are the stateful core of the Copilot SDK. How you create, configure, scope, and dispose them determines whether your application is resilient, scalable, and cost-efficient — or fragile and leaky. This post goes deep on sessions: what they are, how their lifecycle works, how to persist them across restarts, and the patterns that hold up in production. The mental model: Client vs. Session Before getting into lifecycle specifics, it's worth being precise about the two core classes and what each one owns. CopilotClient is infrastructure. It manages th...

After pulling some NuGet packages into my .NET Aspire project, I ran into this cryptic startup failure: Aspire.Hosting.DistributedApplicationException: Newer version of the Aspire.Hosting.AppHost package is required to run the application. Ensure you are referencing at least version '13.2.2'. at Aspire.Hosting.Dcp.DcpDependencyCheck.EnsureDcpVersion(DcpInfo dcpInfo) at Aspire.Hosting.Dcp.DcpDependencyCheck.GetDcpInfoAsync(...) at Aspire.Hosting.Dcp.DcpHost.StartAsync(...) The app host refuses to start, and the logs point you toward a version check deep inside DCP internals. The error message tells me that a minimum version of the hosting package is required,but no matter how many times I ran dotnet restore or update NuGet packages through Visual Studio, the error persists. That's because there are two places that pin the Aspire version. Why updating NuGet packages isn't enough Aspire AppHost projects use a special SDK reference at the very...

Yesterday, I created a minimal .NET project with DevUI and registered a couple of standalone agents. That gets you surprisingly far for interactive testing. But real business scenarios quickly outgrow a single agent: you need data flowing through multiple specialized steps, decisions being made along the way, and a clear picture of the whole pipeline. That's what workflows are for. In this post, we'll build a content review pipeline as a concrete example — a Writer agent drafts a response, a Reviewer agent critiques it, and a deterministic formatting step finalizes the output. All of it visualized in DevUI. Agents vs Workflows — the key distinction The Agent Framework docs put it cleanly: an agent is LLM-driven and dynamic — it decides which tools to call and in what order, based on the conversation. A workflow is a predefined graph of operations, some of which may be AI agents, but the topology is explicit and deterministic . You decide exactly what runs after what. ...