At endjin, we maintain Corvus.JsonSchema, and in the previous post we saw how the source generator produces complete typed models from JSON Schema.

Now let's look at what happens when you call person.EvaluateSchema().

Validation is not optional

If you're working with JSON that crosses a trust boundary - API requests, message queues, configuration files, user-supplied data - you need to validate it. Not "check a couple of fields" validate. Schema validate. Against a specification that defines what valid means, and that both producer and consumer agree on.

JSON Schema is that specification, and it covers all the major drafts: 4, 6, 7, 2019-09, and 2020-12 - plus OpenAPI 3.0 and 3.1.

V5 validates over 10× faster than other .NET JSON Schema validators.

The generated validator

If you've followed the source generator approach from the previous post, validation is already built in:

using var doc = ParsedJsonDocument<Person>.Parse(
    """{"name":"Alice","age":30}""");
Person person = doc.RootElement;

bool valid = person.EvaluateSchema();  // true

That's it. The source generator produced a validation method tailored to your specific schema, with every keyword compiled into type-specific checks. There is no interpretation overhead and no runtime schema walking.

Getting diagnostic output

When validation fails and you need to know why, pass a results collector:

using var collector = JsonSchemaResultsCollector.Create(
    JsonSchemaResultsLevel.Detailed);

bool valid = person.EvaluateSchema(collector);

if (!valid)
{
    foreach (var result in collector.EnumerateResults())
    {
        if (!result.IsMatch)
        {
            Console.WriteLine(
                $"  Failed: {result.GetMessageText()} " +
                $"at {result.GetDocumentEvaluationLocationText()}");
        }
    }
}

When you call EvaluateSchema() without a collector, you get a simple pass/fail bool with maximum performance. If you need diagnostics, create a JsonSchemaResultsCollector and choose how much detail you want:

Use the no-collector overload in production hot paths; use Detailed or Verbose for diagnostics.

Dynamic validation at runtime

Not every scenario has schemas known at compile time. Schema registries, configuration validators, and user-supplied schemas all need runtime compilation.

The Corvus.Text.Json.Validator package handles this. Internally, it uses the same code generation engine as the source generator, but invokes Roslyn dynamically:

using Corvus.Text.Json.Validator;

// Load a schema - from a file, string, stream, or URI
JsonSchema schema = JsonSchema.FromFile("Schemas/person.json");

// Validate
bool valid = schema.Validate("""{"name": "Alice", "age": 30}""");

Compiled schemas are cached automatically by their canonical URI, so the first validation incurs a compilation cost (around 100ms) but subsequent calls are sub-millisecond.

Multiple input formats

The Validate() method accepts JSON in whatever format you already have it:

// UTF-8 bytes (zero copy from a network buffer)
bool valid = schema.Validate(utf8Bytes);

// Stream (HTTP request body, file stream)
bool valid = schema.Validate(stream);

// Pre-parsed element
using var doc = ParsedJsonDocument<JsonElement>.Parse(json);
bool valid = schema.Validate(in doc.RootElement);

Pre-loading referenced schemas

If your schema uses $ref to reference other schema files, you can pre-load them to avoid file system or network resolution:

var options = new JsonSchema.Options(
    additionalSchemaFiles: new[]
    {
        new AdditionalSchemaFile(
            "https://example.com/schemas/address.json",
            "Schemas/address.json")
    });

JsonSchema schema = JsonSchema.FromFile("person.json", options: options);

This is particularly useful in CI/CD environments where external resolution may be unreliable or disallowed.

Conformance

We take correctness seriously. The V5 engine passes the official JSON Schema Test Suite for all supported drafts, and we publish results to Bowtie - the cross-implementation conformance project.

Next up

We've seen validation from the caller's perspective. In the next post, we'll go deeper into the V5 memory model. We'll look at how ParsedJsonDocument<T> uses ArrayPool to achieve just 136 bytes per document.

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 needs a large context to cover all domains, which drives up token usage and increases the chance of confusion
• Tool access becomes an all-or-nothing decision — you either give the agent everything or nothing
• The agent's behaviour is hard to constrain to specific task types without prompt gymnastics

