The art of simplicity

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 2012(!) I blogged about rubber duck debugging to help me troubleshoot issues. It's a practice I'm still using even today. With GitHub Copilot CLI's newest update, rubber duckis becoming AI driven. Copilot introduces a second AI model from a different family to critique your agent's plans and implementations at the moments where feedback has the highest return. Let's have a look at it in more detail... What rubber duck actually does Rubber Duck is not a general-purpose chat assistant. It's a review agent that will use a model from a complementary AI family to whichever model you've selected as your orchestrator. When you're running a Claude model as your orchestrator, Rubber Duck runs on GPT-5.4. This is intentional: a model reviewing its own output is still bounded by its own training biases. A cross-family reviewer brings genuinely different blind spots to the table. Rubber Duck's output is deliberately narrow — a short, prioritised lis...

Having your AI agent come up with a plan before start coding, has helped me a lot in my agentic development workflow. It allows me to verify the steps the agent will take and allowed me to avoid that the agent goes down the wrong path. To help you with this, Visual Studio got a ‘plan mode’ that once enabled allowed the agent to create a plan. I really liked the feature, the only problem is that is what not always obvious when the agent decides to create a plan and when it just starts executing. To tackle this issue, the plan mode in Visual Studio has evolved to a separate plan agent, similar to what we have in VSCode. Plan first, code second If you have never heard about plan mode or the plan agent, it is a dedicated mode in Copilot Chat that focuses entirely on understanding what you want to build before touching a single file. Instead of jumping straight to implementation, it asks clarifying questions, reads your codebase using read-only tools, and drafts a detailed implemen...

If you're upgrading to the latest version of the Copilot SDK beta, there's a syntax change you need to know about. The .On() method now requires a generic type parameter. As the SDK is still in beta, breaking changes are not unexpected. But this one should be handled with extra care to avoid resource leaks. This post walks you through what changed, why it matters, and how to update your code. What changed In previous versions of the SDK, registering an event handler looked something like this: // Old syntax app.On(evt => { if (ev is AssistantMessageDeltaEvent deltaEvent) { Console.Write(deltaEvent.Data.DeltaContent); }); } In the latest version, the .On() method is now generic. You must explicitly specify the activity or event type you're handling: // New syntax using var subscription = app.On<AssistantMessageDeltaEvent>(evt => { Console.Write(deltaEvent.Data.DeltaContent); }); The method signature has changed from:...

After upgrading the GitHub Copilot SDK to the 1.0.0-beta.10 version, initiating the CopilotClient no longer worked. Instead I got the following error message: System.Text.Json.JsonException: The JSON value could not be converted to System.DateTimeOffset. Path: $.timestamp | LineNumber: 0 | BytePositionInLine: 43.  ---> System.InvalidOperationException: Cannot get the value of a token type 'Number' as a string.    at System.Text.Json.ThrowHelper.ThrowInvalidOperationException_ExpectedString(JsonTokenType tokenType)    at System.Text.Json.Utf8JsonReader.TryGetDateTimeOffset(DateTimeOffset& value)    at System.Text.Json.Utf8JsonReader.GetDateTimeOffset()    at System.Text.Json.Serialization.Converters.DateTimeOffsetConverter.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options)    at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object o...