feat(mcp-agentic): Add MCP Agentic power with agent delegation framework

[morozow]

Add mcp-agentic power — External Agent Delegation for Kiro

What this enables

This PR adds the MCP Agentic power to the Kiro powers registry. With it, Kiro gains a standard bridge for discovering and delegating work to external ACP-compatible agents through MCP.

In practice: a Kiro user can find what specialist agents are available, send them tasks, carry on multi-turn conversations with them, and manage the full session lifecycle — without leaving the IDE. The agents themselves can be written in any language and run as separate processes, as long as they speak ACP over stdio.

The power is built on @stdiobus/mcp-agentic (Apache-2.0) from the stdio Bus ecosystem.

---

What Kiro users can do

• Discover available agents — find which specialist agents are registered and what capabilities each one advertises, so Kiro can pick the right agent for the job
• Delegate tasks — route focused work (code analysis, data processing, security review, etc.) to an external agent and receive structured results back
• Run multi-turn sessions — open a session with an agent and exchange multiple prompts while the agent preserves context across interactions
• One-shot delegation — fire-and-forget a single task without managing session lifecycle manually
• Monitor and control sessions — check session status, cancel an in-flight prompt, or close a session when work is done
• Verify bridge health — confirm the agent bridge is operational before delegating
• Connect cross-runtime workers — integrate agents implemented in Python, Go, or any other runtime that can be launched as a worker process and speaks ACP over stdio

---

Why this belongs in the Kiro powers registry

• Extends Kiro with external agent delegation — gives users a standard path to work with specialist agents beyond Kiro's built-in capabilities, through the same MCP interface Kiro already uses for other powers
• ACP as the agent interface — adopts the Agent Communication Protocol for agent interaction, providing a well-defined contract between Kiro and external agents
• Cross-runtime integration — agents don't need to be JavaScript or run inside Kiro's process; any ACP-compatible worker process can participate
• Session-first design — multi-turn sessions with context continuity are a first-class capability, not an afterthought; this matters for iterative workflows where a single prompt isn't enough
• Controlled delegation surface — read-only tools are auto-approved; mutating tools (session creation, prompting, delegation) require explicit user approval, keeping the user in control

---

Example workflows

Discover and delegate (one-shot):
A user asks Kiro to analyze a codebase for security issues. Kiro activates the power, discovers a code-analysis agent, and delegates the task in a single call:

bridge_health()                    → { healthy: true }
agents_discover({ capability: "code-analysis" })
                                   → [{ id: "sec-scanner", capabilities: ["code-analysis"], status: "ready" }]
tasks_delegate({ agentId: "sec-scanner", prompt: "Analyze src/ for security issues" })
                                   → { text: "Found 3 issues...", stopReason: "end_turn" }

Multi-turn session with context:
A user needs iterative work — first analyze, then fix. Kiro opens a session and continues the conversation:

sessions_create({ agentId: "sec-scanner" })
                                   → { sessionId: "abc-123", status: "active" }
sessions_prompt({ sessionId: "abc-123", prompt: "Analyze src/ for vulnerabilities" })
                                   → { text: "Found 3 issues...", stopReason: "end_turn" }
sessions_prompt({ sessionId: "abc-123", prompt: "Now suggest fixes for issue #1" })
                                   → { text: "Here's the fix...", stopReason: "end_turn" }
sessions_close({ sessionId: "abc-123" })
                                   → { closed: true }

Health check and capability-filtered discovery:
Before delegating, Kiro verifies the bridge is up and finds agents with a specific capability:

bridge_health()                    → { healthy: true }
agents_discover({ capability: "data-analysis" })
                                   → [{ id: "py-agent", capabilities: ["data-analysis"], status: "ready" }]

---

What's included

Files

mcp-agentic/
├── POWER.md                                    # Metadata (14 keywords), rules, tool reference, examples
├── mcp.json                                    # MCP server config (npx @stdiobus/mcp-agentic)
└── steering/
    ├── activation-and-scope.md                 # When to activate/deactivate, session continuity checks
    ├── configuration.md                        # Server config, agent registration, worker setup, limits
    ├── delegation-and-session-lifecycle.md      # Session states, delegation patterns, cleanup rules
    ├── discovery-and-routing.md                # Discovery workflow, agent resolution, routing constraints
    └── failure-handling.md                     # Error categories, retry strategies, user communication

MCP tools (8)

Tool	Purpose	Auto-approved
bridge_health	Check bridge readiness	✓
agents_discover	List available agents, filter by capability	✓
sessions_status	Check session status	✓
sessions_create	Create a new agent session
sessions_prompt	Send a prompt to an existing session
sessions_close	Close a session
sessions_cancel	Cancel an in-flight prompt
tasks_delegate	One-shot delegation (create + prompt + close)

Read-only tools (bridge_health, agents_discover, sessions_status) are auto-approved. All mutating tools require user approval.

