The entire discovery layer is missing from the agentic stack.

ARD: the spec

Agentic Resource Discovery (ARD) is an open spec — v0.9 draft, published under the Linux Foundation. Microsoft, Google, GitHub, Hugging Face, GoDaddy, NVIDIA, Salesforce, Snowflake, Cisco, Databricks, and ServiceNow are all behind it.

It gives registries a standard way to advertise what they have, and gives clients a standard way to search across them. The analogy people reach for is DNS — your agent asks “who can do X?” and the registry answers with matching resources and connection details. It sits before invocation, works with MCP servers, A2A agents, OpenAPI services, CLIs, skills, whatever, and is federated so multiple registries can coexist and cross-reference each other.

The spec defines a query model (text search, faceted filters, pagination), a manifest format for describing resources, conformance rules, and federation referrals that let one registry point you to another.

As Angie Jones explains in her writeup on AI Catalog, discovery is an ecosystem problem, not a protocol-specific one. An agent workflow might need an MCP server for market data, an A2A agent for reasoning, a CLI tool for local operations, and a skills plugin for domain prompts. Each artifact type has its own native metadata format — ARD doesn’t try to replace those. It provides a common discovery layer around them: a typed JSON catalog where each entry declares what kind of artifact it is via mediaType, and clients can fetch and process entries they understand while skipping the rest.

Real implementations, not just a spec

The reason I’m writing about this now and not in six months is that real implementations already exist:

GitHub Agent Finder — built into GitHub Copilot. Instead of pre-loading every MCP server into the context window, Copilot searches GitHub’s curated catalog of AI resources (or your own private registry) and surfaces ranked matches on demand. Agent finder only finds — it doesn’t auto-install anything. You stay in control.

Hugging Face Discover — provides search access to thousands of skills, ML applications, and MCP servers on Hugging Face and other ARD registries.

Cisco AI Catalog and Ora Directory — additional reference registries you can query today.

Google’s announcement post and Microsoft’s post on the Command Line blog both go into more detail on the motivation and architecture.

The problem: specs are hard to explore

I’ve been working with ARD, and the usual problem with new specs applies — you want to poke at real endpoints, try queries, see what the response looks like, validate your manifest, but there’s no easy way to do that without writing throwaway code.

MCP had MCP Inspector for this. ARD didn’t have anything equivalent.

So I built one.

ARD Explorer

ARD Explorer is a web UI for exploring ARD endpoints. One command, zero config:

npx ard-explorer

It opens a local web app where you can:

• Connect to any ARD registry by URL, or discover registries via .well-known/ai-catalog.json
• Search with the full §7.1 query model — text queries, filters, pagination, federation referrals
• Browse facets with bucket counts (see what categories and capabilities a registry exposes)
• List agents via GET /agents
• Validate manifests against the spec’s conformance rules
• Inspect raw request/response for every call (useful when you’re implementing a registry yourself)

It ships with a built-in mock registry so you can explore the query model even without a live endpoint. And it comes pre-configured with the reference implementations: Hugging Face Discover, GitHub Agent Finder, Cisco AI Catalog, and Ora Directory. Includes a proxy server to handle CORS, since browsers and cross-origin API calls don’t mix.

Try it

The agentic ecosystem has a cold start problem. Protocols for calling tools are maturing fast, but discovering tools is still ad-hoc. This isn’t just an MCP problem — it’s true for A2A agents, Skills, Plugins, Canvases, workflows, and every other kind of agentic resource. ARD standardizes that layer, and any artifact type with an agreed-upon media type can participate.

Building a registry? You can test your implementation against the query model. Evaluating ARD as a consumer? See what’s actually out there across GitHub, Hugging Face, Cisco, and more. Just curious? The mock registry lets you play with it without any setup.

The package is on npm as ard-explorer. The repo is on GitHub.

I write about building with AI agents. Follow me on LinkedIn for more.

We designed this in close collaboration with our Shell team. If you’re building agents that run on Windows, this is the API you need to know.

The problem it solves

Apps can show detailed info about what’s happening — but that means the user has to be staring at the app. File copies get a whole dialog with a progress chart — hey, I built this with my team back in Windows 8! — with detailed progress, speed estimates, and time remaining (OK, that last one wasn’t always accurate); great, if you’re watching it. It was apparently good enough that someone built a lunar lander game on top of it.

But everyone knows people don’t want to sit there staring at a dialog, which is why file copies also show a sweeping progress bar on the taskbar. Downloads do the same.

That taskbar progress bar is the universal “something is happening” signal. But that’s all it tells you. An agent researching a topic might spend minutes crawling sources, cross-referencing, drafting. A progress bar can’t tell you it just finished searching three databases and is now compiling a report. The user has no idea if it’s working, stuck, or waiting for input. They alt-tab. They check. They alt-tab back. Repeat.

The taskbar progress bar: useful for downloads, not enough for agents.

The AppTasks API gives apps a way to push structured task status directly into the Windows Shell — steps, results, even interactive prompts. The taskbar becomes the progress surface. No custom UI required.

The Researcher agent in Microsoft 365 Copilot showing real-time progress steps on the taskbar — completed steps get checkmarks, the current step shows a spinner.

The API surface

The namespace has three classes and one enum. That’s it.

AppTaskInfo is the task itself. Create one with AppTaskInfo.Create(title, subtitle, deepLink, iconUri, content) — the task appears on the taskbar immediately. Tasks survive app restarts; the Shell owns the lifecycle. Use FindAll() to recover them on next launch, Update() to change state and content, Remove() when you’re done. The HiddenByUser property tells you if the user dismissed it.

AppTaskContent controls what the user sees. It has factory methods for different visual representations:

• CreateSequenceOfSteps — step-by-step progress (the screenshot above). Takes an array of completed steps and the current step string.
• CreatePreviewThumbnail — a thumbnail preview of the output
• CreateTextSummaryResult — a text summary when the task completes
• CreateGeneratedAssetsResult — display generated files/assets as AppTaskResultAsset objects

You can also bolt on interactive elements: SetQuestion to ask the user something, AddButton for deep-link actions, SetTextInput for free-form input with a URI template ({userTextInput} placeholder). The Shell renders all of it.

AppTaskState is the enum: Running, Paused, Completed, Error, NeedsAttention. Straightforward.

AppTaskResultAsset represents a file or artifact the task produced.

Show me the code

Here’s a basic flow: create a task, update it as your agent progresses, mark it complete.

using Windows.UI.Shell.Tasks;