Custom agents solve this by letting you define specialised agents with scoped prompts, restricted tool sets, and their own optional MCP servers — all within a single session. The Copilot runtime acts as the orchestrator, automatically delegating user requests to the most appropriate sub-agent based on the task.

Custom agents

Custom agents are lightweight agent definitions you attach to a session. Each agent has its own system prompt, tool restrictions, and optional MCP servers. When a user's request matches an agent's expertise, the Copilot SDK runtime automatically delegates to that agent as a sub-agent — running it in an isolated context while streaming lifecycle events back to the parent session.

Here's the minimal .NET setup:

using GitHub.Copilot.SDK;

var session = await client.CreateSessionAsync(new SessionConfig
{
    Model = "gpt-4.1",
    CustomAgents =
    [
        new CustomAgentConfig
        {
            Name = "researcher",
            DisplayName = "Research Agent",
            Description = "Explores codebases, reads files, and answers questions. " +
                          "Use for analysis, investigation, and understanding tasks.",
            Tools = ["grep", "glob", "view"],       // read-only tools only
            Prompt = "You are a research assistant. Analyse code and answer questions " +
                     "without making any changes."
        },
        new CustomAgentConfig
        {
            Name = "editor",
            DisplayName = "Editor Agent",
            Description = "Writes and modifies code. Use for implementation, " +
                          "refactoring, and code generation tasks.",
            Tools = ["grep", "glob", "view", "edit", "write"],
            Prompt = "You are a code editor. Make minimal, precise changes. " +
                     "Always verify the change compiles before finishing."
        }
    ]
});

With this setup, a prompt like "explain what this authentication middleware does" will route to the researcher agent, while "add retry logic to the HTTP client" will route to the editor agent. The user doesn't know which agent is handling their request — they just get a better, more focused answer.

On descriptions: a good description helps the runtime match user intent to the right agent. Be specific about the agent's expertise and capabilities. Think of the description the same way you'd write a skill description: it's a semantic index, not a display label.

Pre-selecting an agent

By default, the runtime picks the most appropriate agent for each turn. If you want to start a session with a specific agent active — for a workflow where you know the first task type — set the Agent property on SessionConfig:

var session = await client.CreateSessionAsync(new SessionConfig
{
    Model = "gpt-4.1",
    Agent = "researcher",   // start with the researcher active
    CustomAgents = [ /* ... */ ]
});

The value must match the Name of one of the agents defined in CustomAgents. This is useful when your application's entry point is task-specific — a "review this PR" button should probably start in the researcher agent rather than letting the runtime decide from a cold start.

The three orchestration patterns

Custom agents support three orchestration patterns, each suited to different workflow shapes.

Pattern 1: Automatic delegation

The simplest pattern. You define agents, send prompts, and the runtime routes automatically. The user (or calling code) stays unaware of which agent is active.

This is the default behaviour shown above. It works well for interactive sessions where task types are mixed and unpredictable. The runtime's delegation logic is based on the agent descriptions. Precise descriptions produce more reliable routing.

Pattern 2: Agent handoffs

Handoffs work best when you want a clear human-in-the-loop moment, such as reviews, approvals, or sensitive checks. One agent completes its work and explicitly transfers control to another, optionally passing a summary of what it did.

A practical example: a security review followed by a remediation step, where you want to inspect the findings before allowing code changes:

var session = await client.CreateSessionAsync(new SessionConfig
{
    Model = "gpt-4.1",
    CustomAgents =
    [
        new CustomAgentConfig
        {
            Name = "auditor",
            Description = "Reviews code for security vulnerabilities. Read-only.",
            Tools = ["grep", "glob", "view"],
            Prompt = """
                You are a security auditor. Review the code for vulnerabilities.
                When done, produce a structured findings report and hand off to
                the 'remediator' agent with a summary of what needs fixing.
                """
        },
        new CustomAgentConfig
        {
            Name = "remediator",
            Description = "Applies security fixes identified by the auditor.",
            Tools = ["grep", "glob", "view", "edit", "write"],
            Prompt = """
                You are a security engineer. You receive findings from the auditor.
                Apply the minimum change necessary to address each finding.
                Explain each change as you make it.
                """
        }
    ]
});

