Memory

Every chat used to start from zero, apart from what you had written into steering. Memory changes that. Kiro can now notice something useful while it works, write it down, and recall it in a later session without being told again.

Kiro’s documentation uses a good example. While debugging, Kiro learns that a repository’s integration tests fail until the local database is seeded. With Memory on, a later session can seed the database first instead of rediscovering the cause.

What Memory is

Memory adds two steps to the context Kiro already uses:

• Learn from the work. As a session goes, the agent can identify something worth keeping and create or refine a memory.
• Recall when relevant. In a later session, Kiro can retrieve a matching memory while it works on your request.

What gets stored is the kind of thing you would otherwise repeat: repository conventions and commands, corrections you made, and approaches already ruled out. In the IDE most memories show the type Preference or Fact, and each one applies either globally or to one repository.

Memory Context Kiro learns from your work in one session and can recall in a later one. It sits alongside steering, session history, compaction summaries, and (in the CLI) knowledge bases. is one form of context among several, and it does not replace any of them.

Where it works

Surface	Status
Kiro IDE	Since 1.4 (19 October 2026). Off by default since 1.4.10
Kiro CLI	Since 2.29.0 (9 October 2026), local V3 sessions only
Kiro Web	Kiro’s Memory docs say support is coming soon

Kiro Web has a separate, older feature also called memory: it learns from the pull request feedback given by whoever created a task. That is covered on the Kiro Web page. Kiro Crew keeps its own memory too.

Turn it on in the IDE

1. Select the Memories icon in the activity bar to open the Memory view.
2. Select the settings gear. Settings opens on Kiro Agent: Memory.
3. Choose a level.

Level	What it does
Use and learn	Uses memories, changes them when you ask, and creates and refines them automatically
Use but don’t learn	Uses memories and changes them when you ask, but never on its own
Use only	Uses existing memories and never creates, updates, or deletes them, even when you ask
Off	Does not use or change memories. The default

Turning Memory on or off, or switching to or from Use only, applies to new sessions; the IDE offers a Start new session action. Switching between the two “Use” levels takes effect immediately. Memory is a user setting, so putting it in workspace settings does nothing.

The Memory view lists global memories and those for the repositories open in the window. You can search, filter by type or location, open a memory in a tab, and delete one (Kiro asks you to confirm). In chat, Kiro groups memory activity into entries such as Memory accessed (1) or Memory created (1), and recalled memories appear as their own row in Context Usage, after steering files.

Turn it on in the CLI

Memory in Kiro CLI needs V3, which becomes the default with CLI 3.0 at the end of October 2026 (see the CLI Guide). In a local V3 session:

1. Type /memories and select config.
2. Choose read & write, read only, or off. Access changes apply to your next session.
3. With read & write, choose whether to turn on Automatic memory updates, which lets Kiro “create and refine memories, including after a session ends”. That setting applies immediately.

Select list under /memories to search and preview what is stored. The list is read-only: to fix or delete a memory, ask Kiro in the chat. When Kiro uses a memory mid-turn, the chat shows a Memory entry with command=get and the memory’s title.

Trust and safety

In a workspace you have not trusted, Kiro can read memories but cannot add, change, or delete them from the chat, whatever level you chose. That stops a cloned repository from planting instructions that follow you into other projects.

Memories also cost context. A recalled memory is text the model reads, so it uses part of the window like steering does.

Memory or steering?

	Steering	Memory
Who writes it	You	Kiro, from your work
When it applies	Every time its inclusion rule matches	When Kiro judges it relevant
Where it lives	.kiro/steering/, committed with the code	Kiro’s memory store, per user
Shared with the team	Yes, through the repository	No
Good for	Rules, stack, structure, standards	Small facts you keep repeating

Kiro’s own advice is direct: if a rule must apply consistently, write it in steering. Memory is learned, so it can be incomplete or wrong, and nobody reviews it in a pull request.

Related

• Steering is the context you write yourself.
• Compact a long session covers the other way Kiro keeps context manageable.
• What’s New in Kiro tracks Memory as it reaches more surfaces.