// Create the task content — a sequence of steps the agent will work through
var content = AppTaskContent.CreateSequenceOfSteps(
    new string[] { },  // no completed steps yet
    "Beginning research"  // current step
);

// Create the task — it appears on the taskbar immediately
var task = AppTaskInfo.Create(
    title: "Researching retail personalization trends",
    subtitle: "Copilot",
    deepLink: new Uri("myapp://tasks/research-123"),  // where to go when clicked
    iconUri: new Uri("ms-appx:///Assets/AgentIcon.png"),
    content: content);

As your agent progresses, update the content:

// Agent finished step 1, now on step 2
var updatedContent = AppTaskContent.CreateSequenceOfSteps(
    new[] { "Beginning research" },  // completed steps
    "Searching databases"  // current step
);
task.Update(AppTaskState.Running, updatedContent);

When the agent finishes, switch to a result view:

// Show generated assets when done
var assets = new AppTaskResultAsset[]
{
    new AppTaskResultAsset(
        "Research Report", "12 sources, 3 databases",
        new Uri("ms-appx:///Assets/DocIcon.png"),
        new Uri("myapp://reports/research-123"))
};
task.Update(AppTaskState.Completed,
    AppTaskContent.CreateGeneratedAssetsResult(assets));

If the agent needs user input mid-task:

// The content model supports interactive elements
var content = AppTaskContent.CreateSequenceOfSteps(
    new[] { "Beginning research" }, "Waiting for input");
content.SetQuestion("Should I include competitor analysis?");
content.AddButton("Yes, include it", new Uri("myapp://task/confirm"));
content.AddButton("No, skip it", new Uri("myapp://task/skip"));
content.SetTextInput("Or type specific instructions",
    "myapp://task/input?text={userTextInput}");
task.Update(AppTaskState.NeedsAttention, content);

Tasks survive app restarts — the Shell owns the lifecycle. On next launch, find and resume them:

var existingTasks = AppTaskInfo.FindAll();
foreach (var t in existingTasks)
{
    // Resume, update, or remove stale tasks
    // t.HiddenByUser tells you if the user dismissed it
}

When the task is no longer relevant:

task.Remove();

Requirements

Two things your app needs:

1. Package identity. Your app needs package identity so the Shell can associate tasks with it. This doesn’t mean you need a full MSIX package — you can use packaging with external location (sparse packaging) to add identity to your existing app without changing how you install or deploy it.

   Alternative for unpackaged agents: If your agent can’t easily get package identity (e.g. a Python script, a CLI tool), you can build a small packaged helper app whose sole job is to call the AppTasks APIs on behalf of your agent. Your agent talks to the helper via IPC or command-line args; the helper handles the Shell integration.

2. AppExtension manifest entry. Declare com.microsoft.apptaskprovider in your Package.appxmanifest:

<Extensions>
  <uap3:Extension Category="windows.appExtension">
    <uap3:AppExtension
      Name="com.microsoft.apptaskprovider"
      PublicFolder="Public"
      Id="MyApp.AppTaskProvider"
      DisplayName="AppTaskProvider for MyApp"/>
  </uap3:Extension>
</Extensions>

That’s how Windows knows your app provides this kind of status.

Why this matters for agent developers

The API is marked [Experimental] and started rolling out to Windows 11 in May 2026. It’s early. But the design pattern here is the one that will stick.

Background agents need a presence in the OS. Not a notification that fires and disappears. Not a toast that gets swiped away. A persistent, glanceable status that the user can check without context-switching.

We’ve had this pattern for decades with download managers and file transfers. Agents are long-running background work. The taskbar is where users already look for that.

The content model is flexible enough to handle the range of agent behaviors: step-by-step progress for research tasks, thumbnails for image generation, asset lists for multi-file output, and interactive elements when the agent needs human input. That last one is probably the most interesting — agents that can ask questions through the Shell UI don’t need to yank you out of whatever you’re doing just to answer “yes” or “no.”

What’s next

If you’re building agents on Windows, start with the API docs. The surface area is small enough to learn in an afternoon, and you get your agent’s status right there on the taskbar instead of making users babysit it.

The broader story — how Windows is becoming a platform where agents are native citizens of the OS — is still unfolding. AppTasks is one piece of that. More to come.

Connect with me on LinkedIn to discuss platform architecture for AI agents: linkedin.com/in/asklar

I wanted an actual answer. Not “probably some Intune stuff” but a real breakdown: who launched each script and what it does.

So I built an analysis engine into script-warden and pointed it at two weeks of captures on my corporate machine.

Classifying the noise

The new analyze command groups every captured script along two axes:

1. Source — who launched it. Management agents (Intune/MDM, ConfigMgr), scheduled tasks, Group Policy, EDR/AV, dev tools, Windows servicing.
2. Behavior — what it does. Install/uninstall, update, inventory, config change, persistence, network/download, remote execution, credential access, obfuscation.

On my machine, the biggest script launchers weren’t things I run. They were management agents and scheduled tasks I never configured. Background inventory sweeps. Compliance checks. Telemetry collectors. All silent.

None of it is malicious. But “not malicious” and “I knew about this” are not the same thing.

What are they actually doing?

The behavior breakdown is where it got interesting. The single biggest category was inventory: scripts that scan your hardware, installed software, and registry state, then report it somewhere. Others silently adjust settings. A few do network/download operations you’d never notice.

Probably fine. But “probably fine” looks different when you can see the actual script.

This one is a PowerShell script launched by ConfigMgr through WMI to check whether my VPN profile version matches what IT expects. I didn’t run it. I didn’t know it existed. It ran for 4.7 seconds and exited silently. script-warden caught it, decoded it, and showed me the full parent chain: wininit.exe all the way down to powershell.exe.

Transparency is not a security risk

If a script is safe to run on my machine, it’s safe for me to read. Enterprise tooling running hidden with no user-accessible audit trail is a UX choice, not a security requirement.

Your laptop slow at 2pm every Tuesday? Now you can find out why. That PowerShell window that flashes for a split second? You can read what it did. The base64-encoded command that ran at 3am? Decoded and saved.

Composable filters

The analysis view is a drill-down tool. Stack filters (taxonomy include/exclude, time range, full-text content search), see the live match count, then click through to matching events. Search for a URL, a registry key, or an executable name across every script that ever ran on your machine.

Taxonomies are JSON files. Edit them, drop in your own categories. script-warden auto-updates the built-ins but never touches your custom ones.

What’s next

The captures are structured data with full script content. That means you can point a model at them. I’m working on an AI analysis mode that reasons over your capture history to surface patterns, flag anomalies, and answer questions like “what ran differently this week vs. last week?” or “show me everything that touches the network after midnight.” The data is already there. It just needs a brain on top.

