A bit of a lull before the BUILD conference next week. Highlights this week include: Claude Opus 4.8 is now available in Microsoft Foundry: Anthropic's most capable Opus model is now available in Microsoft Foundry, built for complex coding, reliable multi-step agentic tasks, and document-heavy enterprise analysis that holds context across longer sessions. Automate evaluations Microsoft Foundry: A walkthrough of Foundry's evaluation tooling, covering end-to-end run tracing, on-demand synthetic test datasets, automated red-team attacks, AI-driven root-cause analysis of failures, and runtime guardrails such as Task Adherence that inspect every tool call. Azure Functions MCP extension now supports MCP Prompts: The Azure Functions MCP extension now supports MCP prompt triggers in public preview, completing coverage of all three core Model Context Protocol primitives (tools, resources, and prompts) for building MCP servers on Azure Functions.

In Analytics: Incremental Liquid Clustering in Microsoft Fabric: Faster, smarter, and truly incremental: Now in Fabric Runtime 2.0, Incremental Liquid Clustering re-clusters only the data that needs it, keeping clustering time roughly flat as tables grow rather than rising linearly, which makes OPTIMIZE costs far more predictable. From Excel to Delta Tables - Simplifying Excel Data Ingestion with Shortcut Transformations Preview: Fabric's Shortcut Transformations (Preview) now extend their zero-code ingestion experience to Excel, letting teams bring spreadsheet data into Delta tables the same way they already do with CSV, Parquet, and JSON.

In preview Public Preview: Azure Site Recovery Support for Performance Plus Managed Disks: Azure Site Recovery can now replicate virtual machines that use Performance Plus enabled managed disks (Premium SSD, Standard SSD, and Standard HDD), giving high-IOPS and high-throughput workloads Azure-to-Azure disaster recovery with consistent performance across primary and secondary regions during replication, test failover, and full failover. How to use Instance Mix with Azure Virtual Machine Scale Sets: Instance Mix lets a Flexible-orchestration Virtual Machine Scale Set define up to five compatible VM sizes under a single "Mix" SKU, so Azure can choose from that list at scale-out based on your allocation strategy to ease regional capacity, quota, and pricing constraints.

Finally, Entra Automation: Users, Groups, and Conditional Access: A tutorial on using Microsoft Graph PowerShell to automate Entra ID user creation, security groups, group membership, and Conditional Access policies, with report-only mode for validating changes safely before enforcement.

Welcome to F# Weekly,

A roundup of F# content from this past week:

News

• Angel Munoz: Mibo.Raylib 1.0.0 is Out – F# micro framework for code-first Raylib games
• Loïc Denuzière: Domain Modeling Made Functional is in the Functional Programming Humble Bundle

Microsoft News

• Doing More with GitHub Copilot as a .NET Developer
• Give Your .NET MAUI Android Apps a Material 3 Makeover
• A hypothetical redesign of System.Diagnostics.Process to avoid confusion over properties that are valid only when you are the one who called Start – The Old New Thing
• How Azure Chaos Studio ships with hermetic Aspire end-to-end tests | Aspire Blog
• What’s new in Microsoft Foundry | May 2026 | Microsoft Foundry Blog
• Improve your agentic developer tools by grounding in Microsoft Learn – Microsoft for Developers
• Verification-driven tooling prompts for fast-moving codebases – ISE Developer Blog
• How AI coding agents actually use your technology – Microsoft for Developers
• Visual Studio Code 1.122
• Visual Studio May Update – Plan, Review, Refine – Visual Studio Blog

Videos

• Ryan Riley: Development Process using AI – Episode 403
• .NET AI Community Standup: .NET + AI at Build 2026: What’s Coming Next? – YouTube
• .NET Data Community Standup: 8 Real-World Query Anti‑Patterns (and How to Fix Them) – YouTube

Blogs

• Urs Enzler: Event Sourcing – Why We Built Our Own Library
• How I use Rider for F# web development | by Vladimir Shchur | May, 2026 | Medium

Highlighted projects

• EHotwagner/FS-Skia-UI: Experimental F# desktop UI toolkit built on SkiaSharp and Vulkan using an Elmish Model-View-Update model
• mrLSD/riscv-fs: F# RISC-V Instruction Set formal specification
• fable-compiler/Fable: F# to JavaScript, TypeScript, Python, Rust, Erlang and Dart Compiler (Fable 5.1.0 released)

