Skills, Tools, Plugins, oh my!

If you've spent time with AI agents lately, you may know this experience:

You discover one useful way to customize an agent, feel like you finally understand it, and then someone says "No, that should really be a skill" or "This belongs in a custom agent" or "Just expose it over MCP".

The problem in 2026 is no longer a lack of options. It's that we now have so many overlapping ways to customize agent behaviour. And when teams mix those layers up, they can end up with bloated prompts, unsafe tool access, and a whole new type of tech debt to manage.

The hardest part is rarely "Can I customize this agent?" It's choosing the cleanest customization that fits the job.

Understanding Agentic Primitives

A term I use a lot lately is agentic primitive. It gives us a way to talk about the smallest reusable building blocks in an agent system, without the vendor-specific naming.

There are already many types of agentic primitives, expressed mostly in the form of Markdown files with specific frontmatter sections. They are composable, have boundaries, and can be improved independently.

• Custom Instructions (.instructions.md) are great for stable rules and conventions to keep your agents on track.
• Prompt Files (.prompt.md) are great for reusable workflows you want to repeat or share.
• Custom Agents (.agent.md) or other custom agent definitions are great for persona-based role separation and tool boundaries.
• Spec Files (.spec.md) are a convention for storing a detailed specification that can be read & updated by agents.
• Memory Files (.memory.md) help capture decisions and lessons that should persist between sessions.
• Context Files (.context.md) help an agent pull in the right supporting material without dragging in the whole universe.

The 2026 customization stack

The guidelines for using each customization are always evolving, but here's how I think about them currently:

When I'd use each one

If the same long text keeps appearing in your chat history, that is usually a prompt file trying to happen. Save it.

If you want an agent to behave like a specialist with a narrow remit, that is usually a custom agent problem. Define the role, define the boundaries, and restrict the tools.

If the agent needs to cross system boundaries to interact with another application or enterprise platform, that is an often an MCP tool problem (although CLI commands being called directly by agents are starting to challenge this).

If you have something more reusable than a single prompt and broader than a single file, that is often a skill. This is especially true when you want to package examples, workflow guidance, and domain knowledge together for others.

If you need to package a set of other primitives for easy sharing across your team, explore plugins for your specific platform. Or for a platform independent approach to distribution, use Agent Package Manager.

Anti-patterns to watch for

These are some anti-patterns I'd avoid right now:

• The mega-prompt: one giant wall of text that tries to hold role, rules, examples, workflow, output format, and safety guidance all in one place
• The god-agent: one custom agent with every tool enabled because scoping felt inconvenient
• Instruction sprawl: lots of overlapping instructions with no hierarchy, so the agent gets inconsistent guidance
• Tool sprawl: exposing dozens of tools or skills "just in case" and then wondering why the agent makes odd choices

Nearly every bad agent setup I see recently can be explained as a violation of one a few constraints: too much context or scope, poor composition or boundaries, or unclear guidance.

Once you start treating these customizations as modular assets, you can improve them the same way you improve code. You can version them, refactor them, compose them, and share them.

Want to learn more?

Daniel Meppiel's new Agentic SDLC Handbook and PROSE Framework is great if you want a deeper dive on this. He goes through usage patterns of each primitive in detail, as well as guiding architecture principles:

• Progressive Disclosure: load context just-in-time, not all at once
• Reduced Scope: break work into units small enough for the model to hold clearly
• Orchestrated Composition: combine small primitives instead of writing one mega-prompt
• Safety Boundaries: give agents autonomy inside explicit limits
• Explicit Hierarchy: apply the most relevant rules at the most relevant level

If you only take one idea from that framework, make it this: reliable agents usually come from better composition, not longer prompts.