Try it

script-warden install       # start monitoring (one-time admin prompt)
# ... let it collect for a day or two ...
script-warden analyze       # build the analysis database
script-warden serve         # browse everything in the web viewer

The Analysis tab in the viewer uses the same engine. Click any category to filter the full audit log to matching entries.

github.com/asklar/script-warden — MIT licensed, single exe, no runtime.

Point it at your machine. You should know what’s running on it.

What would you find on yours? Run script-warden install and find out. If you do, I’d love to hear what surprises you — find me on LinkedIn or open an issue.

I tried to catch it. Task Manager wasn’t fast enough. Event logs told me that something ran, sometimes, but never handed me the actual script. On a managed Windows machine, that’s the norm: logon scripts, config-management agents, scheduled tasks, and remote-management tooling shell out to PowerShell and cmd dozens of times a day, usually with no window, usually gone in milliseconds, occasionally as a base64 blob you couldn’t read even if you caught it.

None of it is sinister. Most of it is patch management and compliance checks doing exactly what they should. But “probably fine” is a strange thing to accept about code you can’t see. I wanted to read it.

So I built script-warden: a single Windows executable that records every script launch, keeps a copy of the actual script, and lets you browse the whole trail in a local web viewer. It’s open source (MIT), and this post is about the itch and the one genuinely clever trick that makes it work.

The Observability Gap

The problem was never that scripts run. It’s that they run and disappear.

The requirements more or less wrote themselves:

• Record every launch of the usual interpreters: powershell.exe, pwsh.exe, cmd.exe, cscript.exe, wscript.exe.
• Keep the actual script: copy referenced .ps1 / .bat / .cmd / .vbs / .js files, save inline -Command / cmd /c text, and decode -EncodedCommand payloads into something readable. Everything content-addressed and de-duplicated by SHA-256.
• Note whether each ran Visible (had a console) or Hidden (no window / background), because the silent ones are exactly the ones you want to see.
• Capture the full parent chain, so you can trace a launch from the script up to the scheduled-task host or management agent that started it. It reads SYSTEM-level data too, so scripts that ran with full privileges show up.
• Never, ever break the thing it’s watching. If the audit logic throws, PowerShell must still run.

That last point turned out to shape the whole design.

The One Clever Trick

How do you sit in front of every PowerShell launch on a machine with no kernel driver, no OS patching, and no fragile global hook?

Windows has a decades-old debugging feature called Image File Execution Options (IFEO). Register a Debugger value for an executable name, and from then on, whenever Windows is asked to launch powershell.exe, it instead launches your program with the original PowerShell command line handed to you as arguments. It’s the same supported mechanism used to attach a debugger at process start. script-warden registers itself as that debugger.

That’s the hook, and it creates an obvious problem. If my tool’s job is to relaunch the real PowerShell, and every launch of PowerShell is intercepted by my tool… I’ve built an infinite loop that takes down every shell on the machine. Blast radius: the entire OS.

The escape hatch is a lovely little detail in the loader. When you start a process with the DEBUG_ONLY_THIS_PROCESS flag, Windows skips the IFEO redirection for that launch. So script-warden relaunches the real interpreter as if it were debugging it, immediately detaches, and lets it run with completely normal semantics: same stdio, working directory, environment, exit code, and the original command line forwarded verbatim, quoting and all. That last part matters more than it sounds: a tool whose promise is “I recorded exactly what ran” can’t paraphrase. To the user and to every script, nothing happened. There’s just now a durable, faithful record of it.

Making the Data Worth Having

Capturing is only half of it. A folder of a thousand JSON files isn’t insight. So script-warden serve opens a local web viewer (React + Fluent UI, embedded straight into the executable, so it’s still a single file). You get a fast, paginated, searchable trail filtered by interpreter, origin, parent process, and visibility; the full launch chain for any event; and the captured script itself to view or download, including the decoded version of that base64 blob.

Click any entry to see the full detail: command line, visibility, parent chain, working directory, and the captured scripts themselves.

There’s a deliberate principle running through it: talk about what the user cares about, not the plumbing. You don’t filter by “window-handle state”; you filter by Visible vs Hidden. The interesting engineering lives in the code; the product speaks in your questions.

Why Native AOT

This thing runs on every single interpreter launch on the machine. If it added a few hundred milliseconds of CLR startup each time, I’d uninstall my own tool within a day. .NET Native AOT (ahead-of-time compilation) compiles the whole program to a single native executable: around 4 MB, starts in a blink, no .NET runtime to install or ship. The constraint enforced discipline, too: all P/Invoke uses LibraryImport source generators (compile-time marshalling, no runtime reflection), all JSON uses System.Text.Json source generators (same idea for serialization), and the whole thing publishes AOT-clean. Constraints like these tend to make software better, not worse.

Try It

script-warden is MIT licensed and lives here: github.com/asklar/script-warden.

It’s a single self-contained .exe. Run script-warden diagnose first. It self-tests your data locations, current monitoring state, and simulates a capture so you can see exactly what it does before you commit. Then install starts monitoring (machine-wide, so it prompts for admin once), serve opens the viewer, and uninstall cleanly removes only what it added.

Point it at your own machine and go read what’s been running. You might be surprised.

I write about building with AI agents and the deep Windows internals that make them possible: the stuff that works and the stuff that breaks. Follow me on LinkedIn for more.

But the interesting part isn’t the map. It’s how I use it.

What makes it a canvas

A “canvas” in Copilot is a UI that both you and the agent can see and manipulate at the same time. Think of it like a shared screen — except one of the people driving is an AI. The canvas renders in the Copilot desktop app’s side panel, but since it’s just a local web server under the hood, you can also open it in any browser. I did all my development from Copilot CLI and just pointed Edge at localhost:60698.

My extension shows a Leaflet + OpenStreetMap map with a pin for every match. Green for finished results, orange for upcoming fixtures. Click a pin and you get team badges, scores or kickoff times, venue, round, and a link out to highlights on YouTube. You can filter by status or team.

I can click around the map myself. Or I can tell the agent “focus on Mexico’s next match” and it pans the map for me. Same UI, two ways to drive it.

The Architecture

The extension runs a Node HTTP + SSE server that serves both the map UI and a /api/matches endpoint. The agent has three canvas actions it can invoke:

• refresh_matches — pull latest data and update all markers
• focus_match — pan/zoom to a specific match
• filter_matches — show only matches matching criteria (team, status, round)

