The art of simplicity

UI generation and background coding agents are two of the "AI" tools that really changed my way of working. Together, they close a gap that's been annoying me for a while: the coding agent still needs someone to describe what the UI should look like, and that someone is usually me, typing a wall of text into an issue and hoping for the best. Google Stitch generates UI screens (HTML/CSS, Tailwind, Flutter, SwiftUI, whatever…) from a prompt or a sketch. The GitHub Copilot coding agent picks up an issue and produces a pull request in the background, without you sitting in the editor. In this post we look at how to connect the two through MCP, so the coding agent stops guessing at layout, spacing and colors, and starts reading an actual design spec. Here's how to wire it up, and where it still needs a human in the loop. My first approach: screenshots in the issue body My first attempt was to design something in Stitch, paste a screenshot into a GitHub issue, and ...

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...

The GitHub Copilot CLI keeps getting more capable. One of the newer additions is the ability to schedule prompts, either on a repeating interval or as a one-shot delayed action. Let me walk you through both approaches. Two ways to schedule The /every command schedules a prompt to run repeatedly at a specified interval, while /after schedules a one-shot prompt to run once after a specified delay. Both commands are still experimental. They are only available if you have used the /experimental on slash command, or the --experimental command-line option first. Use the following slash command to enable experimental mode in your session: /experimental on Recurring prompts with /every Use /every when you want Copilot to repeat a task on a cadence during your session. /every 10m Run the test suite and summarize any new failures /every 1h Check for new comments on my open pull requests A number with no suffix is interpreted as minutes — so /every 30 remind me to check for...

In the previous post, we walked through local sandboxing in the Copilot CLI: enable it with /sandbox enable , tune filesystem and network rules through the TUI, and your agent's shell execution is isolated by Microsoft MXC. Simple, useful, done. But if you're building with the Copilot SDK, embedding the agent runtime into your own .NET application, you can't type /sandbox enable into a session you're programmatically orchestrating. So the question becomes: how do you get the same isolation guarantees when you own the host? The good news: sandbox support is coming to the SDK as a preview feature. The entry point is Session.Rpc.Options.UpdateAsync , and it lets you push a sandbox configuration into a running session from code. Preview caveat : this API is behind the experimental surface of the SDK. It's real, it works, but the shape may change before it stabilises. Treat it as preview-quality and don't build production contracts on top of it just yet. Wha...

There's a moment in every agentic workflow where you pause and think: wait, what exactly is Copilot allowed to touch right now? For a long time the answer was: pretty much everything under your working directory and whatever shell commands it decides to run to get the job done. That was fine when Copilot was mostly suggesting code. It's a different story when it's running tools, executing scripts, and modifying files on your behalf. As of June 2026, GitHub has an answer: local sandboxing , now in public preview. It doesn't replace good judgment about what you ask Copilot to do, but it does put a real isolation boundary between the agent's tool execution and the rest of your machine. Let’s explore this feature… Why do we need this? The Copilot CLI has evolved significantly since GA. What started as a smart terminal assistant now has Autopilot mode, /plan , fleet parallelism, rubber duck, and a full agentic harness underneath. When you run Copilot in Autopil...

By default, the CopilotClient starts in CopilotCli mode. That means the full Copilot CLI persona is active — which includes a lot: All built-in tools available (subject to the ToolSet filtering you do per session) Host integration enabled: the CLI picks up your local ~/.copilot/ config, agents directory, plugins, and AGENTS.md files if they exist The default system prompt with the full Copilot identity Co-author trailers added to git commits Storage backed by the local filesystem at the default path For a developer using the SDK on their own machine to automate their own workflows, this is perfect. The agent behaves exactly like Copilot CLI would interactively. Context flows in from their environment, their local agent configs are respected, their Copilot persona is preserved. The multi-tenant problem The moment you start running the SDK as a service — where one process handles sessions for multiple users or tenants — default mode becomes a liability. ...

This post is part of a follow-up series to my GitHub Copilot SDK blog series . After wrapping up the main series I was left with a list of features that deserved more than a passing mention. This is the second post about the built-in tools. When you create a session using the SDK, the agent has access to two distinct categories of tools: Custom tools are the ones you define yourself — your CopilotTool.DefineTool(...) registrations, the available skills and MCP tools. These are the application-specific capabilities you build. Built-in tools are what the Copilot CLI brings to the table out of the box: file reading, file writing, shell execution, web fetching, web search, and a handful of others. These power the agentic loop that makes Copilot useful without you having to implement everything from scratch. By default, when you call CreateSessionAsync , both categories are available. And by default, built-in tools that could cause side effects — writing files, executing sh...

This post is part of a follow-up series to my GitHub Copilot SDK blog series . After wrapping up the main series I was left with a list of features that deserved more than a passing mention. First up: SystemMessageConfig , and specifically the mode that most tutorials gloss right over. The temptation of Replace When you first discover that the Copilot SDK lets you control the system prompt, the obvious instinct is to reach for SystemMessageMode.Replace . Full control, clean slate, no surprises — what's not to like? var session = await client.CreateSessionAsync(new SessionConfig { Model = "gpt-5", SystemMessage = new SystemMessageConfig { Mode = SystemMessageMode.Replace, Content = "You are a helpful assistant." } }); However there is a big problem with adding this line. When you replace the system prompt wholesale you are not just customizing Copilot, you are evicting it. The carefully tuned defaults around tool use, safet...

With the change to token based billing, I pay a lot more attention on what my AI agents are doing. Although some info is available, I was missing the tools to evaluate my token consumption and have an in-depth understanding of what's going on. Until I discovered AgentsView. AgentsView is a local-first desktop and web app that reads those files and gives you a proper UI to work with them: browse sessions, search across all message content, see tool calls and thinking blocks, and get a quick health grade for each session. Let's install it and see what it actually looks like. Installation There are a few ways in, pick whatever fits your workflow. As a Windows user I decided to grab the latest .exe or .AppImage from the GitHub Releases page . The desktop app is fully bundled and auto-updates. Executing the downloaded executable will walk you through an installation wizard. Remark: There is also a CLI which uses the same data directory. Running it If you went the...

In previous posts, I covered how to customize the GitHub Copilot CLI statusline. First with the default options , then with a dynamic script . Today we're taking it a step further: integrating Oh My Posh to bring full prompt theming support to your Copilot CLI session. Oh My Posh has native support for GitHub Copilot CLI, so you get all its theming power (Nerd Font icons, color gradients, diamond-style segments,…) rendering right inside the Copilot CLI statusline. What Is Oh My Posh? Oh My Posh is a cross-shell prompt engine that lets you define richly styled prompts using a JSON (or YAML/TOML) configuration file. You probably know it from PowerShell or bash, but it also ships a dedicated copilot subcommand specifically for integration with GitHub Copilot CLI's statusLine feature. Prerequisites Oh My Posh installed ( winget install JanDeDobbeleer.OhMyPosh   see docs ) A Nerd Font installed and set as your terminal font (for icons to render correctly) Gi...

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...