The model is the fulcrum;
the harness is the lever

Context: the only resource you truly manage

The loop is ready-made; what you manage is what content goes in and when to clean it up — and this floor largely determines how far Kiro can go. Note that the three ways of using it — IDE, CLI, ACP — diverge sharply on this floor: the CLI has a full set of slash commands (/compact, /rewind, /tangent), the IDE uses panel buttons and # references, and ACP carries the CLI's capabilities into third-party editors over a protocol (detailed in the next section).

After the model completes a step, you have several choices. The easiest is "continue," but the other options exist precisely to help you manage context quality.

First, clear up something easy to confuse. Kiro has three ways to use it: IDE, CLI, ACP. ACP is not a third standalone product but a mode of the CLI: you run kiro-cli acp, and underneath it's still the CLI's agent core — it just communicates over an open protocol (JSON-RPC), so you can call Kiro from the AI panels of third-party editors like JetBrains, Zed, and Neovim. So ACP's capabilities are essentially a subset of the CLI's: terminal-only interactive commands (rewind's turn selector, tangent's toggle) aren't available, and the IDE's GUI-only features (the checkpoint panel, the Spec panel) certainly aren't.

The table below lays out, for each context action, whether it exists in each of the three modes, how to use it, and when. A few names are especially easy to misread (rewind doesn't revert files, clear only clears the display), and those are marked:

✓* = a Kiro extension to ACP, experimental, and only effective if the host editor implements the _kiro.dev/ extensions; without it, it degrades to plain standard ACP (only sessions, models, streaming). ✗ the mode lacks this action, — not listed as supported by the docs, △ experimental, must be enabled manually.

The IDE side has no slash commands overall; the equivalents are panel buttons: Summarization (the counterpart to /compact), the checkpoint panel's Restore (roll back code + context), Revert (undo only the most recent turn's changes), and # context references.

Compaction is fundamentally lossy compression: as you near the window limit, the whole conversation is summarized into a more concise description, and the model continues from the summary in a new context. CLI triggers it manually with /compact, and it also fires automatically when context overflows; the two tunable settings are keeping the most recent 2 message pairs by default and keeping 2% of the context window by default, taking whichever is more conservative. A Kiro-specific detail: after a compact, a new session is created rather than the original being compressed in place, and you can recover the original with /chat resume. The IDE equivalent is the Summarization feature, with the same logic.

The first thing to watch: at the moment auto-compact fires, the model happens to be at its least intelligent because of context rot, yet it has to make the most critical "keep what, discard what" decision. A typical failure chain: after a long debug session, auto-compact fires and the summary focuses on the debugging; then you say "now go fix that warning in the other file," but the warning's details have already been dropped. The right approach is proactive management: compact manually with /compact ahead of time, while you know your next step and the model is still in good shape.

Kiro has an easily-confused design around "rolling back": it splits "roll back the conversation" and "roll back files" into two independent mechanisms, and one command can't do both at once.

The CLI docs explicitly split "supplying context to the conversation" into four categories, chosen by "whether it occupies resident tokens":

A rule of thumb: new task = new session. Having just finished implementing a feature and about to write its docs, you should consider starting a new session (CLI uses /chat new — again, not /clear). There's a trade-off between related tasks: reusing context is faster and cheaper, since the model doesn't have to re-read the files you just changed; a new session is cleaner but has to re-read the relevant files, which is slower and costs more credits. The decision rule: if the next task is highly related to the current context, continue; otherwise start a new session.

CLI /knowledge (experimental) can turn a large file, an entire document library, or even a whole codebase into a semantic-search knowledge base: it occupies context only when a search hits it, and consumes no tokens otherwise. The docs' threshold is clear: once content exceeds about 10MB or thousands of files, it shouldn't go into resident context — use a Knowledge Base instead. It's an optional persistent semantic index layer that, in large-codebase scenarios, saves a lot of "have the agent read files one by one" overhead. The trade-offs: it's experimental with limited stability, plus the indexing performance bottleneck on very large codebases (see 2.3).

Knowledge & tools: the blueprint