These push live updates over Server-Sent Events. The canvas in GitHub Copilot’s desktop side panel receives them and re-renders instantly.

Plain CLI tools (worldcup_list_matches, worldcup_match_detail) also exist so the agent can answer match questions even with the canvas closed. The canvas is the rich interface; the CLI is the fallback.

Data Wrangling

Match data comes from TheSportsDB (league 4429, season 2026). Getting all 72 group-stage matches required merging three separate endpoints — events by round, next scheduled, and past results — then deduping by match ID. No single endpoint returns everything.

TheSportsDB events have no coordinates. I built a static lookup table mapping 16 host stadiums to lat/lng, with name aliases to handle variations (“Reliant Stadium” → NRG Stadium, “BC Place Stadium” → BC Place).

How I actually built it

Here’s my entire contribution to the initial build. I opened Copilot CLI and typed:

“I’m a big soccer fan and it’s currently the FIFA world cup, I’d like to build a copilot canvas extension that shows me the matches’ results and upcoming games, in a map control”

That’s it. One sentence. The agent spent the next 107 minutes figuring out the rest — spelunking the SDK’s .d.ts files to discover the canvas API, researching TheSportsDB endpoints, writing the Node server, wiring up SSE, building the Leaflet map, and handling all the coordinate lookups. I rejected one tool call (“no codebase yet, you’ll start from scratch”) and otherwise just watched.

After that, I spent maybe 20 more minutes iterating: fixing the two bugs I describe below, adding the team filter, tweaking the popup styling. But the core architecture — the SSE flow, the canvas actions, the data merging — all came from that one prompt.

What the agent figured out

Watching the agent work through problems in real time was half the fun:

“Only results, no upcoming matches.” The agent hit a wall: TheSportsDB’s past-events endpoint only returns finished matches, and the next-events endpoint only returns scheduled ones. Neither returns both. Its fix: merge all three feeds, dedupe on ID. I just said “there should be upcoming games too” and it root-caused the data source on its own.

“Canvas server doesn’t seem to be running.” Each time the extension reloaded during development, it bound a new ephemeral port — orphaning any canvas tab still pointing at the old one. The agent figured out the fix: bind a stable port (60698) with EADDRINUSE fallback so the canvas URL stays constant across reloads.

Discovering the canvas API itself. Canvas extensions aren’t heavily documented yet. The agent found createCanvas and joinSession by spelunking the SDK’s bundled .d.ts type definition files. The types were the map.

Try It

The extension is open source on GitHub. Install by cloning into your Copilot extensions directory:

# User scope (just you)
git clone https://github.com/asklar/worldcup-map-canvas-2026 ~/.copilot/extensions/worldcup-map

# Team scope (shared repo)
git clone https://github.com/asklar/worldcup-map-canvas-2026 .github/extensions/worldcup-map

It works in the GitHub Copilot desktop app or any browser pointed at the local server.

The World Cup runs through July 19. The map updates live. And if I want to know when Uruguay plays next — I just ask.

I write about building with AI agents, the stuff that actually works and the stuff that breaks. Follow me on LinkedIn for more.

That’s the fundamental gap Microsoft Execution Containers (MXC) fills — and it’s not theoretical for me. My team and I have been integrating MXC into OpenClaw so agents can run tools locally without inheriting a full user session.

To make the idea concrete, here’s the mental model I use:

Announced at Build 2026, MXC is a policy-driven execution layer that lets developers declare what an agent can access — files, network, system resources — and has the OS enforce those boundaries at runtime. It’s open source on GitHub and works across Windows, Linux, and macOS.

The Problem: Trust Without Boundaries

Right now, when you run a coding agent, it inherits your session. Every file, every credential, every network path.

If you can access it, so can the agent.

That’s super powerful.

And that’s where it gets scary: the agent can mess up or overstep, at machine speed.

The agent might be well-behaved, but the model generating its actions is non-deterministic. One hallucinated command, one prompt injection, and your agent is doing things you never intended with access you never meant to grant.

Traditional containment often collapses into a monolithic boundary: either you grant broad access so the agent can work, or you lock it down so hard it becomes useless. Agents need something in between.

What MXC Actually Does

MXC introduces a containment spectrum — not a single sandbox, but composable isolation that scales with risk:

• Process isolation — restrict what a single agent process can touch
• Filesystem boundaries — declare which paths are readable, writable, or invisible
• Network constraints — control what an agent can reach over the wire
• Composable policies — layer isolation primitives based on workload risk, not one-size-fits-all rules

The key insight is that a coding agent and an enterprise data-processing agent don’t need the same guardrails, but they do need one coherent trust model.

More specifically: you want to be able to apply containment per agent (or per agent instance / task), not just “per framework.” MXC provides the abstraction layer so developers define intent (“this agent reads project files and nothing else”) and the OS handles enforcement.

Why This Matters for Agent Builders

If you’re building agents today, you’re probably doing one of three things for security:

1. Nothing — trusting the model not to do bad things (most common, most dangerous)
2. Containers (often Docker/VM-shaped) — workable, but heavyweight for the inner loop and frequently ends up feeling like a Linux-first story bolted onto Windows
3. Custom sandboxing — reinventing the wheel per framework

MXC replaces all three with a platform primitive. You declare a policy, the OS enforces it. Your agent runs contained without you managing cgroups, namespaces, or AppContainer details.

The Windows security blog post walks through the broader platform story around agent containment and policy-based controls.

The Composable Part Is the Breakthrough

Plenty of systems can sandbox a process. What makes MXC interesting is the composability. You can start with lightweight process isolation during development, then layer on filesystem restrictions for staging, then add network constraints for production — all using the same policy model. The containment adapts to the context without requiring architectural changes.

This is the pattern I keep seeing across successful platform work: don’t force developers to choose between security and capability. Give them a spectrum they can dial based on risk tolerance.

What’s Available Now

MXC is in early preview. The SDK is on GitHub and covers process isolation, filesystem boundaries, and network constraints across Windows, Linux, and macOS.

It’s also already landing in real developer workflows:

• GitHub Copilot local sandboxes are in public preview and are built on Microsoft MXC technology for a consistent isolation experience across macOS, Linux, and Windows. See: Cloud and local sandboxes for GitHub Copilot now in public preview (use /sandbox enable to enable sandboxing for a session). In the current preview, this focuses on isolating shell command execution initiated by Copilot; MCP servers / language servers are separately controlled surfaces from the shell tool sandboxing.

  On Windows, MXC’s default backend targets Windows 11 24H2+ (per the MXC repo), and some backends are Insider Preview-gated.

  Some capabilities are gated behind Copilot CLI’s experimental mode. You can enable it either at launch (copilot --experimental) or inside a running session (/experimental). See Copilot CLI docs: https://github.com/github/copilot-cli#experimental-mode

  I’ve also been working in close partnership with the GitHub Copilot CLI team on the practicalities of local sandboxing + tool execution in real developer workflows.

