> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kanaeru.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# The learning loop

> How a retrospective turns into learnings, who approves them, and how they reach Kana's later sessions.

Every outcome ends with a retrospective. What the retrospective finds is saved as **learnings**, and active learnings are given to Kana's later sessions so the next outcome starts from what the last one taught her.

```mermaid theme={null}
%%{init: {"theme":"base","themeVariables":{"fontFamily":"Inter, ui-sans-serif, system-ui, sans-serif","fontSize":"16px","primaryColor":"#FFF1E0","primaryBorderColor":"#A94604","primaryTextColor":"#3B1A02","secondaryColor":"#FFE4C2","tertiaryColor":"#FFF8F0","lineColor":"#A94604","clusterBkg":"#FFF8F0","clusterBorder":"#E8B98A","edgeLabelBackground":"#FFFFFF","git0":"#A94604","git1":"#FF9F0A","git2":"#D97706","git3":"#B45309","gitBranchLabel0":"#FFFFFF","gitBranchLabel1":"#3B1A02","gitBranchLabel2":"#FFFFFF","commitLabelColor":"#3B1A02","commitLabelBackground":"#FFF1E0"}}}%%
flowchart TD
  D[Delivery PR merged] -->|you: Start retrospective| R[Retrospective session<br/>metrics, cost, drift, Kana's Assessment]
  R --> F[Your feedback]
  F -->|you: Accept delivery| L[Outcome learnings]
  L -->|Kana promotes| W[Workspace learnings]
  W -->|Kana promotes| C{Company-wide?}
  C -->|Pending review| A[Owner or admin<br/>approves or dismisses]
  C -->|Active| S[Later sessions]
  A -->|approved| S
```

## The retrospective

When the delivery pull request has merged and every task is done, cancelled, or deferred, choose **Start retrospective**. Only a person can start it; Kana and Koa can't. Kanaeru then opens a Retrospective session, and Kana works through the cycle on her own.

The **Retrospective** panel in the **Execution** tab shows what she finds:

| Part | What it shows |
| - | - |
| Metrics | **Duration**, **Tasks**, **Pipeline Steps**, **Commits**, **Messages**, **Est. Cost**, **UGs**, and **Evidence** |
| **Kana's Assessment** | Her findings, grouped as **What Worked**, **Challenges**, **Learnings**, and **Action Items** |
| **User Feedback** | Your own items in the same four groups. Pick a group, type your item, and send it |

Kana also scores **spec drift**, how far what was built moved from the blueprints you approved. A blocking drift verdict has to be acknowledged by a person before the outcome can complete.

## Closing the retrospective

While Kana is still working, the button in **Evidence & trust** reads **Retrospective still running**. When she's done, choose **Accept delivery and complete outcome**.

The outcome completes only when the retrospective has at least one feedback item. Kana records her own during the session, so this is normally already true. Adding your own feedback is what earns **Complete a retrospective** toward your [level](/concepts/levels).

Completing the outcome also saves its retrospective as learnings. If that fails, the outcome stays in its retrospective and you see **The retrospective findings could not be saved to the experience bank**. Feedback you add after completion is still saved as learnings, within about a minute.

## Applying a finding

Each **Challenges**, **Learnings**, and **Action Items** finding in the Retrospective panel, Kana's and your own, has an **Apply to roadmap** button. Applying a finding drafts a roadmap item from it, labeled **From retrospective**, and the finding then shows **Applied** with **View in roadmap**. The item stays proposed until you approve or reject it under **Review auto-suggestions** on the **Roadmap** tab. Applying the same finding again opens the same item.

Applying a finding after you've completed a retrospective earns **Apply a retrospective finding**, one of the goals for reaching Autonomy. Editing the vision's title or description after a retrospective still counts too. Either way it's credited once per vision.

## Learnings

A learning is one lesson, such as a recurring failure and how to avoid it. Each learning has a scope:

| Scope | Comes from | Applies to |
| - | - | - |
| **Outcome** | The retrospective and the outcome's execution logs | That outcome |
| **Workspace** | Kana promoting lessons that hold across the workspace's outcomes | Every outcome in the workspace |
| **Company** | Kana promoting lessons that hold across workspaces | Every workspace in your organization |

And a status:

