# What to save

Save the things that would change the next decision. A useful memory says what happened, why it matters and where you learned it. It should make sense without the chat that produced it.

## Start with the things you keep repeating {#examples}

<dl class="example-list"><dt>A decision</dt><dd>“We kept the existing billing provider because the replacement failed our refund test. The review and test results are linked.”</dd><dt>A correction</dt><dd>“The earlier release checklist is no longer current. The data owner must approve the totals before release, following the latest review.”</dd><dt>A lesson</dt><dd>“This integration drops empty fields. Check that case before reusing it.”</dd><dt>A rejected option</dt><dd>“We tried a shared queue. It created delays for urgent work, so we kept separate queues.”</dd><dt>A handoff</dt><dd>“The migration is tested locally. Production approval is still open. Here are the checks and the remaining risk.”</dd></dl>

Those are examples of the shape, not facts to save about your company. Use your own evidence. Don’t turn a suggestion into an approved decision.

## Keep the source with the memory {#sources}

Include a link to the review, issue, document or test that supports the statement. Name the person who made the decision when that is known and appropriate to share. If the agent inferred something, say it is an inference.

A meeting transcript is useful evidence, but every sentence in it is not a decision. Someone may be proposing an option, asking a question or quoting somebody else. Ask your assistant to separate those before it saves anything.

```
Read these meeting notes. Propose the decisions and lessons worth saving.
For each one, include the source and say whether it was agreed,
suggested or inferred. Let me review the list before you capture it.
```

## What a capture contains {#required}

Your assistant fills in the fields when you speak normally. If you’re building an integration, `agent_capture` needs five fields: `content`, `thought_type`, `source_agent`, `source_phase` and `importance`.

```
{
  "content": "Example: require the data owner to check totals before release. The previous release had mismatched totals.",
  "thought_type": "decision",
  "source_agent": "project-assistant",
  "source_phase": "review",
  "importance": 0.7,
  "confidence": 0.9,
  "scope": ["onboarding.demo"],
  "evidence": ["Onboarding exercise, not a live company policy"],
  "metadata": { "example": true }
}
```

`source_agent` identifies the agent making the capture. `source_phase` says what kind of work was happening, such as research, design, build or review. Neither field should be used to pretend an agent is the person who approved the decision.

## Choose the kind of memory {#types}

The type helps describe what you are keeping. Use the closest fit; don’t spend longer classifying it than understanding it.

<div class="table-scroll"><table><thead><tr><th>Type</th><th>Use it for</th></tr></thead><tbody><tr><td>decision</td><td>A choice that was made, including its reason.</td></tr><tr><td>correction</td><td>A statement that fixes or replaces an earlier one.</td></tr><tr><td>lesson</td><td>Something learned through doing the work.</td></tr><tr><td>preference</td><td>How a person or team wants work done.</td></tr><tr><td>rejection</td><td>An option deliberately ruled out, and why.</td></tr><tr><td>handoff</td><td>What the next person or agent needs to continue.</td></tr><tr><td>pattern</td><td>A repeated behavior supported by examples.</td></tr><tr><td>drift</td><td>A gap between what was intended and what is happening.</td></tr><tr><td>insight</td><td>A useful interpretation, with its evidence and uncertainty.</td></tr><tr><td>reflection</td><td>A considered review of what happened.</td></tr><tr><td>seed</td><td>Initial context brought in to get started.</td></tr></tbody></table></div>

## Importance is not confidence {#importance}

**Importance** says how much the memory should matter when it is relevant. **Confidence** says how certain the statement is. A serious risk can be important even when the evidence is incomplete.

Both use values from 0 to 1. Don’t set everything to 1: that removes the distinction. Explain uncertainty in the words as well, so the next agent can see what still needs checking.

## Give it a useful home {#scope}

A scope is a dotted filing path such as `billing.refunds` or `website.content`. It lets you narrow a search to the relevant project without stuffing the project name into every sentence.

Each part can contain ASCII letters, numbers, underscores and hyphens. Use dots between parts, not spaces or slashes. This restriction applies to the scope, not the language of the memory.

Scopes organize the material. They are not access-control boundaries. If two groups must not read each other’s material, configure separate authorized workspaces rather than relying on different scope names.

## Bring in work you already have {#imports}

Use `korium_hydrate` to import a prepared batch of memories. Review what the assistant extracts from documents or transcripts before sending the batch. Keep the source and the distinction between a fact, an opinion and a decision.

Imports count toward total storage room rather than the monthly capture allowance. A batch that will not fit is refused as a whole. Free and paid plans have different import entitlements; check the current plan before starting a large import.

Connecting Korium does not automatically import your Teams / Zoom / Meet history or your Miro / Atlassian / Figma work. Bring in material you are allowed to use through an import, a connected assistant or an integration.

## What to leave out {#leave-out}

Don’t save passwords, API keys, refresh tokens or private customer details that the future work does not need. Don’t save a full transcript just because it is available. Keep the useful knowledge and enough evidence to verify it.

Don’t force every task to produce a memory. “Nothing durable changed” is a valid outcome. A noisy memory makes the next person’s job harder.