Agent Plugins Are the Future. But You Might Be Giving Away Your Best Engineering.

A few weeks ago AWS 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.

I have been sitting with this since the announcement. The more I think about it, the more I think this is one of those inflection points that looks small now and obvious later. It is also the moment we need to have an honest conversation about what we are trading away when we reach for the install button.

What Agent Plugins Actually Are

An agent plugin is a container that packages multiple types of expertise together:

• Agent Skills: Structured workflows and playbooks. Step-by-step guides for tasks like “analyse 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. 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-aws

The App Store Moment for Engineering Agents

Here is why I think plugins are going to reshape how engineering teams operate.

Skills Become Composable

Right now, every team with a skilled prompt engineer has their own private collection of agent workflows. Maybe it is a CLAUDE.md file with deployment instructions. Maybe it is a carefully crafted system prompt for code review. Either way, it is locked in someone’s head or scattered across team wikis.

Plugins formalise 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. If you’ve been following the 10 open source agent projects I reviewed, you can see the foundation forming: MCP servers, skills, hooks — plugins formalise what that community built ad hoc.

The Marketplace Is Already Growing

The ecosystem is expanding quickly. Every infrastructure vendor, every SaaS tool, every internal platform team will ship a plugin that teaches agents how to work with their product. Datadog ships one for monitoring. PagerDuty ships one for incident response. HashiCorp ships one for Terraform best practices. Your internal platform team ships one that knows your specific deployment pipeline, naming conventions, and compliance requirements.

Consistency Without Committees

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.

The Part Nobody Is Talking About: Trust Boundaries

Now for the part that keeps me up at night.

Agent plugins are not dependencies in the way we normally think about them. An npm package manipulates data. An agent plugin manipulates decision-making. That is a categorically different blast radius.

When you install a plugin, you are giving code access to your development environment: your codebase, your environment variables, your cloud credentials, your MCP connections to external APIs. A plugin that can influence how your agent reasons about IAM permissions while also holding tool-use permissions has something close to kernel-level access to your engineering workflow.

Simon Willison and Johann Rehberger have done important work documenting indirect prompt injection risks through tool-use surfaces. The AWS MCP strategy guide addresses this directly with token isolation and golden path abstractions. Agent plugins sit squarely in that threat model. A compromised or poorly-scoped plugin does not just exfiltrate data; it steers the agent’s reasoning chain. You would not see a malicious action in the logs because the agent genuinely believed it was following correct policy. The exploit is upstream of the decision itself.

Think about what a well-crafted deployment skill actually contains: years of hard-won knowledge about architecture trade-offs, failure modes, cost optimisation patterns, and operational gotchas. When you install someone else’s plugin instead of writing your own, you are saying: “I trust this vendor’s generic understanding more than my specific knowledge.” Sometimes that is the right call. Often it is not.

The deploy-on-aws plugin will do a solid job getting your application running. 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 does not match the model? When the recommended architecture does not account for your compliance requirements?

The engineer who wrote their own deployment workflow understands the decisions. The engineer who installed a plugin and pressed deploy does not.

Own Your Core, Plugin Your Periphery

I am 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 Claude skills for your deployment workflow. Even a rough one. You will 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 will know which parts are brilliant and which are generic.

Guard your core workflows. Every team has workflows that are their competitive advantage. Never plugin your core. Write those skills yourself. Version them. For everything else (generic deployment patterns, standard monitoring, 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 makes on your behalf. Treat it like you would 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.md

Keep learning the fundamentals. The engineers who thrive in the agent-assisted future will not be the ones who installed the most plugins. They will be the ones who understand AWS well enough to write their own, or know when an existing plugin is making a bad recommendation. The moment you stop learning the underlying technology because “the plugin handles it” is the moment you have started the clock on your own obsolescence.

The Real Opportunity

The engineers I am most excited about are not the ones installing plugins. They are the ones building them. They are taking their hard-won domain expertise and packaging it as reusable, composable skills that make their whole team better.

Don’t just consume the plugin marketplace. Contribute to it. Take the deployment workflow you have 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 organisation real money. Package them. Share them. That is how you become more valuable, not less.

But be deliberate about it. Know what you are sharing, know what you are keeping, and never stop understanding the systems underneath.

Agent Plugins for AWS are available now on GitHub. If you are going to install them, and you should look at them, read the source first. Your future self will thank you.