AWS Agent Plugins and the Compound Plugin Pattern: How Cloud Providers Are Shipping Production-Grade Agent Skills
AWS Agent Plugins and the Compound Plugin Pattern: How Cloud Providers Are Shipping Production-Grade Agent Skills
On 17 February 2026, AWS Labs open-sourced awslabs/agent-plugins — the first major cloud provider plugin suite purpose-built for AI coding agents 1. The repository ships seven plugins that work across Claude Code, Codex CLI, and Cursor 2, and introduces what is arguably the most important architectural pattern in the nascent plugin ecosystem: the compound plugin.
This article dissects the compound plugin architecture, walks through the deploy-on-aws workflow, shows how to wire these plugins into Codex CLI via marketplace.json, and considers what Azure and GCP will need to ship to compete.
What Is a Compound Plugin?
A traditional agent skill is a single SKILL.md file — a structured workflow document that an agent reads and follows. It is essentially a sophisticated prompt template with step-by-step instructions.
A compound plugin bundles four distinct artifact types into a single distributable unit 1:
| Artifact | Purpose | Example |
|---|---|---|
| Agent Skills | Structured workflows and best-practice playbooks | skills/deploy/SKILL.md |
| MCP Servers | Live connections to external services, data, and APIs | aws-pricing, aws-knowledge, aws-iac-mcp |
| Hooks | Automation and guardrails triggered on developer actions | validate-drawio.sh (PostToolUse) |
| References | Documentation, configuration defaults, and knowledge | Style guides, templates, example diagrams |
The key insight is that skills alone lack runtime context. An agent following a deployment playbook cannot estimate costs without a pricing API, cannot validate IaC without a CDK linter, and cannot enforce diagram standards without a PostToolUse hook. The compound plugin pattern solves this by packaging the entire capability surface — instruction, data access, validation, and knowledge — into a single installable unit.
graph TD
A[Compound Plugin] --> B[Agent Skills<br/>SKILL.md workflows]
A --> C[MCP Servers<br/>Live data & APIs]
A --> D[Hooks<br/>Guardrails & automation]
A --> E[References<br/>Docs & templates]
B --> F[Agent reads workflow steps]
C --> G[Agent queries pricing, docs, IaC]
D --> H[Validation runs on tool use]
E --> I[Agent consults knowledge base]
F --> J[Deterministic, auditable execution]
G --> J
H --> J
I --> J
The Seven AWS Plugins
The awslabs/agent-plugins marketplace ships seven plugins as of April 2026 23:
| Plugin | Focus | Key Capabilities |
|---|---|---|
deploy-on-aws |
Infrastructure deployment | Architecture recommendations, cost estimates, CDK/CloudFormation generation |
aws-serverless |
Lambda, API Gateway, EventBridge, Step Functions | Serverless architecture patterns and deployment |
aws-amplify |
Full-stack apps with Amplify Gen 2 | Auth, data, storage, serverless functions, sandbox deployment |
databases-on-aws |
Database guidance (Aurora DSQL initially) | Database selection, schema design, connection patterns |
amazon-location-service |
Maps, geocoding, routing | Geospatial feature integration |
migration-to-aws |
GCP-to-AWS migration | Resource discovery, architecture mapping, cost analysis |
sagemaker-ai |
ML model lifecycle | Build, train, deploy AI/ML models |
Each plugin is a compound plugin — not merely a skill file, but a complete capability unit with its own MCP servers, hooks, and reference material 1.
Deep Dive: deploy-on-aws
The deploy-on-aws plugin is the flagship and the best illustration of the compound pattern. It implements a five-step deterministic workflow 45:
The Five-Step Workflow
flowchart LR
A[1. Analyse] --> B[2. Recommend]
B --> C[3. Estimate]
C --> D[4. Generate]
D --> E[5. Deploy]
C -.->|aws-pricing MCP| P[(Live Pricing API)]
A -.->|aws-knowledge MCP| K[(AWS Docs)]
D -.->|aws-iac-mcp| I[(CDK/CFn Validator)]
- Analyse — examines project structure, dependencies, and runtime requirements 5
- Recommend — proposes AWS services with rationale (e.g., App Runner for the backend, RDS PostgreSQL for the database, CloudFront + S3 for the frontend) 5
- Estimate — queries the
aws-pricingMCP server for real-time cost projections before any infrastructure is committed 4 - Generate — produces CDK or CloudFormation code with security defaults applied 4
- Deploy — executes deployment only after explicit user confirmation 5
Three Backing MCP Servers
The skill file alone would be a 600-line prompt with no access to live data. The compound pattern solves this with three bundled MCP servers 4:
aws-knowledge— architecture decisions, service documentation, and best practicesaws-pricing— real-time cost data from the AWS Pricing APIaws-iac-mcp— CDK and CloudFormation validation and guidance
Hooks as Safety Rails
The deploy-on-aws plugin also ships PostToolUse hooks — notably validate-drawio.sh for the architecture diagram skill, which validates generated .drawio diagrams against style guides and templates stored in the references/ directory 6. This pattern ensures that agent outputs conform to organisational standards without requiring the developer to manually review every artefact.
Installing AWS Plugins in Codex CLI
Codex CLI supports plugin installation via repo-local or personal marketplace.json files 78. To add the AWS agent plugins marketplace:
Step 1: Add the Marketplace
codex marketplace add https://github.com/awslabs/agent-plugins
This registers the AWS marketplace in your Codex plugin configuration. Codex reads the marketplace catalogue and makes all seven plugins available for installation 8.
Step 2: Install a Plugin
codex marketplace install deploy-on-aws
Codex installs the plugin into ~/.codex/plugins/cache/awslabs-agent-plugins/deploy-on-aws/<version>/, wiring up the skill files, MCP server configurations, and hooks automatically 7.
Step 3: Configure in config.toml
For enterprise deployments, you may want to pin plugins in your project’s config.toml:
[plugins]
marketplaces = ["https://github.com/awslabs/agent-plugins"]
[plugins.installed]
deploy-on-aws = { version = "latest", policy = "INSTALLED_BY_DEFAULT" }
aws-serverless = { version = "latest", policy = "AVAILABLE" }
The three-tier installation policy (INSTALLED_BY_DEFAULT, AVAILABLE, NOT_AVAILABLE) gives enterprise teams granular control over which plugins are active by default versus opt-in 7.
The Plugin Directory Structure
Understanding the on-disk layout clarifies how the compound pattern works:
plugins/deploy-on-aws/
├── .codex-plugin/
│ └── plugin.json # Manifest: metadata, component pointers
├── .mcp.json # MCP server definitions
├── skills/
│ ├── deploy/
│ │ ├── SKILL.md # Five-step deployment workflow
│ │ └── references/ # Architecture patterns, defaults
│ └── aws-architecture-diagram/
│ ├── SKILL.md # Diagram generation skill
│ └── references/ # Style guides, templates, examples
└── scripts/
├── validate-drawio.sh # PostToolUse hook
└── lib/ # Post-processing pipeline
The plugin.json manifest is the glue — it declares which skills, MCP servers, and hooks the plugin provides, along with package metadata and installation surface fields 67.
Cross-Tool Portability
One of the most significant aspects of the compound plugin pattern is its emerging cross-tool portability. The @every-env/compound-plugin CLI can convert Claude Code plugins into formats for Kiro, OpenCode, Codex, Factory Droid, Gemini CLI, GitHub Copilot, and others 9. Skills and MCP server configurations translate cleanly; hooks are the current gap, as hook models differ between tools and are dropped during conversion 9.
This suggests a future where compound plugins become a lingua franca for agent capabilities — write once for Claude Code’s plugin format, convert for Codex CLI’s marketplace, and deploy across your team’s heterogeneous tooling.
What Azure and GCP Need to Ship
AWS’s first-mover advantage is substantial. As of April 2026, the competitive landscape looks like this 1011:
| Capability | AWS | Azure | GCP |
|---|---|---|---|
| Official agent plugin suite | ✅ 7 compound plugins | ❌ No equivalent | ❌ No equivalent |
| MCP servers for coding agents | ✅ 60+ servers | ✅ Azure DevOps, AI Foundry | ✅ Smaller count, granular controls |
| Deterministic deployment workflow | ✅ Five-step with cost estimation | ❌ | ❌ |
| Cross-tool support | ✅ Claude Code, Codex, Cursor | Partial (VS Code integration) | Partial (Gemini CLI) |
| Plugin marketplace format | ✅ marketplace.json | ❌ | ❌ |
Azure’s strongest card is deep Visual Studio and Azure DevOps integration — the Azure DevOps MCP Server for work items, pipelines, and test management is a genuine differentiator that AWS lacks 10. But Azure has no compound plugin equivalent that bundles skills, MCP servers, hooks, and references into a single deployable unit.
GCP has invested in the Agent Development Kit (ADK) with a Python-first approach and has official MCP servers with granular read-only/read-write controls 11. However, GCP’s MCP server count is the smallest of the three, and there is no plugin marketplace format.
For Azure and GCP to compete, they need to ship:
- Compound plugin specifications — a manifest format that bundles skills, MCP, hooks, and references
- Deployment workflow plugins — deterministic, auditable deployment pipelines with real-time cost estimation
- Marketplace infrastructure — discoverability and version management for plugin distribution
Security Considerations
The compound plugin pattern introduces a broader attack surface than simple skill files. Each MCP server is a network-connected process with access to cloud APIs. Enterprise teams should consider:
- Least-privilege IAM — each MCP server should use scoped credentials, not broad administrator access
- Hook validation — PostToolUse hooks execute arbitrary scripts; review them as you would CI pipeline code
- Plugin pinning — use specific versions rather than
latestin production environments - Network policy — restrict MCP server outbound connections using Codex CLI’s
[permissions.network]domain allowlists
⚠️ The current plugin format does not include a cryptographic signing mechanism for verifying plugin integrity. This is an open gap for enterprise adoption.
The Plugin Maturity Ladder
Not every capability needs the full compound treatment. The AWS plugin suite illustrates a natural maturity progression:
graph BT
A["Level 1: Single SKILL.md<br/>(Structured prompt)"] --> B["Level 2: Skill + References<br/>(Knowledge-augmented)"]
B --> C["Level 3: Skill + MCP Server<br/>(Data-connected)"]
C --> D["Level 4: Compound Plugin<br/>(Skills + MCP + Hooks + Refs)"]
style D fill:#f96,stroke:#333
Start with a SKILL.md for internal workflows. Add references when the agent needs domain knowledge. Connect an MCP server when live data is required. Graduate to a full compound plugin when you need guardrails, validation, and cross-tool distribution.
Conclusion
AWS’s agent-plugins repository is more than a collection of cloud deployment shortcuts. It establishes the compound plugin as the unit of distribution for production-grade agent capabilities — bundling instruction, data access, automation, and knowledge into a single installable package. With cross-tool converters already emerging and Codex CLI’s marketplace infrastructure maturing, the compound plugin pattern is likely to become the standard way cloud providers and enterprises ship agent skills.
The question is no longer whether your cloud provider supports MCP. It is whether they ship compound plugins that actually work end-to-end.
Citations
-
Introducing Agent Plugins for AWS — AWS Developer Tools Blog ↩ ↩2 ↩3
-
AWS Weekly Roundup: Agent Plugin for AWS Serverless — March 30, 2026 ↩
-
AWS Launches Agent Plugins to Automate Cloud Deployment — InfoQ ↩ ↩2 ↩3 ↩4
-
Beyond Assistance: The Executive Power of “Agent Plugins for AWS” — DEV Community ↩ ↩2 ↩3 ↩4
-
Build plugins — Codex CLI Developer Documentation ↩ ↩2 ↩3 ↩4
-
Plugin support: local-based marketplace.json — openai/codex PR #13422 ↩ ↩2
-
Compound Engineering Plugin — EveryInc/compound-engineering-plugin — GitHub ↩ ↩2
-
Azure MCP Server: Setup, Tools, and Configuration for AI Coding Agents (2026) ↩ ↩2
-
AWS Agent Plugin: Frictionless Deployment? Developer Honeypot? — Futurum Group ↩ ↩2