// Auditor runs, produces findings, hands off to remediator
var result = await session.SendAndWaitAsync(new MessageOptions
{
    Prompt = "Audit the authentication module for security vulnerabilities and fix any issues found"
});

The handoff happens inside the session — the remediator picks up where the auditor left off, with access to the auditor's findings in context.

Pattern 3: Explicit sub-agent delegation

With explicit sub-agent delegation, a primary agent programmatically invokes other custom agents to handle well-defined subtasks. Unlike handoffs, the user does not switch agents. A parent orchestrator breaks down complex tasks and dispatches them to specialists, then assembles the results.

This is the most structured pattern, and the right choice for repeatable, multi-step pipelines:

var session = await client.CreateSessionAsync(new SessionConfig
{
    Model = "gpt-4.1",
    CustomAgents =
    [
        new CustomAgentConfig
        {
            Name = "orchestrator",
            Description = "Coordinates the full code review pipeline. Entry point for all requests.",
            Tools = [],   // orchestrator doesn't use tools directly
            Prompt = """
                You are a pipeline orchestrator. For every code review request:
                1. Delegate to the 'linter' agent to check style and formatting
                2. Delegate to the 'tester' agent to verify test coverage
                3. Delegate to the 'security' agent to check for vulnerabilities
                4. Synthesise all findings into a single structured report
                Never perform any of these tasks yourself — always delegate.
                """
        },
        new CustomAgentConfig
        {
            Name = "linter",
            Description = "Checks code style, formatting, and conventions.",
            Tools = ["grep", "glob", "view"],
            Prompt = "You are a linting specialist. Check code against established style conventions."
        },
        new CustomAgentConfig
        {
            Name = "tester",
            Description = "Reviews test coverage and test quality.",
            Tools = ["grep", "glob", "view"],
            Prompt = "You are a testing specialist. Evaluate test coverage and flag gaps."
        },
        new CustomAgentConfig
        {
            Name = "security",
            Description = "Reviews code for security vulnerabilities.",
            Tools = ["grep", "glob", "view"],
            Prompt = "You are a security specialist. Review for OWASP Top 10 and common .NET security issues."
        }
    ],
    Agent = "orchestrator"
});

The prompt always enters the orchestrator, which breaks the task into sub-tasks and dispatches each to the appropriate specialist. The caller writes one prompt; three specialised agents execute.

Giving Custom Agents Their Own MCP Servers

Custom agents can each have their own MCP server configuration, independent of what the session-level MCP servers provide. This is powerful for tight tool scoping: the researcher agent can read from a knowledge base, while the editor agent has access to a build system, and neither can use the other's tools:

new CustomAgentConfig
{
    Name = "azure-ops",
    Description = "Manages and queries Azure resources.",
    Prompt = "You are an Azure operator. Use Azure tools to answer questions and take actions.",
    McpServers = new Dictionary<string, McpServerConfig>
    {
        ["azure"] = new McpStdioServerConfig
        {
            Command = "npx",
            Args = ["-y", "@azure/mcp@latest", "server", "start"],
            Tools = ["azure_resource_group_list", "azure_storage_account_list"]
        }
    }
}

Observing sub-agent activity

Sub-agent lifecycle events flow through the same event system as the parent session. You can distinguish parent and sub-agent events by the AgentName property on the event data:

session.On<SubagentStartedEvent>(evt =>
    _logger.LogInformation(
        "[{Agent}] started: {Tool}",
        evt.Data.AgentDisplayName,
        evt.Data.ToolCallId));

session.On<SubagentCompletedEvent>(evt =>
    _logger.LogInformation(
        "[{Agent}]completed",
        evt.Data.AgentDisplayName));