This floor is the guide's core framework. An often-overlooked premise: the harness matters as much as, or more than, the model itself. Teams fixate on benchmarks, but in actual use, results depend more on the ecosystem you build around the model. This floor has one thing going for it: most of Kiro's Steering / Skills / Hooks / MCP is shared between IDE and CLI — configure it once and both sides can use it.

A common misconception is that an agent finds code purely by traversing files live, with no index. Kiro doesn't work that way — it's a hybrid of three coexisting mechanisms, which is the easiest thing to get wrong by assumption:

Worth emphasizing: symbol-level and structure-level code understanding (which in many tools requires manually installing an LSP) is something Kiro has built into the product (the CLI's tree-sitter code tool, the IDE's index and AST editing). So in Kiro this isn't scaffolding "you have to build" but an existing capability you just need to "understand is already there."

Building the harness has an order; each layer rests on the previous one, and you shouldn't skip. Kiro's version is Steering → Hooks → Skills → Powers → code intelligence → MCP → Subagents. Each layer comes with its "common mistake" and "which line it belongs to":

The core constraint: a model's capability ceiling in a large codebase equals its ability to find the right context. A few recurring practices: keep Steering lean and mode-segmented (don't set everything to always-load); scope test and lint by subdirectory; exclude generated files with .gitignore and protected paths; when the structure is unclear, have Kiro generate a codebase map (IDE uses #repository, and for an existing codebase you can first generate structure.md / tech.md / product.md); have the model use tree-sitter symbol search rather than pure string grep; and use a Knowledge Base for large codebases rather than loading everything.

Steering files live in .kiro/steering/ (workspace level) or ~/.kiro/steering/ (global level); on conflict, the workspace wins. Each .md loads automatically, split by domain. In the IDE, clicking "Generate Steering Docs" produces three base files — product / tech / structure — on which Kiro's basic understanding of the project is built. Steering is more flexible than a single project doc loaded in full from start to finish, and that flexibility comes from these four inclusion modes (written in the YAML front-matter at the very top of the file):

fileMatch is the key: Kiro's steering files are flat (all in one directory), and when they load is decided by the inclusion mode, not by which directory the file sits in. To get "rules specific to a certain subdirectory," write a fileMatch glob that matches those files, rather than placing the rule file inside that subdirectory. Additional notes: #[[file:relative-path]] links a live workspace file into steering (some reports say this syntax occasionally doesn't work on the CLI but is fine in the IDE); AGENTS.md is supported but doesn't support inclusion modes and always loads in full; and on the CLI, when using a custom agent, steering doesn't load automatically — you must add it explicitly in the agent config's resources field.

Kiro's Skills use exactly the open Agent Skills standard, so mature community skill know-how and ready-made skill packages are largely reusable here as-is. The structure is identical:

Locations: workspace .kiro/skills/, global ~/.kiro/skills/, with the workspace winning on name conflict. Both name (must match the folder name) and description (used by Kiro for semantic matching) are required. Progressive disclosure works the same way: at startup only name+description load, and the full SKILL.md loads only when a request matches. The familiar best practices apply directly: don't pile on filler, add a Gotchas section to record failure points, use the file system for progressive disclosure, and write the description as trigger conditions rather than a summary.

This is the layer where IDE and CLI diverge the most, so they have to be covered separately.

MCP integration is configured in .kiro/settings/mcp.json (workspace level) or at the user level; the two merge, with the workspace winning. It's the standard mcpServers format — local servers use command/args/env, remote ones use url/headers. A few things Kiro adds here: finer-grained auto-approval (autoApprove / disabledTools / disabled); the MCP Registry (CLI, where an organization centrally pushes servers, and registry defaults can be overridden locally key by key — suited to enterprise control); and one-click install links ("Add to Kiro" placed in a README). One thing to note: the Web Kiro Web sandbox currently supports only local stdio servers, not remote ones.

Cost-reduction mechanism: Kiro has Tool Search, which, when there are many tools, doesn't preload all tool definitions but searches and pulls them at runtime on demand. It's off by default on the CLI; the trigger threshold is 5% of context or 50,000 tokens, and turning it on is recommended once you have more than 5 MCP servers. Powers, meanwhile, bundles "MCP tools + knowledge + workflows" into one package activated dynamically by context: MCP provides the tools, Skills provide the operational knowledge, and Powers provide the combined "tools plus knowledge" volume.

One principle runs through this floor: more tools and more instructions are not better. Tool schemas and overly long instructions both crowd out the space the model uses for reasoning. A short steering doc and a focused skill often beat piling on redundant configuration. Because Kiro bills by credit, this also has a direct cost implication: every extra piece of resident context is something you pay for on every request. The default leaning should be "verify with the minimum configuration whether the model can handle it, then add incrementally based on the problems you actually hit." This undercurrent is tied off in the closing section, "build it up, then cut it back."

Orchestration: who should hold the plan

At this floor the question becomes: for a given task, do you let the model keep the whole plan in its head turn by turn, or hand the plan off to be held elsewhere? Orchestration comes down to one question: who holds the plan. The most naive approach is to have the model keep the plan in context and proceed turn by turn, but once a task grows large, the plan tends to drift and distort under compaction.

Kiro's answer is distinctive: persist the plan to disk as spec files, have a human review them, then let the agent implement against them. The plan is no longer held in the model's context turn by turn but becomes three markdown files on disk that can be version-controlled and reviewed by the team. This is Kiro's signature capability, Spec-driven development, and it is IDE-exclusive (the CLI has no built-in spec, only a lightweight Plan agent, see 3.7). What this buys you is that the plan is readable, reviewable, and traceable: think it through at the document level and have a human confirm it before writing any code — especially suited to complex, high-regression-cost development that needs team alignment.

Each spec generates three files, placed under .kiro/specs/<feature>/, one directory per feature:

Two workflow variants plus a quick mode: Requirements-First (variant; behavior is clear, architecture is flexible) · Design-First (variant; an architecture already exists, or you must meet hard non-functional requirements like latency/compliance) · Quick Plan (a separate session mode, not strictly a variant: auto-generate all three files at once, skipping the inter-stage approvals — suited to mature features where you trust Kiro's output). The default has approval gates: Requirements → (human review) → Design → (human review) → Tasks, and before entering design there's an Analyze Requirements step that helps you catch contradictions, ambiguities, and gaps in the requirements. Note the division of labor: a spec covers only a single feature's plan; project-level resident context goes through steering, and the two are kept separate.

tasks.md has a dedicated execution view that shows each task's status in real time. Run all Tasks: Kiro automatically builds a task dependency graph and groups the dependency-free tasks into "waves" — the first wave runs all dependency-free tasks concurrently, the second runs those whose dependencies the first wave satisfied, and so on — serial between waves, concurrent within a wave. Sync Files: when triggered, has Kiro scan the codebase and automatically mark completed tasks, handling the case where "you or a teammate already did part of it in another session." Beyond running everything at once, you can also execute tasks one at a time (the Start Task link above a task), reviewing each before moving to the next — handy if you like "one task, one review."

Subagents exist in both the IDE and the CLI; only the granularity of control differs. They are a different thing from the wave-based parallelism of spec tasks (3.3): that is parallelism at the task-orchestration layer, while a subagent spins up a child agent with its own isolated context window to run a stretch on its own. In common: the subagent gets its own fresh window, the main agent decides whether to delegate, and when it finishes the result rolls back to the main agent, keeping the intermediate noise in the isolated context. The two lines differ as follows:

Where it fits (both lines): research-intensive tasks (read dozens of files and return a summary), multiple mutually independent subtasks (run in parallel), needing a fresh perspective (not inheriting the main session's assumptions), and an independent review before committing. The mental test: "Do I need these tool outputs themselves, or only the conclusion?" If only the conclusion, delegate.

One sentence to frame the boundary of Kiro's orchestration and avoid mismatched expectations. Kiro's orchestration is agent-driven and described in natural language; the holder of the plan is always the LLM main agent, not a deterministic script. Two concrete manifestations:

So Kiro's strength is: use a spec to persist a single feature's plan and get it reviewed clearly, then use subagents for limited parallel delegation and adversarial review. Understand this boundary and you won't expect it, when configuring, to do script-level, line-by-line replayable, large-scale deterministic orchestration.