• OpenClaw on Windows was announced at Build as running natively on Windows leveraging MXC — the gateway and node processes run contained so your system stays secure out of the box. See: Build 2026 Windows platform post and Windows platform security for AI agents.

If you watched the keynote, this is the kind of capability being positioned as “agent-grade” platform security: not just better prompts, but OS-enforced containment.

The Bigger Picture

Agent containment is the infrastructure work that determines whether enterprises actually deploy local agents or keep everything locked down in cloud sandboxes. MXC makes the local path viable by giving IT teams the controls they need and giving developers the flexibility they want.

Agents are coming. The question was never whether they’d be powerful — it was whether we could trust them on real systems with real data. MXC is how Windows answers that question.

Try it + help shape it

If you’re building agents and you care about running them locally with real guardrails, go kick the tires:

• MXC repo + SDK

Early previews get better fast when real builders bring real edge cases.

I write about building with AI agents, the stuff that actually works and the stuff that breaks. Follow me on LinkedIn for more.

The community response was predictable: “be more careful what you install.”

But this isn’t new. Earlier this month, a compromised VS Code extension was live for 18 minutes. That was enough. The payload harvested credentials from everywhere it could reach — npm tokens, AWS keys, SSH keys, vault tokens, GitHub PATs. One employee had it installed. Thousands of internal repos were accessed. Signing keys had to be rotated. Every Enterprise Server customer had to take action.

18 minutes. One extension. One machine.

The extension wasn’t sketchy. It was well-known, widely-used, actively-maintained. The compromise came through a chain of poisoned dependencies. The malicious payload didn’t even need anything exotic — it just called tools already on the machine to grab credentials.

And it’s not just extensions. Earlier this year, Notepad++ was hijacked by what security researchers assessed as a Chinese state-sponsored group — not through a code vulnerability, but by compromising the hosting provider and selectively redirecting update traffic. The software was fine. The distribution was poisoned.

Mitigations exist, but they don’t solve this

Yes, there are org-level controls. You can disable the VS Code marketplace entirely. You can restrict extensions to trusted publishers. You can lock down package registries.

But “trusted publisher” wouldn’t have helped here — the compromised extension was from a trusted publisher. The Notepad++ compromise bypassed the publisher entirely. You can lock everything down to be secure and also completely useless. But if you want your developers to be productive, a balance has to be struck — and that’s where the real nuance lives. How much do you allow to run? Which tools get access to what? Who decides?

The advice we keep giving after these incidents — vet your dependencies, check the maintainer, audit your supply chain — is correct. It’s also completely insufficient at scale.

Because the actual problem isn’t which tools you install. It’s what those tools can do once they’re running.

You might assume VS Code extensions run sandboxed. They don’t. Extensions run in a separate extension host process, but according to VS Code’s own docs, that process has the same permissions as VS Code itself — it can read and write files, make network requests, and run external processes. Compare that to browser extensions, which run in a sandboxed environment with a declared permission model — they can’t just read arbitrary files off your disk. The browser figured this out years ago. Developer tooling hasn’t caught up.

An npm postinstall script runs with the same permissions as you. An MCP server runs inside your agent’s process with whatever the agent can touch.

There’s no boundary between “I added a productivity tool” and “that tool can read every secret on my machine.”

The right question

The question I keep coming back to: why is full trust the default?

Why doesn’t the platform enforce what a tool can actually reach — which files, which network endpoints, which credentials — regardless of whether you trust the maintainer?

Some ecosystems are starting to get this right. Deno ships with --allow-net, --allow-read, --allow-env — you have to explicitly grant each capability. Mobile operating systems figured this out a decade ago: apps declare permissions, the OS enforces them, and you can revoke access at any time. Windows has had this with UWP and AppContainer — sandboxing, declared capabilities, brokered access to resources. The primitives exist. They’re just not being applied to developer tooling yet.

Developer tooling is still stuck in the 2005 model where everything runs with your full permissions and we just hope nobody’s malicious.

What would “boundaries as infrastructure” look like?

A few things that would have changed the outcome here:

Filesystem isolation. The extension doesn’t need access to ~/.vault-token or ~/.npmrc or ~/.ssh/. Why can it read them? Restrict tools to the workspace they’re operating on, plus explicitly declared paths.

Network policy. A code linting extension has no reason to make outbound HTTP requests to arbitrary endpoints. A language server doesn’t need to phone home. Enforce a default-deny network policy and make tools declare what they need.

Credential isolation. Your GitHub PAT, your AWS keys, your SSH keys — these should not be ambient. Tools should request credential access through a mediated API, not just read files off disk.

Per-invocation sandboxing. Not “this tool is sandboxed” as a binary yes/no, but different sandbox shapes for different tools based on what they actually need. A filesystem MCP server gets filesystem access to specific paths. A GitHub MCP server gets network access to api.github.com. A linter gets read access to the workspace and nothing else.

None of this is novel. It’s how mobile platforms have worked for over a decade. It’s how Deno works today. It’s how containers work. We just haven’t applied it to developer workstations yet, because “developers need full access” has been the unquestioned assumption.

“Be careful” is individual advice. Boundaries are infrastructure.

Individual judgment doesn’t scale. You can’t vet every transitive dependency. You can’t audit every extension update. You can’t “be more careful” when a trusted tool gets compromised three hops deep in the dependency chain and the malicious version is live for 18 minutes.

What scales is enforcing boundaries at the platform level — so that even when a tool is compromised, the blast radius is contained to what that tool was supposed to access in the first place, and auditing can happen for forensic purposes.

We have the primitives. Sandboxing, capability-based permissions, network policy enforcement — this isn’t speculative technology. It’s just not being applied where developers live.

That’s the gap. And until we close it, “be careful what you install” will keep being our only answer, and it will keep being insufficient.

I write about AI agents, developer tooling, and platform security. If this resonated, connect with me on LinkedIn — I post about these topics regularly.

The throughput is real. But it also broke in ways I didn’t expect.

This post is about those breaks, and the rules I now follow to prevent them.

The pitch

Agent fleets let you dispatch work and walk away. You describe what you want, a Copilot session spins up, and starts working on your repo. You can run multiple agents in parallel on different tasks. They all operate on the same directory and files. In theory, this multiplies your throughput.