If OpenTelemetry is configured, each sub-agent's work appears as a child span under the parent invoke_agent span, giving you a complete trace of delegation chains without additional instrumentation.

When to use custom agents vs. multiple sessions

Custom agents are the right tool when tasks share a conversation — when earlier context should inform later steps, and delegation happens within a single coherent workflow. Multiple independent sessions are the right tool when tasks are fully isolated — separate users, unrelated jobs, or workflows where shared context would be a liability rather than an asset.

A useful heuristic: if the agents need to read each other's outputs, use custom agents in one session. If they don't, use separate sessions.

What’s next

Although the support for custom agents in the GitHub Copilot SDK is a good starting point, the level of control and flexibility in a multi-agent setup is still limited compared to other frameworks like the Microsoft Agent Framework. The good news is that the GitHub Copilot SDK integrates nicely and that is exactly we’ll take a look at in our final post tomorrow. 

More information

This has results from sysbench on a small server with Postgres 19 beta1, 18.4 and 17.10. Sysbench is run with low concurrency (1 thread) and a cached database. The purpose is to search for changes in performance, often from new CPU overheads.

tl;dr

• 19beta1, 18.4 and 17.10 have mostly similar performance
• There might be small regressions (about 2%) from 17.10 to 19beta1 but my tests are not good at spotting that.
• 19beta1 is much faster on one test (read-only-count) thanks to a new query plan

Windows App SDK 2.2 Experimental 9 (2.2.2-experimental9) 🧪

Windows App SDK 2.2 Experimental 9 is the latest experimental release. It ships alongside Windows App SDK 2.2.0 stable and generally brings over the changes from that release; the highlights below describe the experimental-only additions.

What's new in WinAppSDK 2.2 Experimental 9:

• Language Model APIs on GPU [Experimental]. The Language Model APIs now run on non-Copilot+ PCs equipped with a supported GPU, bringing local language model capabilities to a broader range of Windows 11 devices. Supported hardware includes NVIDIA GeForce RTX 30 series and newer with 6+ GB vRAM. GPU inference requires Developer Mode to be enabled and a Windows Insider Experimental Channel build. The GPU model is not pre-installed; it is downloaded on demand via EnsureReadyAsync through Windows Update. Apps should check GetReadyState and display a consent dialog before triggering the download. Users can manage the model at Settings > System > AI Components. For responsible AI guidance, see the new Transparency Note: Language Model APIs on Non-Copilot+ PCs.
• Speech Recognition APIs [Experimental]. New on-device speech recognition APIs in Microsoft.Windows.AI.Speech enable both batch and streaming speech-to-text. BatchRecognition recognizes a complete audio source in a single call, and StreamingRecognition raises Recognizing and Recognized events. Audio can be sourced from a device (AudioConfiguration.FromAudioDevice), file (FromFile), input stream (FromStream), or pushed by the caller via SpeechAudioProvider (16 kHz, 16-bit, single-channel PCM). The on-device model is managed via SpeechRecognitionModel.EnsureReadyAsync / TryCreateAsync, with download and load progress reported through SpeechRecognitionModelProgress.
• New NpuType API. A new Microsoft.Windows.Workloads.NpuType enum surfaces the NPU class on the current device (for example, Qnn, Lnl, Stx, Win365, Unknown, None), so apps and Workloads infrastructure can route AI workloads to the appropriate execution path.

This release also rolls forward all changes from the 2.2.0 stable release: the new Microsoft.Windows.AI.Video.VideoScaler Video Super Resolution API, the new Microsoft.Windows.Storage.ApplicationData.GetForUnpackaged() entry point for unpackaged apps, the new XamlBindingHelper boxing-free setter overloads, and the WinUI / Windows ML reliability fixes shipped in 2.2.0.

New or updated APIs (since 2.1 Experimental 8):

Microsoft.UI.Xaml

    Setter
        ValueProperty

Microsoft.UI.Xaml.Markup

    XamlBindingHelper
        SetPropertyFromColor
        SetPropertyFromCornerRadius
        SetPropertyFromThickness

Microsoft.Windows.AI.Speech

    AudioConfiguration
    BatchRecognition
    SpeechAudioProvider
    SpeechContract
    SpeechRecognitionModel
    SpeechRecognitionModelProgress
    SpeechRecognitionModelProgressStatus
    SpeechRecognitionModelResult
    StreamingRecognition
    StreamingRecognizedEventArgs
    StreamingRecognizingEventArgs

Microsoft.Windows.AI.Text.Experimental

    LanguageModelExperimental
        CompressPromptAsync
        GenerateResponseAsync
        GenerateResponseFromEmbeddingsAsync

    LanguageModelOptionsExperimental
        PreferredRetentionRatio

Microsoft.Windows.Workloads

    NpuType

Try it out

• Download the 2.2.2-experimental9 NuGet package to use WinAppSDK 2.2 Experimental 9 in your app.

Getting started

To get started using Windows App SDK to develop Windows apps, check out the following documentation:

• Install developer tools.
• Create a WinUI 3 app.
• Continue your development journey.

Windows App SDK 2.2.0

WinAppSDK 2.2.0 is the latest stable servicing release for 2.0, with a new Windows AI video upscaling API, a first-class ApplicationData entry point for unpackaged apps, additions to XamlBindingHelper, and a batch of WinUI and Windows ML reliability fixes.

What's new in WinAppSDK 2.2.0:

• Video Super Resolution AI API. The new Microsoft.Windows.AI.Video.VideoScaler API delivers real-time video enhancement through advanced AI upscaling, optimized for streams featuring people in conversation. It enables developers to provide sharper, clearer visuals across conferencing, streaming, and editing platforms, even under poor network conditions. The API supports customization of output resolution, frame rate, and regions of interest, with compatibility for multiple video formats including BGR, RGB, and NV12. VideoScaler is disposable, and includes a capability check so apps can validate VSR support at runtime. Explicit Windows ML initialization is not required.
• New ApplicationData API for unpackaged apps. Microsoft.Windows.Storage.ApplicationData.GetForUnpackaged() gives unpackaged apps a first-class WinRT entry point to per-user / per-machine application data, matching the surface previously available only to packaged apps. This simplifies future packaged ↔ unpackaged migration and removes the need for Registry-API workarounds.
• New XamlBindingHelper APIs. Added boxing-free value setter overloads to XamlBindingHelper (SetPropertyFromThickness, SetPropertyFromCornerRadius, SetPropertyFromColor) and exposed the Setter.ValueProperty dependency property.

Bug fixes:

New or updated APIs (since 2.1.3):

Microsoft.UI.Xaml

    Setter
        ValueProperty

Microsoft.UI.Xaml.Markup

    XamlBindingHelper
        SetPropertyFromColor
        SetPropertyFromCornerRadius
        SetPropertyFromThickness

Microsoft.Windows.AI.Video

    VideoScaler
    VideoScalerOptions
    VideoScalerResult
    VideoScalerStatus

Microsoft.Windows.Storage

    ApplicationData
        GetForUnpackaged

Try it out

• Download the 2.2.0 NuGet package to use WinAppSDK 2.0 in your app.
• Download and update the WinUI Gallery to see the WinUI 3 updates firsthand.

Getting started

To get started using Windows App SDK to develop Windows apps, check out the following documentation:

• Install developer tools.
• Create a WinUI 3 app.
• Continue your development journey.

Windows App SDK 1.8.9 (1.8.260529003)

WinAppSDK 1.8.9 is the latest stable servicing release for 1.8, with two reliability fixes in WinUI input and items controls.

Bug fixes:

Try it out

• Download the 1.8.260529003 NuGet package to use WinAppSDK 1.8 in your app.

Getting started

To get started using Windows App SDK to develop Windows apps, check out the following documentation:

• Install developer tools.
• Create a WinUI 3 app.
• Continue your development journey.