| Status | Meaning |
| - | - |
| **Pending review** | A proposed company-wide learning, waiting for an owner or admin |
| **Active** | In use. Only active learnings reach Kana's sessions |
| **Resolved** | The problem it describes is fixed. It becomes active again if the problem comes back |
| **Dismissed** | Retired. Kana no longer uses it |
| **Withdrawn** | Dismissed while it was still pending review |

Outcome and workspace learnings are active as soon as Kana saves them. A company-wide learning waits as **Pending review**, because it would reach every workspace, unless it's backed only by evidence observed in execution logs, which Kana admits on her own.

## Approving company-wide learnings

Owners and admins review them in **Agent Memory** (see [below](#seeing-what-kana-has-learned)) under **Pending review**. Open a learning to read its evidence, then **Approve** or **Dismiss** it with a reason. If it changed while you had it open, you're shown the latest version to review again. The same works from the terminal:

```bash theme={null}
kana memory learnings list
kana memory learnings get <id>
kana memory learnings approve <id> --revision <hash> --reason "Matches our API style guide" --yes
kana memory learnings dismiss <id> --revision <hash> --reason "Only true for the legacy importer" --yes
```

`--revision` is the hash from `learnings get`, so you decide on the version you read. Approving a learning makes it active and marks it as **Human guidance**. Dismissing one retires it together with every learning that shares its key, at every scope. See [`kana memory`](/cli/reference#kana-memory).

## How learnings reach Kana

Kana doesn't read every learning in every session. Each kind of session gets the active learnings that fit its work:

| Session | Learnings it gets |
| - | - |
| Task Execution | The outcome's, and company-wide ones |
| Planning | The workspace's, and company-wide ones |
| Review | The outcome's, the workspace's, and company-wide lessons about what fails |
| Vision & Roadmap, Refinement | The workspace's, and company-wide ones |
| Retrospective | None. It reads and writes learnings itself |
| Koa | None |

A session gets at most 10 learnings, most costly first. They're added to Kana's instructions for the session. On Claude Code they're also restored when a session starts, resumes, or compacts its context. Sessions that get company-wide learnings also get your [company notes](#seeing-what-kana-has-learned), outside that limit.

## Seeing what Kana has learned

Open a workspace's **…** menu → **Settings** → **Agent Memory**:

* **Pending review** (owners and admins only) lists proposed company-wide learnings to approve or dismiss.
* **Saved learnings** lists the workspace's learnings and the company-wide ones it inherits, with each one's scope, status, and source (**Observed**, **Agent proposal**, or **Human guidance**). Owners and admins can change a workspace or outcome learning here (see below).
* **Company notes** are key/value notes for your organization, such as your API style or naming rules. Kana's Planning, Task Execution, Review, Vision & Roadmap, and Refinement sessions read up to 20 of them as company guidance, alongside their learnings. Only owners and admins can add, edit, or delete them. A note written by an agent isn't read until an owner or admin saves it.

From the terminal:

```bash theme={null}
kana memory patterns --workspace <id>
kana memory get
```

You can't delete a learning, but owners and admins can take one out of use, each time with a reason:

* On a workspace or outcome learning in **Saved learnings**: **Resolve** it when the problem is fixed (it comes back if the problem recurs), **Dismiss** it when the advice is wrong, or **Reactivate** a resolved one. Each changes only that learning.
* On a company-wide learning, **Dismiss** retires it together with every learning that shares its key, at every scope.

```bash theme={null}
kana memory patterns resolve <id> --reason "Fixed by the new retry wrapper" --yes
kana memory patterns dismiss <id> --reason "Doesn't apply to this repository" --yes
kana memory patterns reactivate <id> --reason "The flaky test is back" --yes
```

## From retrospective to roadmap

During the retrospective, Kana also files each **Challenges** and **Action Items** finding as a refinement signal for the workspace. Signals don't change the roadmap on their own. To turn them into roadmap suggestions, create an [automation](/guides/automations) with the **Signal refinement pass** session. Once a workspace has at least three open signals, a run drafts roadmap items labeled **Auto-refinement loop**. Find them with **Review auto-suggestions** on the **Roadmap** tab. They stay proposed until you accept them.


## Related topics

- [Kanaeru overview](/index.md)
- [Settings and profile](/guides/settings.md)
- [How Kanaeru works](/concepts/how-kanaeru-works.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.