In practice, it does — until they step on each other.

The contention problem

Fleet agents don’t talk to each other. They don’t know the others exist. When two agents modify the same files, you get collisions: one agent finishes, commits, and moves on. The other agent tries to complete, realizes its working state is gone, resets the branch, and tries to reapply its changes — discarding the first agent’s work because it looks “unrelated.” Sometimes both agents end up in this loop. Nobody wins.

I spent hours building out features across multiple agents. Things were looking great. Then I noticed some features had stopped working. When I asked the agent about it, it casually told me that another background agent had “basically rewritten the repo” — and suggested I wait for the background agent to finish so it could try to reconcile the conflicting changes. There’s no async communication channel between the main session and fleet agents. You can’t steer them, warn them, or update their instructions mid-flight. You just wait.

Contrast this with other agent frameworks — some, like OpenClaw, let the orchestrating agent steer background agents in real time: send new constraints, redirect work, or kill a task that’s gone off track. That’s a fundamentally different model. Copilot fleets today are fire-and-forget.

No warning. No conflict detection. No merge. Changes just get lost.

Temporal contention

There’s a subtler version of this that’s harder to avoid:

You have an idea, dispatch an agent. Two minutes later you have a related idea. The first agent is still running — there’s no way to update it. And there’s no easy way for the orchestrator to know a priori whether the new task will conflict with the running one. So it dispatches. Contention.

The only mechanism today is killing the first agent and starting over. There’s no “hey, also do this” channel.

You might think planning helps. And it does — you can spend more time upfront specifying exactly what each agent should do before dispatching. Copilot’s plan mode is great for this. But humans keep thinking after they hit submit. That’s just how brains work. Plan mode reduces contention, it doesn’t eliminate it.

The formula

I think about contention as:

If you have ideas faster than agents can finish, you’ll have overlapping agents. Speed helps, but even a fast agent doesn’t eliminate the need for fleets. Fleets let you decompose a big problem into parallel tracks. That’s real, not just a speed workaround.

To be clear: Copilot is excellent, and fleets are a genuinely powerful feature. I’m confident they’ll get smarter about coordination over time. This is just my experience in March 2026 — a snapshot of where things are today, not a verdict on where they’re going. The gaps I’m describing are solvable, and GitHub is iterating fast — that team is on fire, honestly one of the most productive teams I’ve seen.

Three rules I follow now

After losing work a few times, I settled on three rules that have held up:

1. TDD is non-negotiable

Write tests before code. Every feature, every diagnostic, every behavior gets a test first. Not because TDD is a religion. Tests are how you detect when one agent broke what another agent built.

When an agent opens a PR and the tests pass, you have confidence. When they fail, you know exactly what regressed. Without tests, you’re flying blind — you won’t even notice the damage until much later.

With 3,000+ tests, I catch conflicts almost immediately. That number isn’t an accident. It’s the direct result of treating tests as the ground truth for the project.

2. Every agent gets a worktree and a branch

No agent works on main. Ever. Each background agent gets its own git worktree on its own branch. This gives you isolation by default. Agents can’t silently overwrite each other’s work because they’re working in different directories on different branches.

git worktree add /tmp/agent-task-123 -b feature/add-diagnostics

This is cheap. Worktrees are lightweight. And it means you always have a clean merge point where you can see exactly what changed.

There’s a file-level version of this trick too. In C#, I started having background agents write new code into separate files using partial class instead of editing the main class file. Agent A works in Parser.cs, Agent B writes to Parser.Diagnostics.cs — same class, different files, zero merge conflicts. The main agent can consolidate later if the split doesn’t make sense, but often it does and you end up with better-organized code anyway.

Same principle as worktrees — don’t touch the same artifact — just applied at a different granularity.

3. One merge authority

The main agent (or me) handles all merges. Background agents propose changes via PRs. They don’t merge anything themselves. This creates a single coordination point where conflicts are visible and resolvable.

If two agents touched the same area, I see it at merge time. Not after the damage is done.

Enforcing the rules

I store these rules in GitHub Copilot’s native repo memory. You just tell Copilot “remember this” and it does — you’ll see it invoke a store_memory tool call, a built-in tool for persisting conventions across sessions. When an agent spins up, it loads these automatically. The memory tells it: work in a worktree, write tests first, don’t merge.

Not foolproof. Agents can still drift. But the failure mode goes from “silently lost a day of work” to “caught it in a PR review.”

What I wish existed

The rules above work if you’re disciplined. But there are gaps that discipline can’t cover:

Agent-to-agent communication. If Agent A is modifying the parser and Agent B is about to touch the same area, B should know. Even a simple “these files are locked” mechanism would help.

Worktrees as a default. Today you have to explicitly set this up. It should be the default behavior for any background agent — spin up in an isolated worktree, propose changes via PR, never touch the main branch directly.

Tests as ground truth. The ecosystem should treat passing tests as the primary integration signal, not just “did the agent say it’s done.” If tests fail after an agent’s changes, that’s a hard stop, not a suggestion.

You’re not the only one hitting this

Niko Heikkilä tried Claude Code’s /batch for a framework migration — parallel worktrees, PRs per task, e2e tests as gates. He got merge conflicts between parallel PRs, doom loops trying to fix “done” work, and ultimately called the project off. Tests were there but coordination wasn’t.

Tamir Dresher wrote about the same problem from the state management angle — squad memory files polluting code PRs when multiple agents share state. Different angle, same underlying issue.

GitHub clearly sees it too — Brady Gaster’s team just shipped Squad, a coordinated multi-agent system that drops a specialized team (lead, frontend dev, backend dev, tester) directly into your repo. Squad solves a different layer than what I’m describing here: it handles who does what — role specialization, internal review loops, shared project memory. My rules handle how agents don’t step on each other — worktrees, file isolation, merge authority. They’re complementary. I haven’t tried Squad yet but it’s next on my list.

So what now

Agent fleets work. I built a real project with them and the throughput is genuinely impressive. But they work like concurrent programming: without synchronization primitives, you get race conditions.

Tests catch the damage. Worktrees prevent the collision. One merge authority gives you a place to reconcile.

Until the tooling catches up, that’s what I’ve got. It’s working.

I’ve distilled these into a SKILL.md you can drop into your repo. Any agent that reads it will follow the rules automatically.

I write about building with AI agents, the stuff that actually works and the stuff that breaks. Follow me on LinkedIn for more.

The spec says it plainly

The MCP specification is explicit: annotations are not guaranteed to faithfully describe tool behavior. Clients must treat them as untrusted unless they come from a trusted server. During the original proposal review, MCP co-creator Justin Spahr-Summers asked the question that still hangs over every annotation proposal:

