Manu's Vault

AI-Agent-Tooling-Ecosystem

7 min readStatus:Seedling

AI Agent Tooling Ecosystem — The Five-Layer Stack

The landscape of AI agent tooling is fragmented in name but convergent in structure. Practitioners encounter MCP servers, skills, plugins, powers, hooks, and back-pressure mechanisms as separate concepts, often adopted ad hoc as new capabilities become available. But these components are not independent additions — they form a coherent five-layer stack, and each layer serves a distinct purpose that no other layer can substitute for.

The case for deliberate stack design is empirical: Context-Engineering research shows that context window quality — not raw model capability — is the primary determinant of agent output quality. Every poorly chosen tool adds token overhead. Every redundant component degrades performance. Understanding the stack as a whole is the precondition for making deliberate choices at each layer.

Layer 1: The Protocol — Model-Context-Protocol

The foundation of modern agent tooling is a standardized communication protocol. Before Model-Context-Protocol (MCP), every AI agent required bespoke connectors for each external system — one adapter for databases, another for APIs, another for file storage. The result was brittle, non-transferable integration code that accumulated technical debt faster than value.

MCP replaces this fragmentation with a single open standard: “the USB-C port for AI applications.” Any MCP-compatible host (Claude, Cursor, VS Code Copilot) can connect to any MCP server without custom glue code. The three server primitives — tools (executable functions), resources (data sources), and prompts (reusable templates) — cover the full range of agent-environment interaction.

The security surface is real: MCP tool descriptions inject directly into the system prompt, creating a prompt injection attack vector via malicious servers. Practitioners should connect only to trusted servers and disable unused connections — excess tool definitions consume context budget and degrade model performance.

Layer 2: Capabilities — Agent-Skills and Kiro-Powers

With a protocol in place, the second design question is what the agent knows how to do. Capabilities sit above the protocol layer and package domain expertise into activatable modules.

Agent Skills are filesystem-based modules — a SKILL.md file plus optional bundled resources — that extend agent behavior without rebuilding the agent. They use a three-level progressive disclosure model:

  • Level 1: lightweight metadata loaded at startup (~100 tokens per skill)
  • Level 2: full SKILL.md instructions, loaded only when the skill is triggered by a matching request
  • Level 3: bundled executable resources, loaded only when explicitly referenced

This design decouples capability breadth from context cost. An agent can have access to twenty skills while consuming context budget for only the one currently needed.

Kiro-Powers extend this pattern further: dynamic capability bundles that combine MCP tool configurations with domain-specific steering guides, activated by keyword detection rather than explicit invocation. Powers solve the context overflow problem of static MCP configurations — five connected servers can consume 50,000+ tokens before the first prompt — by keeping baseline context usage near zero and loading full tool definitions only when triggered.

The spectrum runs: AGENTS-md-Files (always loaded, universal rules) → Agent Skills (on-trigger, domain-specific workflows) → Kiro Powers (keyword-activated, dynamic tool sets). Choosing where to place a capability determines its context cost profile.

Layer 3: Adapters — AI-Plugins

Plugins are the productized, bundled form of agent capabilities. Where skills are agent-native and powers are IDE-native, plugins are the distribution format: a single installable unit that bundles MCP tool configurations, skill definitions, and behavior instructions into a one-click installation.

Claude Plugins demonstrate the pattern: a plugin for a service like Stripe or Supabase delivers MCP server configuration, relevant skills, and contextual AGENTS.md instructions together, managed as a versioned package with community oversight and Anthropic-verified listings.

The distinction between plugins and the layers above matters in practice: plugins are not a technical primitive but a packaging and distribution mechanism. Their underlying components are MCP tools, skills, and behavior instructions. Understanding this prevents the common confusion of treating plugin installation as a substitute for deliberate capability design.

Security remains the critical concern: plugins expand the attack surface significantly. Indirect prompt injection — malicious content in retrieved data hijacking tool-use behavior — is a primary risk. Minimal permission scopes and human confirmation for destructive operations are non-negotiable mitigations.

Layer 4: Automation — Hooks-Agent-Lifecycle

The fourth layer is programmable event-driven automation. Hooks are user-defined scripts that execute at defined points in the agent’s lifecycle — before and after tool use, at session boundaries, on file changes, when the agent needs input. Their conceptual ancestor is Aspect-Oriented Programming: inserting cross-cutting concerns (logging, validation, enforcement) at the seam between agent and environment, without modifying agent instructions.

The practical power of hooks is in the silent-success / verbose-failure pattern: a hook that passes silently and surfaces only errors forces the agent to resolve issues before it can stop — a CI-gate applied to agentic sessions. Hooks can auto-format edited files, reinject context reminders after compaction, block dangerous shell commands, and send notifications when the agent is idle.

Crucially, hooks are the mechanism by which the other layers integrate: a PostToolUse hook can verify that an MCP tool invocation produced valid output; a SessionStart hook can activate the correct skill set for the current task context; a PreToolUse hook can enforce back-pressure before an action is taken.

Layer 5: Verification — Back-Pressure-Mechanisms

The fifth layer is deterministic enforcement. Back-pressure mechanisms — type checkers, build steps, unit tests, integration tests, linters, structural tests, property-based tests — provide structured failure signals that an agent can act on to self-correct.

Empirical evidence confirms the leverage: interactive TDD workflows achieve up to 45.97% improvement in pass@1 accuracy within five interactions (Fakhoury et al., 2024). The mechanism is precise: test failures create unambiguous correction signals that the model can reason about and address.

The critical design discipline is failure-only surfacing: passing output is suppressed; only failures emit. Every line of “test passed” output is wasted context budget. This constraint makes back-pressure compatible with long-running sessions — verification can run frequently without degrading context quality.

Back-pressure is not optional and is not substitutable by any other layer. It is the boundary between probabilistic reasoning (the middle of the harness) and deterministic outcomes (what actually ships).

Practical Stack Design

The five layers have a natural adoption order based on return-on-investment:

  1. Start with back-pressure — verification is always needed and has the highest marginal impact on agent success rates
  2. Add AGENTS-md-Files — persistent behavioral guidance prevents the most common failure modes across all tasks
  3. Add skills or MCP — extend capability for specific domains as needed, using progressive disclosure to control context cost
  4. Add hooks — automate verification, formatting, and integration logic once the capability layer is stable
  5. Add powers or plugins — introduce dynamic capability management as complexity grows and context efficiency becomes the binding constraint

Accumulating components in the wrong order — installing plugins before establishing verification, adding MCP servers before writing AGENTS.md — produces harnesses that are broad in capability but shallow in reliability. The five-layer model makes the design sequence explicit.

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks