How to Decide What Survives Kiro's Compaction (2026 Guide)

Kiro's own summary of the mechanism is straightforward. Compaction "keeps long sessions productive by automatically summarizing older conversation history as your session grows," and the framing is that "your goals, decisions, and technical progress are preserved - only the verbose middle gets compressed."

The sequence has three parts: "Kiro creates a structured summary capturing your goals, decisions, progress, and next steps," then "older conversation history is replaced by the summary, while your most recent messages are kept verbatim," then the session continues "from where you left off with no interruption."

That design is sensible, and the categories it picks are the right ones for continuing work. A summary that knows which files changed, which tests pass, what is left, and what your constraints are can absolutely keep going. Kiro's worked example makes the case well: after forty-five minutes of refactoring, the summary retains which files were modified, which tests pass, the two files remaining, and the constraint that "all changes must be backward-compatible."

The gap is a category difference, not a bug. A summary preserves conclusions efficiently and arguments badly. "All changes must be backward-compatible" survives as a constraint. The twenty minutes in which you established why backward compatibility was non-negotiable here — the caller nobody can update, the client on an old version, the migration that failed last year — is exactly what the table files under exploratory discussion and intermediate reasoning steps.

Two more entries in the compressible column deserve attention. "Error details from resolved issues" means the failures you already worked through get compressed — and a failure you worked through is usually the strongest evidence for the approach you settled on. "Code snippets in earlier messages" means the rejected implementation is gone while the accepted one remains, which removes the comparison that justified the choice.

Kiro's remedy for a missing detail is honest and revealing: "If the agent seems to have lost a specific detail from earlier in the session, restate it. The agent will incorporate it immediately." That works. It also means the retention mechanism for anything not in the preserved column is you, remembering to say it again — the loop we described in how to stop re-explaining context to your AI.

This is not a Kiro-specific design. Amazon Q Developer documents the same shape under a different name: after compaction, "Amazon Q uses the compacted summary (not the full history) for generating responses," and while the full conversation stays visible in the panel for the session, "the detailed chat history will reset when you restart your IDE." Two vendors, two independent implementations, same conclusion — the conversation is working memory, not storage.

Turning compaction off. Not available on most surfaces. Kiro's documentation states that compaction "is automatic in the IDE. There is no manual trigger," and repeats the same for Web and Mobile. Only the CLI exposes /compact, and that is a manual trigger, not a switch. The alternative to compaction is running out of context.

Tuning the retention settings. The CLI exposes two: compaction.excludeMessages, described as the "minimum number of recent message pairs to retain verbatim," and compaction.excludeContextWindowPercent, the "minimum percentage of the context window to keep as recent messages." Both default to a value of 2, and "both settings are evaluated, and the more conservative (larger) value wins."

Raising them keeps more of the recent tail verbatim, which genuinely helps with continuity. It does nothing for reasoning that happened an hour ago, because the tail is defined by recency, not importance. This is the general limit we set out in why a long context window is not memory.

Exporting the session. Kiro recommends this for the right reason: "If you need to preserve the complete history, export your session before compaction occurs." An export is a real safeguard against total loss. It is not a retrieval mechanism — a transcript is chronological, unindexed, and describes what was said rather than what is currently true. That distinction is the whole subject of what indexed session logs recall, and what they don't.

Starting a fresh session for each phase. Reasonable hygiene, and Kiro's CLI guidance suggests /compact "before starting a new phase of work within the same session." But a new session starts with steering files and no conversation, so anything you established last session and did not write down is gone by definition rather than by summarization.

Putting everything in steering. The over-correction. Kiro's steering files under .kiro/steering/ are always-on by default, and an AGENTS.md in the steering location cannot be scoped at all — the docs note that "AGENTS.md files do not support inclusion modes and are always included." Move your whole reasoning history there and you have converted a compaction problem into a context-budget problem, which is the trade-off examined in how much memory you should give an AI agent.

The table is the tool. Use it as a routing rule at the moment a fact appears, not as a post-mortem.

Step 1: Read the two columns as a routing spec

Take Kiro's table literally and apply it while you work. When something important gets established in a session, ask which column it falls into.

If it is task status, a modified path, a next step, or a stated requirement, leave it in the conversation. Kiro preserves those, and duplicating them elsewhere creates two records that will disagree.

If it is an argument, a rejected option, a resolved error that taught you something, or a code snippet you are comparing against — it is on the compressible list. That is your signal to write it somewhere else, now, while it is still verbatim.

The boundary case is "key decisions and constraints," which sits in the preserved column. The decision survives; its justification does not. So the routing rule for a decision is: leave the decision in the conversation, and write the justification out. A constraint with no recorded reason gets deleted by the next person who finds it inconvenient.

Step 2: Promote the reusable half into steering, and keep steering scoped

Some of what you write out belongs in Kiro's own configuration, because it will be true next session too.

Steering files live in .kiro/steering/ for workspace scope and ~/.kiro/steering/ for global, and they take an inclusion mode in front matter — with a documented constraint worth heeding: "The inclusion configuration must be the first content in the file - no blank lines or content before it." The three modes are always (the default), fileMatch with a fileMatchPattern, and manual.

Use them by lifespan. A convention that applies to the whole repository goes in an always file. A convention that applies to one area gets inclusion: fileMatch and a pattern, so it costs nothing when you are elsewhere. A long procedure you invoke occasionally gets manual.

What does not belong in steering is the running history of a project's decisions. Steering is loaded every session for every task; a decision log grows without bound. Kiro also documents that global steering is a per-machine directory — on Web, "Global steering" refers to your local ~/.kiro/steering/ directory, "which the cloud sandbox cannot read," and reusing it across cloud sessions requires uploading it through Configuration Sync. A file that lives on one laptop is not a team record.

Step 3: Give the reasons a home where no summary runs

The remainder — the rejected approaches, the reasons behind constraints, the facts a person supplied when the agent was stuck — has three properties that rule out both previous destinations. It grows continuously, so it cannot be always-on. It is queried rarely and specifically, so it should not be in every prompt. And it must be readable by the next session, the next person, and the next tool, so it cannot live in a transcript on one machine.

That is a store, not a file and not a conversation. It gets appended to when a decision is made and read when a decision is questioned, and nothing in it is subject to a summarization pass.

MemoryLake is that store: a shared layer that holds the reasoning your session compresses and your steering files should not carry. Kiro keeps the status; steering keeps the standing conventions; the layer keeps the arguments. Get started here.

Step 1: Create an API key

Create a workspace for the project and generate an API key. One workspace per project, not per session — the point is that it spans the sessions compaction resets.

Step 2: Upload your first memories

Do not start from scratch. Export a session that has already compacted and mine it for the compressible column: the approaches you tried and abandoned, the errors that changed your design, the constraints someone stated verbally. Add the reasons behind each steering file you already have, since those files state rules without stating why.

Step 3: Connect your AI & agents

Connect Kiro across the surfaces you actually use — the IDE and the CLI behave differently on compaction, and both should read the same set. If you run Kiro Crew for team workflows, connect those agents too, so a scheduled agent is not working from a narrower record than the person who set it up.

Long sessions stop being lossy in an invisible way. Compaction still fires, still on its own schedule, and the summary still keeps the status. But the argument behind each constraint is somewhere that does not summarize, so a compacted session is a smaller context rather than a shorter memory.

The restate loop shrinks. Kiro's advice to restate a lost detail is fine once. It is expensive when the same three facts get restated in every session for a month, and it is unreliable, because the person restating has to remember the fact was ever established.

Rejected approaches stop coming back. "Error details from resolved issues" is on the compressible list, which means the record of what did not work is the first thing to go. Write those down and an agent stops proposing the thing you eliminated on Tuesday.

Steering files stay small enough to be effective. When the decision log has its own home, steering can be a short set of standing conventions instead of an ever-growing document that consumes context on every request. The general argument for keeping the always-on layer lean is in how agent memory got more accurate by keeping less.

Write the reason at the moment it is spoken, not at the end of the session. By the end, the conversation may already have compacted, and Kiro's own warning applies: the history before the compaction point "is not recoverable within the session."

Export before long autonomous runs. It is cheap, Kiro recommends it, and it is the only thing standing between you and a summary you cannot audit.

Raise the CLI retention settings for continuity, not for retention. Increasing compaction.excludeMessages helps the agent stay coherent across a boundary. It is not storage, because the window it protects is defined by recency.

Use fileMatch steering more than always steering. Every always file competes for the same context on every request, and the ones that could have been scoped are pure overhead. Note also that an AGENTS.md in the steering location has no inclusion mode available to it.

Distinguish the decision from the constraint in what you write. "Do not use the shared retry helper in payments" is a constraint and survives compaction. "Because it retries on a failure path that double-charges" is the reason, does not survive, and is the only thing that will stop the constraint being deleted in six months.

If you keep a session log for your own reference, keep it separate from the store. A log is chronological and describes what was said. A store describes what is currently true. Mixing them means the newest contradiction sits next to the oldest claim with nothing to distinguish them — and if you later move tools, it is the store that ports cleanly, as we found in migrating from Kiro to Codex.

Kiro's compaction table is more useful than most vendor documentation because it tells you exactly what to plan around. Status, paths, decisions, next steps, and intent survive. Tool call details, exploratory discussion, intermediate reasoning steps, resolved error details, and earlier code snippets may not — and the operation is one-way.

The practical response is not to fight compaction. It is to stop using the conversation as the storage location for the second column. Decide in the moment which column a fact belongs to, promote the standing conventions into scoped steering files, and give the reasoning a home that no summarization pass touches. Then a compacted session is exactly what Kiro says it is: a smaller context, and nothing lost.