I think the information itself, if it could be trusted, would be very useful, but I wonder how a client makes use of this flag knowing that it’s not trustable.

Basil Hosmer pushed even harder:

Clients should ignore annotations from untrusted servers.

These are the people who built the protocol. They know annotations can’t be trusted, and they shipped them anyway as a UX convenience. That was a reasonable choice. The problem starts when people treat these hints as a security boundary.

Five SEPs, same problem

Right now there are five open Specification Enhancement Proposals trying to add more annotations: trust levels, sensitivity markers, secret handling hints, unsafe output flags, governance metadata. Some come from GitHub and OpenAI, based on real gaps they hit running MCP in production.

I get the impulse. You’re building an agent platform, you want to know what a tool does before you run it, and annotations feel like the obvious place to put that information. But adding more metadata to an untrusted channel doesn’t make the channel trusted. A tool that says secretHint: true is making a promise. Who verifies that promise? The tool itself. That’s circular.

More annotations give you a richer vocabulary for describing risk. That’s useful for building better confirmation dialogs and audit logs. But it’s not enforcement. It’s labeling.

The lethal trifecta needs a runtime answer

Simon Willison named the lethal trifecta: an agent with access to private data, exposure to untrusted content, and the ability to exfiltrate. When all three are present, you’re one prompt injection away from data theft. Researchers have demonstrated this with a malicious Google Calendar event, an MCP calendar server, and a local code execution tool.

The MCP blog post acknowledges this. But then it frames annotations as part of the solution, helping clients reason about which tools contribute to which legs of the trifecta. And sure, if openWorldHint is set correctly, a client could theoretically refuse to combine that tool with one that reads private data.

Here’s the problem: openWorldHint is self-reported. A malicious server won’t set it. A lazy server author won’t think about it. A compromised server might have set it correctly last week but not today. You can’t build a security model on “the tool describes itself honestly.” That’s asking a burglar to wear a name tag.

The lethal trifecta has to be broken at the runtime level: the container, the sandbox, the execution environment. If a tool can’t reach the network, it doesn’t matter what openWorldHint says. If a tool can only read files in /tmp/workspace, it can’t exfiltrate your emails regardless of how it describes itself. The enforcement has to be about what the tool can do, not what it says it does.

Annotations are UX, not policy

I’m not saying annotations are useless. They’re good for UX. If a tool says it’s destructive, showing a confirmation dialog before running it is smart. If a tool says it’s read-only, maybe you skip the confirmation. That’s a better user experience.

But UX is not policy. A confirmation dialog doesn’t prevent exfiltration. It just makes the user click “OK” first. In an agentic workflow where the LLM makes tool calls autonomously, there might not even be a user in the loop to click anything.

The distinction matters because I see people conflating the two. “We have tool annotations, so we have a security story.” No. You have a hint system. Your security story is whatever runs underneath: process isolation, network policies, filesystem restrictions, capability-based permissions. Without those, annotations are a sign on the door that says “please don’t steal anything.”

What enforcement actually looks like

Real enforcement means the runtime environment constrains what a tool can do, independent of what the tool claims about itself:

• Network isolation. A tool that processes documents doesn’t need outbound HTTP. Don’t give it outbound HTTP.
• Filesystem scoping. Mount only what the tool needs. If it’s a code formatter, it gets the source directory. Not your home folder.
• Capability dropping. No raw socket access. No process spawning unless explicitly needed.
• Ephemeral environments. Spin up a container for the tool invocation. Tear it down after. State doesn’t persist unless you explicitly allow it.

None of this requires the tool’s cooperation. None of it depends on annotations being accurate. The tool doesn’t get to vote on its own permissions.

This is the direction the industry is converging on. The protocol layer is the wrong place to solve trust. The runtime layer is where you actually have leverage.

The meta-question

Every time a new annotation SEP shows up, I ask the same question: who enforces this?

If the answer is “the client reads the annotation and decides what to do,” that’s UX. If the answer is “the runtime environment constrains the tool regardless of annotations,” that’s security. The MCP community is pouring energy into the first category while the second category still has no standardized answer.

I’d love to see that energy redirected. Give me a standard way to declare what capabilities a tool needs. Give me a runtime spec that hosts can implement. Give me a container profile format that tool authors ship alongside their servers. That would be worth five SEPs.

Annotations tell you what a tool says about itself. Sandboxes tell you what a tool can actually do. I know which one I’m betting on.

I write about building with AI agents, the stuff that actually works and the stuff that breaks. Follow me on LinkedIn for more.

• Instructions
• Prompt files
• Custom agents / modes
• Skills
• Plugins
• MCP servers
• Hooks

They’re not redundant. They exist because they solve different layers of control.

This post explains what each one is, what it’s good for, and a decision guide for “which should I use?” — written so you can hand it to someone with zero context.

The core axes: scope, trigger, enforcement (and distribution)

When you’re deciding between these primitives, ask four questions:

1) Scope — where does it apply?

• one repo
• one user
• one session
• an entire org

2) Trigger — when does it run?

• always-on
• explicitly invoked
• automatically discovered
• event-driven

3) Enforcement — how deterministic is it?

• guidance (model can ignore)
• packaging (reusable but still model-driven)
• gates (hard allow/deny)

4) Distribution — how does it propagate?

• Personal install (user-level): installed once, used across repos you touch
• Repo install (checked in): travels with the codebase; everyone gets it on clone

If you pick by these axes, “which thing do I build?” becomes straightforward.

A simple map (how these compose)

Think of it like a stack:

• Instructions/prompt files shape behavior.
• Custom agents define “who is the agent right now” and what tools it’s allowed to use.
• Skills package repeatable workflows + assets.
• MCP is an optional connector layer that exposes tools/resources to the agent (often external systems, sometimes local tools too).
• Hooks enforce non-negotiables.

1) Instructions (always-on defaults)

Docs (GitHub Copilot / CLI): Response customization

What it is: a set of rules that are automatically included in context.

Important nuance: instructions typically stack from multiple scopes:

• Repo-wide instructions (checked in; team defaults)
• Path-specific instructions (only apply to certain files/globs; keeps rules local)
• Personal instructions (your preferences, not the team’s)

If your agent feels “mysteriously inconsistent”, a good debugging move is to inspect which instruction files were loaded for the session (many hosts expose a /instructions-style command).

Use it when: you want the agent to behave consistently without anyone remembering to invoke anything.

Great for:

