# Save your first memory The first test is simple: tell one assistant something useful, start a fresh conversation and ask for it back. That proves you’re using Korium, rather than the conversation you already had open. ## Before you start {#before} You need a Korium account you can sign in to, plus an assistant with remote MCP support. MCP is the connection that lets an assistant call Korium’s tools. You can use memory without installing the code-indexing CLI. Open Korium sign-in and check that you can reach the right workspace. If your team invited you, use that invitation rather than creating a separate workspace. If you need an account, see the current account options.
Two separate connections

Your assistant signs in to the Korium MCP service. The Mac CLI has its own sign-in for code indexing and code search. Signing in to one does not sign in to the other.

## 1. Connect your assistant {#connect} Pick the guide for the assistant you actually use. Finish its browser sign-in and return to that assistant before moving on. The address is `https://api.kyroco.ai/mcp`. You should not need to copy a secret out of another client’s configuration. ## 2. Check that the tools are available {#check} Ask your assistant: ``` Show me the Korium tools you can use. Can you search memory and save a memory? ``` Look for tool names ending in `agent_search` and `agent_capture`. The name before that depends on the client and the name you gave the connection. If the capture tool is missing, the connection may only have read permission. That is a permission choice, not an empty memory. See [OAuth scopes](connect-any-mcp-client.html#scopes) before reconnecting. ## 3. Save something worth remembering {#save} Choose one real decision you would hate to explain again. Include the reason and where it came from. For a harmless first test, you can use this clearly labeled example: ``` Save this example in Korium under scope onboarding.demo: Before a release, the data owner checks the numbers. Reason: the previous release had mismatched totals. This is a demonstration, not an actual company policy. Record it as a decision from this onboarding exercise. ``` Ask the assistant to confirm the save succeeded and show the memory ID. “I’ll remember that” is not proof. If the tool refused the save, fix the refusal before continuing. For real work, replace the demonstration with your decision, its source and the person who approved it. Keep the entry understandable to someone who wasn’t there. ## 4. Start a fresh chat and find it {#recall} Open a new conversation with the same connected assistant. Don’t paste the earlier answer into it. Ask: ``` Search Korium under onboarding.demo. What needs to happen before a release, and why? Show the memory you used. ``` The answer should name the data owner’s check, explain the mismatched totals and identify the saved example. Check the source memory instead of accepting a plausible answer that never used a tool. You can repeat this in another assistant connected to the same Korium workspace. The shared workspace matters: two different accounts do not share memory just because both use Korium. ## What a successful save looks like {#receipt} Open the tool result, not just the assistant’s sentence. A capture acknowledgment includes a memory ID. This shortened example uses an invented ID: ``` { "queued": true, "thought_id": "11111111-1111-4111-8111-111111111111" } ``` `queued` means the capture was accepted for the remaining processing. It is not a promise that extraction or every search path has finished. Keep the ID so you can compare it with the `id` of the source thought returned by your search. Background processing can fold a duplicate into an existing memory and mark the new record no longer current. If the original ID disappears from current search, inspect its history and any replacement instead of assuming the save failed. The exercise is complete only when you can find the intended guidance and check its source. If the result says rejected, contains an error or has no successful capture receipt, do not move on as though it saved. If you have a receipt but the first search misses it, check the workspace and scope, then [check processing and retrieval](troubleshooting.html#processing) before saving duplicates. ## 5. Change the example and check the history {#correction} Now change the rule in the same demonstration. This checks something a normal chat history cannot prove: whether the next task can find a correction and the decision it replaced. ``` This is still the onboarding demonstration, not company policy. Find the release-check example under onboarding.demo. Change it so the data owner and release owner both approve the totals. Save the correction with this exercise as its source. Link the new memory as superseding the original, then show both IDs and verify the link. Do not invent a person's approval. ``` The assistant should show a new capture receipt and a successful replacement link, or explain exactly which step failed. If linking is separate from capture, the direction is new memory to old memory. [See the request and verification steps](working-with-memory.html#worked-correction). In a fresh chat, ask what the example requires now and why it changed. The answer should name both reviewers and identify the correction; tracing the history should still explain the original data-owner check. If the source still points only to the original, the exercise is not finished. ## 6. Use it on your next piece of work {#next} Before starting, ask Korium what is already known about that project. At the end, save the decisions, corrections or lessons that will change how someone works next time. You don’t need a transcript of every keystroke. Read [what to save](what-you-can-store.html) for examples, then [build the habit into your project instructions](make-it-automatic.html). If your work includes a codebase, [add the code index](indexing-your-code.html) after the memory connection works.