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