Kiro IDE 1.0: Agent Focus Mode, Custom Agents, and the Permission System That Audits Every Tool Call

AI coding tools have spent two years competing on autocomplete quality and context-window size. Kiro has always bet on something different: structure first, then generation. Today, June 25, 2026, that bet reaches 1.0. Six major features shipped simultaneously — Agent Focus Mode, custom agents defined in Markdown, Natural Language Hooks, a mandatory capability-based permission system, dockable chat tabs, and mid-session agent switching. None of them are incremental quality improvements. They are architectural bets about what the next year of agentic development will look like.

This post walks through each feature with the concrete detail you need to decide whether and how to adopt it — config formats, behavioral guarantees, and the sharp edges that are not yet resolved.

What 1.0 actually means

Kiro has been in preview since its launch as AWS's replacement for Amazon Q Developer. The "1.0" label is not just marketing — it signals a commitment to backward compatibility for the agent file format, the hooks schema, and the permissions model. If you build a custom agent today, Kiro's team is now committed to not breaking it without a versioned migration path.

The deeper signal is the permissions system. In preview, Kiro had a trust dial — a global setting that let agents run freely or paused for approval on every action. 1.0 replaces that with a structured model: every tool call is evaluated against declared rules, and undeclared actions surface a consent prompt. There is no more --trust-all-tools. This is a deliberate break from the preview API, justified by the move to stable.

Agent Focus Mode

Agent Focus Mode is described by the Kiro team as "a chat-first layout designed for developers who spend their day guiding agents." The practical shift: instead of opening a chat panel alongside your code editor, you open a full-width chat view with your active agent sessions in a sidebar. Each session shows its current status, the files it has touched, and an inline diff of recent changes.

The design assumption is that your primary job is directing agents, not editing files directly. You can launch parallel sessions — one implementing a feature, one writing tests — and watch them proceed without switching editor tabs. When either agent surfaces a decision point, you respond in chat and it continues.

The mode also adds mid-session agent switching: you can swap which agent is handling your current session without losing conversation history. In practice this means you can start a task with a general agent, realize it needs a specialized one, and hand off without starting over. The conversation context carries.

Custom agents in Markdown

The most immediately actionable 1.0 feature for teams is the custom agent format. A custom agent is a Markdown file that declares its identity, tool access, and instructions. You drop it in .kiro/agents/ and it appears in the agent selector.

---
name: test-writer
description: Writes idiomatic Vitest unit tests for a given module.
tools:
  - read
  - write
  - shell
---

You write tests, only tests. You do not edit production code.
Given a file path, you:
1. Read the module and its public interface
2. Write a complete test file in the same directory
3. Run the tests with `pnpm test --filter <filename>`
4. Report pass/fail with the test output

Stop when all tests pass. Do not add comments explaining what the
tests do — the test names should be self-documenting.

The four tool-access tags control what the agent can do: read grants file read access, write grants file write access, shell grants command execution, and web grants network fetch access. Tags are enforced by the permission system — if an agent attempts a capability it has not declared, the user gets a consent prompt.

You can also declare inline MCP server connections directly in the agent file, so a specialized agent can have its own tool surface without polluting the global MCP config:

---
name: db-migrator
description: Plans and executes database migrations with rollback plans.
tools:
  - read
  - shell
mcp:
  - server: postgres-mcp
    command: npx @skills-hub-ai/postgres-mcp
    env:
      DATABASE_URL: ${env:DATABASE_URL}
---

You manage database migrations. Before executing any migration,
produce a rollback plan. Run the migration, verify it with a
SELECT against the affected tables, then report the before/after
schema diff.

Custom agents are plain files, so they version-control cleanly and can be shared across a team. The Kiro team's intention is that teams build a library of specialized agents — one per recurring task type — rather than prompting a general agent differently each time.

Natural Language Hooks

Hooks in Kiro fire at lifecycle events: before a file write, after a shell command, when a session starts. In preview, you wrote them directly in the structured JSON format — verbose, but explicit. In 1.0, you can describe what you want in plain English and Kiro generates the hook JSON for you.

When an agent writes to any file in src/api/, run pnpm lint --filter
that file and surface the result before the write completes. If lint
fails with errors (not warnings), block the write and show me the
errors.

Kiro generates:

{
  "version": "1",
  "hooks": [
    {
      "id": "api-lint-guard",
      "trigger": "PreToolUse",
      "match": { "tool": "write", "path": "src/api/**" },
      "action": {
        "type": "shell",
        "command": "pnpm lint --filter {{tool.path}}",
        "on_fail": "block",
        "expose_output": true
      }
    }
  ]
}

The generated JSON is editable — you own the file after generation. The natural language interface is a starting point, not the only interface. For teams who want deterministic, auditable hooks, the JSON format is still first-class. For teams who want to iterate quickly, the natural language path is now the fastest way in.

The permission system

The most significant architectural change in 1.0 is the permission system. Every file read, command execution, and MCP call is evaluated against your declared rules before it runs. If no rule matches, the user gets a consent prompt. The previous trust dial — which could be set to "trust everything" — is gone.

Rules live in .kiro/permissions.yaml:

version: "1"
rules:
  # Allow reading anything in the project
  - capability: read
    path: "**"
    action: allow

  # Allow writing to src/ and tests/
  - capability: write
    path: "{src,tests}/**"
    action: allow

  # Require approval for writes outside src/ and tests/
  - capability: write
    path: "**"
    action: prompt

  # Allow running the test suite and the linter
  - capability: shell
    command: "pnpm {test,lint,build}*"
    action: allow

  # Block all outbound network by default
  - capability: web
    action: deny

Rules are evaluated top-to-bottom; the first match wins. This is the same model used by firewall rulesets and most capability-based permission systems — the ordering matters, and more specific rules belong above more general ones.

The practical impact for teams is twofold. First, you now have an auditable record of what your agents are permitted to do — the permissions.yaml file is the source of truth, and it lives in version control. Second, you can scope individual custom agents more tightly than the global config by declaring per-agent rules in the agent file's frontmatter. An agent that only needs to read files gets only read access, even if the global config would allow more.

The system is a meaningful step toward agentic workflows that security and compliance teams can approve. Whether that matters to your team today depends on your threat model, but the direction is right: agents with well-defined blast radii are easier to trust with larger tasks.

Kiro skills on skills-hub.ai

Kiro's custom agent format is new as of today, so the ecosystem is still forming. On skills-hub.ai/kiro-skills you'll find skills tagged for Kiro — most of them usable as the instruction body for a custom agent file. The pattern is straightforward: install a skill, copy its instructions into your agent's Markdown body, and declare the tool tags it needs.

# Find Kiro-compatible skills
npx @skills-hub-ai/cli search --platform kiro

# Install a skill and inspect it
npx @skills-hub-ai/cli install kiro-custom-agent
cat ~/.skills-hub/kiro-custom-agent/SKILL.md

The most useful skills for Kiro's custom agent format right now are in the integration category — they tend to be self-contained enough to run inside a constrained tool surface. Skills that require broad file access or unrestricted shell access are better run in a general agent context rather than a scoped custom agent.

As Kiro's ecosystem matures, expect to see composition skills published directly as agent files — a single install that wires an entire workflow: spec writer, implementer, test writer, and reviewer, each as a separate agent, each with its own tool surface. That is the direction that Claude Code's subagent model has been moving, and Kiro's custom agent format now makes the same pattern available in an IDE context.

Kiro 1.0 is available today via the VS Code extension and the standalone desktop download. The CLI V3 early access (opt in with kiro-cli --v3) brings the same spec-driven and permissions model to the terminal. Both will update automatically as the 1.x series continues.