Spec-Driven Agents on AWS: Building with Kiro, MCP, and Bedrock AgentCore

Published June 6, 2026 · 3iDATA · ~13 min read

In our last post we untangled the AWS agent stack — Strands writes, Bedrock Agents manages, AgentCore operates. This one puts it to work. The most productive way to build a real agent on AWS in 2026 combines three things: Kiro for spec-driven development, MCP for tools, and Bedrock AgentCore for production. Here's the end-to-end workflow, why it's faster, and the patterns that make it click.

Why spec-driven, not vibe-driven

Most AI coding jumps straight from a prompt to code — fast, but it drifts: the model guesses intent, requirements live only in your head, and there's nothing to check the result against. Kiro, AWS's agentic IDE, is built around the opposite idea: spec-driven development. Before any code, Kiro turns natural-language intent into three artifacts:

a requirements document (Kiro uses EARS notation — structured "the system shall…" statements — so requirements are precise and testable),
a design document, and
a task list it then implements.

Kiro keeps both modes available: Spec mode for the structured flow above, and Vibe mode for quick prompt-to-code when you don't need the ceremony. For agents, spec mode is the win — as the AWS team put it, building in spec mode "is much more accurate and it's much quicker." The payoff is concrete: AWS reports a drug-discovery agent going from spec to production in three weeks, and a team shipping an agent with 15 backend APIs in three days — work that traditionally took two to three weeks.

💡 The connection to last post. Spec-driven development is the same "know the shape of the work before you fan out" discipline we described in Workflows vs. Agents vs. Subagents — just applied at the IDE level. You decide the structure; the agent fills in the judgment-heavy parts.

Kiro's building blocks for agents

Beyond specs, Kiro has a few features that matter specifically when the thing you're building is itself an agent:

Native MCP integration. Kiro connects to both local and remote Model Context Protocol servers, so the IDE itself can reach your docs, databases, and APIs while it builds.
Steering files. Like rules/conventions files in other IDEs — context-specific instructions that keep generated code consistent. (For example, an AgentCore steering file carrying your CDK best practices, so every generated stack follows the same patterns.)
Agent hooks. Event-triggered automations — run a check, update a doc, regenerate a test — when something happens in the project.
Kiro Powers. A way to bundle MCP servers, steering files, and context together. There's an AgentCore-specific Power that streamlines building agents that target AgentCore.

MCP: the tools your agent will use

An agent is only as useful as the tools it can call, and on AWS those tools speak MCP. Two ways to get them:

Write new MCP servers. In Python, a library like FastMCP lets you expose tools with a decorator and a docstring — and the docstring matters: it becomes the JSON Schema the agent reasons over. As the AWS presenters put it, "the docstring is actually what goes to an agent." Write clear docstrings and your agent picks the right tool; write vague ones and it won't.
Wrap what you already have. AgentCore Gateway converts existing Lambda functions and OpenAPI specs into MCP tools — and connects to pre-existing MCP servers — with no code rewrites. Your backend becomes agent-callable in a few lines of CDK.

Gateway also does semantic tool discovery, so an agent "only gets access to the tools it needs when it needs it" rather than having every tool's schema crammed into its context — the same context-hygiene principle behind tool search in agentic coding tools.

AgentCore: where the agent runs

Once the logic is specced and the tools are exposed, AgentCore is where it goes to production. The pieces you lean on most for a freshly-built agent:

Runtime — serverless, framework-agnostic hosting (LangGraph, Strands, custom SDKs), with per-session microVM isolation and execution windows up to 8 hours for deep, long-running work. You deploy via a Docker container or a zip file, much like a Lambda.
Memory — short-term conversation state plus long-term memory (semantic search, user preferences, summaries, or your own extraction logic).
Gateway — the MCP tool layer described above.
Identity — agent auth wired to your existing IdP.
Observability — CloudWatch tracing of sessions, spans, token usage, and latency, so you can debug an agent the way you'd debug any service.

The end-to-end workflow

Putting it together, a spec-driven agent build looks like this:

Spec it in Kiro. Describe the agent in natural language; let Kiro produce the requirements (EARS), design, and task list. Add an AgentCore steering file so generated infrastructure follows your conventions.
Build the tools as MCP. Write new tools with FastMCP (clear docstrings!), or wrap existing Lambdas/APIs through AgentCore Gateway. Register them so the agent can discover them.
Author the agent. Implement the orchestration in your framework of choice — Strands is the natural fit on AWS — following Kiro's task list.
Deploy on AgentCore. Ship the agent to Runtime (container or zip), attach Memory, Gateway tools, and Identity.
Observe and iterate. Watch traces and token usage in CloudWatch; feed what you learn back into the spec — not ad-hoc patches.

The reference pattern AWS demoed at re:Invent makes it concrete: a multi-agent food tracker with a user-facing agent, an orchestrator coordinating between MCP servers, and two MCP servers handling recipes and nutrition data — specced in Kiro, exposed over MCP, and run on AgentCore. The "Kiro → Strands → AgentCore" path (Kiro to scaffold from a spec, Strands to author, AgentCore to operate) is now a documented AWS starting point.

⚠️ Don't skip the guardrails. A specced, deployed agent is still an agent with tools and credentials. Scope each tool to least privilege, use AgentCore Identity and Policy to govern what it can call, and keep a human gate on destructive actions — the same controls we argued for in Least Privilege for AI Agents and saw vindicated by Claude Mythos. Spec-driven doesn't mean risk-free.

Why this combination wins

Each piece removes a different bottleneck. Kiro removes the ambiguity bottleneck — the spec is the source of truth, so the agent isn't guessing what you meant and you have something to verify against. MCP removes the integration bottleneck — tools are standardized and reusable, and existing backends don't need rewriting. AgentCore removes the production bottleneck — isolation, memory, identity, and observability come from the platform instead of being hand-built. Together they turn "weeks of plumbing" into "days of building," which is exactly what those AWS timelines reflect.

The bottom line

Spec-driven development with Kiro, tools over MCP, and deployment on AgentCore is the most coherent path AWS offers for building production agents in 2026: define the work precisely, expose capabilities through a standard protocol, and run on a platform that handles the hard operational parts. Start with the spec, keep the guardrails on, and let the platform carry the undifferentiated weight. The skills underneath — cloud architecture, IAM, IaC, and secure design — are the same ones our certification labs teach, and they're what separate an agent demo from an agent in production.

Sources

← Back to all posts