Steering coverage

File	Guides Kiro on
activation-and-scope.md	When to activate the power, when not to, session continuity detection, scope boundaries
configuration.md	Server config options, in-process agent registration, worker setup, backpressure and input limits, session TTL/idle settings
delegation-and-session-lifecycle.md	Preferred delegation sequence, session state machine, one-shot vs multi-turn patterns, structured payload handling
discovery-and-routing.md	Discovery workflow, agent resolution priority (in-process > worker), capability filtering, routing failure handling
failure-handling.md	BridgeError categories (CONFIG, UPSTREAM, TRANSPORT, INTERNAL), retry vs permanent errors, idempotent operations, user-facing error communication

---

Important: the shipped mcp.json is a reference server

The mcp.json in this power runs npx -y @stdiobus/mcp-agentic, which starts a reference/diagnostics server with no agents registered. This is by design:

• bridge_health responds (reports readiness state)
• agents_discover returns an empty list
• tasks_delegate and sessions_create will fail (no agents to handle requests)

This is useful for verifying MCP connectivity and inspecting the tool schema. For actual agent delegation, users create a custom entry point that calls server.register() before server.startStdio() — documented in POWER.md and steering/configuration.md.

---

Technical notes

• Package: @stdiobus/mcp-agentic v1.x, Apache-2.0
• Transport: stdio Bus — deterministic C runtime for transport-level JSON-RPC routing between clients and worker processes
• Two execution backends:
  • InProcessExecutor — agents registered via register() run in-memory; sessions have TTL and idle expiry
  • WorkerExecutor — agents registered via registerWorker() run as external processes via StdioBus; worker sessions persist until explicitly closed or server shutdown (no automatic expiry)
• Backpressure: configurable concurrent request limit (default: 50); excess requests are rejected with a retryable error
• Input validation: prompt size (default: 1 MiB) and metadata size (default: 64 KiB) are validated before forwarding
• Error model: typed BridgeError with 4 active categories (CONFIG, UPSTREAM, TRANSPORT, INTERNAL); mapped to MCP JSON-RPC error codes
• Runtime requirement: Node.js >= 20.0.0

---

Reviewer focus

When reviewing this PR, the key things to validate:

1. User-facing capability — is the power's value proposition clear and well-scoped for Kiro users?
2. Tool surface — do the 8 tools map cleanly to discovery, delegation, and session management?
3. Auto-approve boundary — only read-only tools are auto-approved; mutating tools require user confirmation
4. Steering quality — do the 5 steering files give Kiro enough guidance for safe routing, delegation, and failure handling?
5. Reference server caveat — is it clear that the shipped mcp.json is for diagnostics, not production delegation?
6. Session lifecycle coherence — are the session states, expiry rules, and cleanup behavior understandable?

---

Scope and limits

• This PR adds the power and bridge surface only — it does not bundle or ship any specialist agents
• Agent quality and domain behavior depend entirely on the external ACP-compatible workers users connect
• The power provides orchestration and session control; it does not interpret, transform, or summarize agent responses
• In-process sessions have automatic TTL and idle expiry; worker sessions do not auto-expire and must be explicitly closed

---

Checklist

• POWER.md with frontmatter (name, displayName, description, 14 keywords, author, license)
• mcp.json with MCP server configuration
• steering/ directory with 5 workflow-specific guidance files
• Auto-approve limited to read-only tools only
• Reference server behavior documented (no agents registered by default)
• Troubleshooting section in POWER.md
• Security considerations documented (input validation, session isolation, credential handling)
• Examples provided (discovery, one-shot, multi-turn)
• Steering references mapped in POWER.md
• License: Apache-2.0

---

Links

• npm: @stdiobus/mcp-agentic
• stdio Bus: stdiobus.com
• Kiro Powers docs: kiro.dev/docs/powers/create
• ACP: agentcommunicationprotocol.dev

Changelog

• Add POWER.md with comprehensive power documentation and runtime model
• Add mcp.json configuration for MCP server setup
• Add steering/activation-and-scope.md guidance on power usage
• Add steering/configuration.md for configuration options and best practices
• Add steering/delegation-and-session-lifecycle.md for session management patterns
• Add steering/discovery-and-routing.md for agent discovery and routing rules
• Add steering/failure-handling.md for error handling strategies
• Introduces agent discovery, session management, and multi-agent delegation capabilities
• Provides both in-process and external worker execution backends via StdioBus

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Hi @morozow, thank you for your contribution!

Please note that if you haven't already, you would also need to submit your power officially at kiro.dev/powers/submit so it can be reviewed for listing in the Kiro powers registry.

[morozow]

Hi @morozow, thank you for your contribution!

Please note that if you haven't already, you would also need to submit your power officially at kiro.dev/powers/submit so it can be reviewed for listing in the Kiro powers registry.

Done