New Releases

• Pulsar.Client 3.16.0
• Fable 5.1.0
• SQLProvider 1.5.21
• FsShelter 5.2.1
• WoofWare.Myriad.Plugins 9.1.6
• Fesh 0.32.3
• Bristlecone 3.1.1
• Polars.FSharp 0.5.0
• Fable.TypedJson 0.4.0
• UnionConfig 0.4.1
• CommandTree 0.5.1
• Falco.UnionRoutes 0.3.2
• Mibo.Raylib 1.0.0
• SwaggerProvider 4.1.0
• Serde.FS 1.0.0-beta.1

That’s all for now. Have a great week.

If you want to help keep F# Weekly going, click here to jazz me with Coffee!

We are happy to announce that we have just released Cordova iOS 8.1.0! This is one of Cordova's supported platforms for building iOS applications.

This release contains fixes for several bugs that were reported against the 8.0.1 version.

• cordova-ios@8.1.0

To upgrade:

cordova platform remove ios
cordova platform add ios@8.1.0

To install:

cordova platform add ios@8.1.0

Release Highlights

• Fix for Ionic WebView plugin

  Re-add an implementation of the deprecated shouldOverrideLoadWithRequest:navigationType: selector because the Ionic WebView plugin relies on it.

• Fix /_app_file_/ URLs not working

  During refactoring of the URLSchemeTask handler for cordova-ios 8, an error was introduced where /_app_file_ URLs were treated as being relative to the resources directory rather than as filesystem paths.

• Fixes various build issues

Changes include:

Fixes:

• GH-1653 fix(actions): fix CDVURLSchemeHandlerTest warnings
• GH-1652 fix(actions): IPhone 16e not found on macOS 26 for latest OS
• GH-1640 fix: NSInternalInconsistencyException: "No response has been sent for this task" - second attempt
• GH-1637 fix(build): Target a generic iOS simulator for building
• GH-1632 fix(ionic): Add workaround for Ionic WebView plugin
• GH-1618 fix(xcode): Fix library search paths for target
• GH-1621 fix(xcode): Ensure we do NFD normalization on PRODUCT_NAME
• GH-1616 fix(spm): Ensure the deployment target always gets set
• GH-1606 fix(webview): Ensure scheme task is always finished
• GH-1610 fix(scheme): Fix /app_file/ URLs not working
• GH-1612 fix(spm): Set deployment target in Package.swift
• GH-1597 fix: ignore spm build artifacts

Others:

• GH-1650 chore: remove redundant Hello World template files
• GH-1647 chore(deps): bump @xmldom/xmldom from 0.8.12 to 0.8.13
• GH-1634 doc: keepCallback and setKeepCallbackAsBool: of CDVPluginResult
• GH-1646 chore(deps): bump lodash from 4.17.23 to 4.18.1
• GH-1644 chore(deps): bump @xmldom/xmldom from 0.8.11 to 0.8.12
• GH-1642 chore(deps): bump picomatch
• GH-1639 chore: update package-lock
• GH-1635 chore: Fix improperly ignored deprecation warning
• GH-1633 chore: Bump patch level for ongoing dev work
• GH-1628 chore: Fix missing licence headers
• GH-1627 release(8.0.1): Update release notes and version
• GH-1623 chore(ci): draft release
• GH-1624 chore: cleanup license headers
• GH-1625 chore: add DEVELOPMENT.md & cleanup README.md
• GH-1622 refactor(versions): Refactor version code for test reliability
• GH-1619 chore(deps): Update to latest jasmine & c8 versions
• GH-1614 doc(readme): improve badges
• GH-1601 chore: Remove compileBitcode from export options
• GH-1611 chore: set swift-tools-version to 5.9
• GH-1599 chore(deps): bump lodash from 4.17.21 to 4.17.23
• GH-1598 Add missing trailing new line
• GH-1592 doc(readme): add minimum iOS version
• GH-1591 doc(readme): add Link to iOS Platform Guide
• GH-1588 chore: update release audit workflow & license headers

The single insight that changes everything

Most "build an AI agent" tutorials collapse two completely different jobs into one tangled mess:

