Ken Muse

If you’ve built custom Copilot agents, skills, and MCP servers, you may know some of the benefits of using plugins to distribute this content. You may also know how quickly the setup starts to become complicated across AI harnesses. The new Agent Plugins specification gives you a portable core for shared skills and servers while keeping client-specific features in a cleaner, separate namespace. In this post, I walk through the new layout and show how to keep your reusable AI tooling portable without giving up the features that make each client worth using.

You carefully built a Model Context Protocol (MCP) tool that returns precise data. It reports 400 milliseconds, but your AI assistant says 321. Where did the value change, and how can you prevent it? Even perfect tool output can lose fidelity when a model interprets and repeats it. Today, I’ll show you where that risk enters the workflow and how to keep exact data in deterministic code.

Copilot CLI may feel like a personal assistant, but it is actually more like a team of specialists. If you provide the right prompt, you can have those specialists introduce themselves and describe how they can each help you to get more done.

Relative script paths look like the portable choice for an Agent Skill – right up until Copilot runs one from the workspace root and spends another turn recovering. A small SKILL.md convention can help the model resolve the real script path before execution, avoiding the failed call and making your skill load more efficiently.

A million-token context window sounds like the end of your retrieval problems. I get the appeal. If you can fit the whole manual, repo, or incident history into one prompt, it feels like the model should finally have everything it needs. But bigger context is not the same as better answers. This post walks through what recent research actually shows, where long-context models still break down, and why a smaller, better-curated prompt often works better.

An AI model evaluation escaped its intended boundaries, reached the Internet, and compromised Hugging Face systems while chasing benchmark answers. The incident highlights the importance of understanding the new world of agentic security.

That line in your agent file that says “see shared-setup.md for details” looks harmless. In code, it’s a free pointer – the compiler resolves it at build time and you never think about it again. In AI instructions, it’s a request for the model to make a choice that may have unexpected performance (and pricing) considerations. Whether that cost is worth paying depends on what you’re referencing – and the answer isn’t always what you’d expect.

You gave the AI a rubric: score this issue from 1 to 10 based on impact, urgency, and risk. It gave you a 7. You ran it again on the exact same issue. This time it said 4. You tried a third time: 9. The criteria didn’t change. The input didn’t change. But your scores are all over the map. What just happened? And more importantly, what do you actually build when you need scores you can rely on?

You prompted your AI to do something. It came back and said “Done.” Tests pass, the files look right. But did it actually follow your instructions, or did it take shortcuts, ignore skills, and waste tokens reading scripts instead of executing them? Today we look at how logs enable you to make your agentic setup more reliable and avoid those kinds of surprises.

Letting AI coding agent run autonomously with access to your network, your secrets, and your entire machine is risky. One rogue call is all it takes. One way to help protect yourself is to use microVM isolation to control the environment and what the agent can access. Docker Sandboxes is one such solution. I’ll walk you through setting it up and exploring some of its file system, network management, and monitoring capabilities.