The art of simplicity

I set up a scheduled pipeline in Azure DevOps. The YAML was valid. No errors on save. I waited patiently for the cron to fire. Nothing happened… The culprit turned out to be a single line I'd added for a completely legitimate reason trigger: none . The setup The pipeline looked roughly like this: trigger: none schedules: - cron: "0 2 * * 1-5" displayName: Nightly weekday build branches: include: - main always: true The intent was straightforward: I didn't want CI runs on every push, so I explicitly disabled that with trigger: none . And I wanted the pipeline to run on a schedule. Seems fine, right? Except it never ran. What's actually happening Here's the thing that isn't obvious until you read the docs carefully (or waste an afternoon debugging): in Azure DevOps YAML pipelines, trigger is specifically the CI trigger — the thing that fires on code pushes. schedules is a completely separate concept. So whe...

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

In a previous post I showed how to add the .NET runtime version as an OpenTelemetry resource attribute: ResourceBuilder.CreateEmpty() .AddService($"{_sofaSettings.ApplicationName}-{_sofaSettings.EnvironmentName}") .AddAttributes(new Dictionary<string, object> { ["deployment.environment"] = _sofaSettings.EnvironmentName, ["service.name"] = _sofaSettings.ApplicationName, ["runtime.dotnet.version"] = Environment.Version.ToString() }) .Build(); The idea was clean: attach facts about what is running directly to the resource, and let OpenTelemetry carry them along with every trace, metric, and log automatically. Unfortunately, there is a catch. The problem Azure Monitor's OpenTelemetry exporter only maps a fixed set of well-known resource attributes onto Application Insights fields. service.name and service.namespace become Cloud Role Name, service.instance.id becomes Cloud Role Insta...

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