Agent Plugins Are the Future — But You Might Be Giving Away Your Best Engineering
Table of Contents
AWS just dropped Agent Plugins — a packaging model that bundles skills, MCP servers, hooks, and reference docs into installable units for AI coding agents. Two commands and your Claude Code or Cursor agent knows how to deploy to AWS, estimate costs, and generate IaC.
This is genuinely exciting. And it’s also the moment we need to have an honest conversation about what we’re trading away when we reach for the install button.
What Agent Plugins Actually Are
Before the opinion — let’s understand the mechanics. An agent plugin is a container that packages multiple types of expertise together:
- Agent Skills — Structured workflows and playbooks. Think step-by-step guides for complex tasks like “analyze my codebase → recommend AWS architecture → estimate costs → generate CDK → deploy.” The skill encodes domain expertise that the agent follows.
- MCP Servers — Live connections to external data. AWS pricing APIs, documentation indexes, IaC best practices. Your agent gets runtime access to information that would be insane to stuff into a prompt.
- Hooks — Guardrails and automation. Validation checks that run on developer actions, enforcing standards without anyone having to remember them.
- References — Documentation and configuration that skills can consult. Knowledge without context bloat.
The first plugin — deploy-on-aws — bundles all four. Install it, say “deploy this to AWS,” and the agent scans your codebase, recommends services, shows you cost estimates, writes CDK, and walks you through deployment. That’s a workflow that used to take a senior engineer half a day, compressed into a conversation.
# Two commands. That's it.
/plugin marketplace add awslabs/agent-plugins
/plugin install deploy-on-aws@agent-plugins-for-awsWhy This Is the Future
Here’s why I think plugins are going to reshape how engineering teams operate:
1. Skills Become Composable and Shareable
Right now, every team with a skilled prompt engineer has their own private collection of agent workflows. Maybe it’s a CLAUDE.md file with deployment instructions. Maybe it’s a carefully crafted system prompt for code review. Either way — it’s locked in someone’s head or scattered across team wikis.
Plugins formalize this. Skills become versioned, testable, distributable artifacts. The same way npm turned JavaScript libraries from “copy this file from Dave’s blog” into a managed ecosystem — agent plugins are doing the same for AI-assisted engineering workflows.
2. The Marketplace Model Is Inevitable
AWS has two plugins today. There will be hundreds within a year. Every infrastructure vendor, every SaaS tool, every internal platform team will ship a plugin that teaches agents how to work with their product.
Think about it: Datadog ships a plugin that teaches your agent how to set up monitoring. PagerDuty ships one for incident response workflows. HashiCorp ships one for Terraform best practices. Your internal platform team ships one that knows your specific deployment pipeline, naming conventions, and compliance requirements.
This is the app store moment for engineering agents.
3. Teams Can Standardize Without Meetings
One plugin installed across a team means every developer’s AI agent follows the same deployment workflow, the same architecture patterns, the same cost estimation methodology. No more “but my agent does it differently.” Consistency through tooling rather than process documents nobody reads.
Here’s the Catch: You’re Giving Away Your Brain
Now for the part that keeps me up at night.
Every time you reach for a plugin instead of understanding the underlying problem, you’re outsourcing a piece of your engineering intelligence. And unlike outsourcing compute or storage, you can’t buy this back when you need it.
Your Prompts Are Your Competitive Advantage
Think about what a well-crafted deployment skill actually contains: years of hard-won knowledge about architecture trade-offs, failure modes, cost optimisation patterns, security considerations, and operational gotchas. When you write your own agent skill for deploying to AWS, you’re encoding your understanding of your problem domain.
When you install someone else’s plugin instead, you’re saying: “I trust this vendor’s generic understanding more than my specific knowledge.” Sometimes that’s the right call. Often it isn’t.
The Plugin Knows the Happy Path. You Need to Know the Sad Path.
The deploy-on-aws plugin will do a solid job of getting your application running on AWS. It follows AWS best practices, estimates costs, generates clean CDK.
But what happens when that deployment breaks at 2am? When the cost estimate was wrong because your traffic pattern doesn’t match the model? When the recommended architecture doesn’t account for your specific compliance requirements?
The engineer who wrote their own deployment workflow understands the decisions. The engineer who installed a plugin and pressed deploy doesn’t.
This isn’t hypothetical. I’ve watched teams who relied entirely on “wizard-style” deployment tools get absolutely stuck when those tools hit edge cases. They’d automated away the understanding, not just the toil.
You’re Training Yourself Out of Relevance
Here’s the uncomfortable truth: if an off-the-shelf plugin can do your job, your job is already commodity work. The value isn’t in executing the deployment — it’s in understanding why you’re deploying this way, what the trade-offs are, and what to do when things go wrong.
Every plugin you install without understanding is a skill you’re choosing not to develop. Compound that over a career and you end up as an “AI operator” rather than an engineer — someone who can install and run plugins but can’t build, debug, or improve them.
The Right Way to Use Plugins
I’m not saying don’t use plugins. That would be like saying don’t use libraries. The nuance matters:
Build First, Then Adopt
Before you install a deployment plugin, try building your own agent skill for your deployment workflow. Even a rough one. You’ll learn more about your architecture in an afternoon of skill-writing than in six months of plugin-clicking.
Once you understand the problem space deeply, then evaluate plugins. You’ll know which parts of the plugin are brilliant (and worth adopting) and which parts are generic (and worth replacing with your own logic).
Own Your Core, Plugin Your Periphery
Every team has core workflows that are their competitive advantage — the things they do differently, better, or faster than everyone else. Never plugin your core. Write those skills yourself. Version them. Guard them.
For everything else — generic AWS deployment patterns, standard monitoring setup, boilerplate compliance checks — plugins are perfect. Let someone else maintain the commodity stuff.
Read the Source
Agent plugins are open source. Before you install one, read the skill definitions. Understand what decisions it’s making on your behalf. Treat it like you’d treat any dependency: know what it does, know its limitations, have a plan for when it breaks.
# Don't just install blindly
# Read the skill source first
gh repo clone awslabs/agent-plugins
cat agent-plugins/plugins/deploy-on-aws/skills/deploy.mdKeep Learning the Fundamentals
The engineers who thrive in the agent-assisted future won’t be the ones who installed the most plugins. They’ll be the ones who understand AWS well enough to write their own plugins — or know when an existing plugin is making a bad recommendation.
Plugins are accelerators, not replacements for understanding. The moment you stop learning the underlying technology because “the plugin handles it” is the moment you’ve started the clock on your own obsolescence.
The Real Opportunity
The engineers I’m most excited about aren’t the ones installing plugins. They’re the ones building them. They’re taking their hard-won domain expertise and packaging it as reusable, composable skills that make their whole team better.
That’s the real opportunity here. Don’t just consume the plugin marketplace — contribute to it. Take the deployment workflow you’ve refined over years of production incidents. Take the security review checklist that catches the bugs others miss. Take the cost optimisation patterns that saved your company real money. Package them. Share them. That’s how you become more valuable, not less.
But be deliberate about it. Know what you’re sharing, know what you’re keeping, and never stop understanding the systems underneath.
Agent Plugins for AWS are available now on GitHub. If you’re going to install them — and you should look at them — read the source first. Your future self will thank you.