• coding conventions, naming, lint expectations
• security defaults (least privilege, no secrets in code)
• process defaults (“always show diff before asking me to merge”)

Don’t use it when:

• you need a named workflow people can invoke
• you need deterministic enforcement (use hooks)

Rule of thumb: instructions should be short and stable. If they change weekly, they’re a prompt or a skill.

2) Prompt files (named plays)

Docs (GitHub Copilot / CLI): Prompt files (VS Code)

What it is: an explicitly invoked prompt template (often a slash command).

Use it when: you keep typing the same thing over and over.

Great for:

• “write release notes from these commits”
• “summarize this PR as a changelog entry”
• “generate an RFC from these bullets”

Don’t use it when:

• you need bundled files/scripts/templates (use a skill)
• you want always-on standards (instructions)

Rule of thumb: prompt files are the “macros” of agent work.

3) Custom agents / modes (role + tool boundary)

Docs (GitHub Copilot / CLI): Custom agents

What it is: a pre-defined agent configuration you select for a session: persona + allowed tools + guardrails.

This is the sharpest tool for preventing expensive mistakes.

Use it when: you need different behavior/tooling for different phases:

• planning vs implementation
• review vs edit
• security/audit vs coding

Great for:

• a Planner that can read but not edit
• a Reviewer that can run checks but not push changes
• an Implementer that can edit files and run tests

Don’t use it when:

• you just need a one-off task template (prompt)
• you need a reusable multi-step workflow with assets (skill)

Rule of thumb: modes are “roles on a team”. If you’d separate the work between two humans, split it into two modes.

4) Skills (packaged workflows)

Docs (GitHub Copilot / CLI): Agent skills

What it is: a folder-packaged runbook: the instructions plus whatever assets the workflow needs (templates, scripts, reference files).

Skills are “recipes”: multi-step workflows that get pulled in when relevant, rather than living as always-on background context.

Use it when: the workflow is multi-step and you want it to be repeatable.

Great for:

• incident triage playbooks
• postmortem generation (with templates)
• project bootstrap scaffolding
• “evaluation loops” (feedback → analysis → proposed change)

Don’t use it when:

• it’s just a standard rule (instructions)
• it’s just a one-shot template (prompt)
• you’re actually trying to connect to a live system (MCP)

Rule of thumb: if you’re attaching files, scripts, templates, or examples, you’re in skill territory.

5) Plugins (distribution package for a host)

Docs: (varies by host; “plugin” is not a single universal standard in Copilot docs)

What it is: an installable unit for a specific host ecosystem (Copilot, VS Code, internal CLI, etc.).

A plugin can contain many things: skills, prompt files, agents, scripts, metadata.

Use it when: adoption and lifecycle matter:

• install/update/uninstall
• discovery (catalog/marketplace)
• compatibility/versioning

Great for:

• packaging capabilities so teams can install them a la carte
• sharing a consistent bundle without copying files repo-to-repo

Don’t use it when:

• you’re still exploring and changing the workflow daily (skills/prompts iterate faster)
• you need cross-host portability (plugins are usually host-coupled)

Rule of thumb: skills are content. plugins are shipping.

6) MCP servers (tools/resources connector layer)

Docs (GitHub Copilot / CLI): MCP

What it is: a standard protocol for exposing tools and resources to an agent.

Often, those tools/resources front a live external system (GitHub, tickets, cloud, databases). But MCP can also be used to wrap local capabilities (for example, a locally running service that brokers auth, or a tool that’s easier to expose over a protocol).

Use it when: the agent needs capabilities or data that aren’t already in its local context, especially when you want a stable interface:

• GitHub/AzDO operations
• ticketing systems
• cloud control planes
• databases / internal services

Great for:

• “create an issue / comment on a PR / fetch build logs”
• “query a service dashboard and summarize anomalies”

Don’t use it when:

• all you need is static guidance or a local workflow
• you can accomplish the same thing with a CLI without running a server

Rule of thumb: MCP is about interfaces and connectivity. If you’re not exposing tools/resources across a boundary (process, machine, auth domain), MCP is usually overkill.

7) Hooks (deterministic policy gates)

Docs: Hooks

What it is: event-driven checks that can allow/deny an operation at execution time.

Use it when: “the model should always…” is not good enough.

Great for:

• blocking dangerous commands
• enforcing compliance checks
• audit logging

Don’t use it when:

• the rule is subjective or fuzzy

Rule of thumb: if violating the rule is catastrophic, make it a hook.

Distribution cheat sheet (personal vs repo)

Different tools name this differently, but the pattern is consistent:

• Personal: great for rapid iteration and power users; teammates won’t see it unless you document it.
• Repo: great for onboarding and consistency; versioned and reviewed like code.

Here’s where these artifacts most commonly live:

• Instructions: repo (and sometimes org-managed)
• Prompt files: repo
• Custom agents / modes: repo (sometimes personal)
• Skills: both (personal skill library or repo-scoped skills)
• Plugins: personal install via marketplace/registry (the plugin itself may deliver repo-scoped content)
• MCP servers: both (workspace config vs user config)
• Hooks: repo/org (because enforcement should be shared)

Chooser matrix (pick the smallest thing that works)

One nuance: plugins are orthogonal. If you need distribution + install/update + catalog UX, wrap whatever you built (prompts/skills/agents) inside a plugin.

What “good” looks like (a minimal stack)

Most teams don’t need all of this.

A sane starting point: 1) Instructions for baseline rules 2) 3–5 prompt files for your most common plays 3) Two modes (Planner + Implementer) if you’re doing real code changes 4) 1–2 skills for the workflows you want repeatable 5) MCP only where you need tool/resource connectors 6) Hooks only for non-negotiables

The goal is not to build an “AI config cathedral.”

The goal is to pick the smallest building block that makes your agent work more reliable, more reusable, or more adoptable.

Final note: it’s all just text (and that’s a feature)

At the end of the day, most of these “building blocks” are files containing text: markdown instructions, prompt templates, and lightweight configuration.

What makes them powerful isn’t the file format. It’s the conventions:

• common names (instructions, prompt files, custom agents, skills)
• common locations (.github/..., ~/.copilot/...)
• common semantics (what gets loaded automatically vs manually)

Those conventions are converging across tools.

A concrete example: Agent Skills is an open, lightweight format centered around a folder with a SKILL.md file (YAML frontmatter + markdown instructions), designed for progressive disclosure (discover → activate → execute).

• What are skills?
• Agent Skills specification

That’s the real story: we’re starting to get a shared vocabulary for packaging agent behavior.

If this was useful, connect with me on LinkedIn.