• the job of building an agent (writing the code, defining its tools, evaluating it, packaging it), and
• the job of running an agent (planning, reasoning, calling tools, remembering users, delivering outcomes).

Once you separate them, modern agent development becomes a clean two-layer architecture:

A Coding Agent sits on top — that's how you produce an agent. A Runtime Agent sits below — that's the agent your business operates. Microsoft Agent Framework is the SDK that ties them together; Microsoft Foundry is the platform both layers publish to and run on.

But the secret ingredient — the thing that turns a generic Copilot into a domain-aware engineer — is the SKILL. SKILL is what the Coding Agent reads before writing a single line. It's how requirements become artifacts that actually match your framework, your conventions, and your fixtures.

This post walks the entire two-layer architecture, in the order you should learn it — with SKILL as the star of Layer 1. We ground every concept in ZavaShop, a fictional global e-commerce company with 5 fulfillment centers, dozens of suppliers, and a CEO who wants one live dashboard for all of it. Both Python and .NET (C#) are first-class — pick the language your team will run in production.

LAYER 1 — The Coding Agent (Build Time)

The Coding Agent is not the agent your customer talks to. It's the agent that constructs the agent your customer talks to. Its output is a bundle of artifacts — code, agent definitions, workflows, skills, connectors, evals, tests, configs, docs — that flow through validation and into Foundry.

Build time has five movements.

Movement 1 — Requirements & Planning

Before the Coding Agent writes a single line, you owe it three things:

1. A real business pain. Not "let's build an agent." Rather: "Mei, the supervisor at Seattle DC, gets interrupted 60 times a day by stock-level questions."
2. A list of acceptance criteria. What does "done" look like? "Agent answers stock questions for SKUs in our 10-SKU catalog. P95 latency under 4s. Wrong-tool rate under 5% on the eval set."
3. The fixtures it'll run on. Real or realistic data — warehouses, SKUs, POs, customers — so the Coding Agent isn't reasoning about a vacuum.

ZavaShop context. The workshop ships workshop/data/ — 5 warehouses, 10 SKUs, 6 POs, 8 suppliers, 5 contracts, 4 customers (3 VIP), 6 orders, 5 carriers, 4 open exceptions. Every artifact the Coding Agent generates is anchored to this shared fixture set, so numbers stay consistent across the entire system.

Movement 2 — The Coding Agent + its SKILL (the star of build time)

This is the movement most teams skip — and it's the one that decides whether your build-time output is professional code or "ChatGPT-shaped" code.

What a Coding Agent actually is

The Coding Agent is GitHub Copilot Chat in Agent Mode, configured with a domain-aware agent definition. In the ZavaShop workshop, it lives at .github/agents/zavashop-coding-agent.agent.md and is activated from the VS Code Agent picker. You start each session with one plain sentence:

"I'm working on the inventory agent in Python — wire up stock and PO lookups against the fixtures, plus a HostedMCPTool for the warehouse handbook."

Notice what's not in that sentence: no library names, no class names, no file paths. The Coding Agent has to fill all of that in. The mechanism it uses is the SKILL.

What a SKILL is

A SKILL is a structured contract that teaches the Coding Agent how to write code in your framework, your conventions, and your domain. It is the most important file in the entire build-time layer — without it, GitHub Copilot is a fluent generalist; with it, it becomes a domain-aware specialist that writes code your tech leads would have written.

Conceptually, a SKILL contains:

A SKILL is versioned with the codebase. When the framework releases a new idiom, you update the SKILL once; every agent built afterwards picks it up automatically. This is the single biggest reason convention drift disappears.

The six SKILLs in the ZavaShop workshop

The workshop ships six SKILLs — three for each language track — and they cover three orthogonal capability surfaces:

How the Coding Agent uses SKILL

The Coding Agent's loop is SKILL-first, code-second:

The discipline is captured in the workshop's one mantra:

"Read the SKILL first."

It is not optional. Skip it and you're back to generic Copilot output.

Movement 3 — A worked example: from a single sentence to a runnable agent

Let's trace what happens when you sit down in front of the Coding Agent and say:

"I'm working on the inventory agent in Python — wire up stock and PO lookups against the fixtures, plus a HostedMCPTool for the warehouse handbook."

Step 1 — The Coding Agent routes

The Coding Agent's definition (.github/agents/zavashop-coding-agent.agent.md) contains a routing table:

It loads both files into context before doing anything else.

Step 2 — The Coding Agent plans

Using the SKILL's patterns and the LAB's acceptance criteria, it generates a plan:

Every item in the plan traces back to either the SKILL (how) or the LAB README (what). No invention, no guessing.

Step 3 — The Coding Agent generates

Now — and only now — it writes code. Because the SKILL specified the patterns, what comes out is shaped like the rest of your codebase:

Notice the things the SKILL enforced without you having to ask: env-var-driven config, named function tools with docstrings, sys.path data-loader pattern, HostedMCPTool placed alongside function tools, Thread for multi-turn.

Step 4 — The Coding Agent validates

The SKILL also told it how to validate. The Coding Agent runs:

• a smoke test against fixtures (SKU-7421 @ SEA-01 → 312),
• the eval set (eval_queries.jsonl) — was the right tool called? did the answer contain the expected fact?
• a red-team probe round.

It reports back: "3/3 acceptance criteria pass. Eval score 5/5. Red-team: no successful prompt injections."

Step 5 — Done

What landed in your repo is not just a script. It's an artifact bundle — code + agent definition + tools + eval rows + a one-page README — that matches the way your team writes agents. That bundle is what flows into the next three movements.

Movement 4 — Agent Artifacts (the outputs)

A well-instructed Coding Agent produces eight kinds of artifact. Together they make up "an agent" in the deployable sense:

Don't confuse two senses of "skill" here. A SKILL file (uppercase, in .github/skills/) instructs the Coding Agent at build time. An Agent Skill (a Foundry concept) is a named runtime capability the Runtime Agent calls. Both names are deliberate — Layer 1's SKILL produces, among other artifacts, Layer 2's Skills.

Movement 5 — Validation

Before any artifact reaches Foundry, four gates run:

1. Tests — unit + integration. Did find_stock("SKU-7421", "SEA-01") return 312, the value in the fixture?
2. Lint & types — ruff/mypy on Python, dotnet build warnings on .NET. The model has to read these signatures; sloppy ones cause real bugs.
3. Evaluation — run the eval set. Did the right tool get called? Did the answer contain the expected fact? You need a score, not a vibe.
4. Red-Team probes — adversarial inputs that try to drift the agent off topic or extract another customer's data. The Foundry red-team SDK ships a battery of these.

Evangelist takeaway. "We built an agent" is not a deliverable. "We built an agent and here is its pass rate on a versioned eval set, plus a red-team report" is a deliverable. Validation belongs at build time, not "we'll add it later."

Movement 6 — Publish & Deploy

When validation is green, the Coding Agent's outputs flow into Foundry and Azure:

• Push to Microsoft Foundry — agent definitions, Skills, Toolbox tools, and custom evals register against your Foundry project. They are now governed, versioned, and observable.
• Deploy to Azure — the runtime host (AG-UI server, workflow worker, Teams app, API surface) ships to your Azure target (App Service, Container Apps, AKS, Functions). Same env vars drive local dev and cloud.

The same artifact set deploys to dev, staging, and production. There is no "production-only" code in your agent.

LAYER 2 — The Runtime Agent (Runtime)

Now the agent is live. Every conversation, every action against your data, every memory it writes — that's Layer 2. Five concerns define it.

Concern 1 — Users & Channels

A Runtime Agent reaches users through the channels they already use:

• Microsoft Teams — the agent shows up where work already happens.
• Outlook — triage, reply, summarize, schedule.
• Custom web / mobile / voice — built on AG-UI, which ships a React client covering streaming text, frontend tools, backend tools, shared state, generative UI, predictive updates, HITL prompts.

The channel is a deployment choice, not an architectural choice. The same agent definition can surface in Teams and on a React dashboard.

ZavaShop context. Mei's agent shows up in Teams. The CEO's control tower is a React app on top of AG-UI. The agent definition behind both is the same artifact set the Coding Agent produced.

Concern 2 — The Runtime Agent itself

The Runtime Agent is the loop you've heard about a thousand times — now it's a concrete piece of architecture:

AIAgent = model + instructions + tools + thread

Inside the loop:

1. The model plans & reasons about the next step.
2. It calls tools through MCP, Toolbox, or local functions.
3. It reads & writes memory.
4. It streams output back to the channel.

Concern 3 — Tools & Integrations (the runtime capability surface)

At runtime, a Runtime Agent reaches the outside world through four kinds of capabilities — and which one to use is a real engineering decision:

Mental progression:

You don't have to start with Toolbox — but the moment a second agent touches the same domain, migrate.

ZavaShop context. Local fixtures → function tools. The warehouse handbook → MCP. Supplier-portal connectors shared by procurement, fulfillment, and finance → Toolbox tools. "Validate-PO-against-contract" → an Agent Skill.

Concern 4 — Memory & State

State at runtime comes in two flavors:

Thread = state inside one conversation

Memory = state across conversations

Foundry Memory is durable, retrievable knowledge about a user — VIP status, packaging preferences, delivery windows. Memory holds stable preferences and facts, not chat transcripts.

ZavaShop context. Customer service agent Aria remembers across sessions that C-204 is VIP, prefers no cardboard, and wants 6–8pm delivery.

Concern 5 — Actions & Outcomes

Real systems take actions that change state and produce outcomes other systems observe:

• Trigger events — kick off a workflow, page a human.
• Generate outputs — write a PO, draft an email, push to a record.
• Notify channels — send back to Teams, update a dashboard, hit a webhook.
• Observability — every action streams to Application Insights / Azure Monitor.

This is also where Workflows live. WorkflowBuilder is Agent Framework's orchestration primitive:

Three workflow features matter most:

1. Reuse, don't rebuild — tools written at build time are workflow nodes at runtime.
2. Human-in-the-Loop (HITL) — pauses, asks a human, resumes from the exact step.
3. Checkpointing — workflows survive process restarts.

ZavaShop context. Fulfillment director Diego's team handles a $10K+ exception every day. Before: an email chain across 5 teams. After: a WorkflowBuilder graph with one HITL approval and full audit trail.

Cross-cutting: the shared services that make this safe

Both layers sit on top of platform services non-negotiable for enterprise deployment:

Skip this row and you have a demo that has not yet failed.

Mapping the ZavaShop workshop to the architecture

Layer 1 artifacts shipped in the repo:

• .github/agents/zavashop-coding-agent.agent.md — the Coding Agent definition
• .github/skills/agent-framework-{azure-ai,workflows,agui}-{py,csharp}/ — the six SKILLs
• workshop/data/ — shared fixtures every artifact grounds in
• Per-lab READMEs + eval_queries.jsonl — Layer 1 validation inputs

Layer 2 artifacts produced over the course of the workshop:

• A single agent (Zara) — function tools + HostedMCPTool + Thread
• A procurement agent (Pierre) — Toolbox + Agent Skills + approval policy
• A customer-service agent (Aria) — Foundry Memory + Evaluation + Red-Team
• A multi-agent fulfillment workflow (Diego) — WorkflowBuilder + HITL + Checkpoint
• An AG-UI control tower for the CEO — covering all 7 AG-UI features

Same model across the stack — gpt-5.5 on Foundry + text-embedding-3-small. Change one env var, run the same artifact in the other language.

Three habits that separate strong agent engineers

1. Read the SKILL first. Make it ritual. The Coding Agent does it automatically; you should do it manually when reviewing the agent's output.
2. Treat tools as a public API. Names, signatures, docstrings, return shapes — they are how the model sees your system at runtime. Refactor them like any other API.
3. Measure before you tune. A prompt change without an eval delta is a vibe. With one, it's engineering.

Getting started in 60 seconds

The one mantra: "Read the SKILL first."

Closing thought

Modern agent development is not one job — it's two. The Coding Agent designs and builds; the Runtime Agent operates and delivers. Microsoft Agent Framework is the SDK that makes both layers feel like the same conceptual model. Microsoft Foundry is the platform both layers publish to and run on.

And the engine that turns a generic Copilot into a domain-aware engineer — that takes a sentence-long requirement and lands a runnable, validated, deployable artifact — is the SKILL. Write a good SKILL once, and every agent built afterwards inherits your team's taste, your fixtures, your patterns, your discipline.

The ZavaShop workshop is the smallest end-to-end example I can give you that actually exercises both layers, with six SKILLs ready to read. Walk it once, and the next time someone asks "how do we build agents in our org?", you won't be pointing at a tutorial — you'll be pointing at an architecture.

👉 Start with the workshop on GitHub