Ken Muse

Have you ever written a detailed prompt and still gotten an answer that missed the point? A few small habits can make it harder for an AI agent to understand what you want. Let’s look at why that happens and how to make your prompts work more clearly for you.

Reading agent logs by hand is slow, and the raw event files are far too big to paste into a chat. VS Code and GitHub Copilot CLI ship built-in skills that do the reading for you. In this post, you’ll learn how both work, why the log folder is deliberately hard for the agent to reach, and what makes selective access such a clever design choice.

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?