# What happens after you say “remember this”? A decision becomes a saved record. Background jobs make it searchable and connect it to what is already known. When the next task starts, the assistant can find the decision, check why it was made and use it in the work. ## On this page ## One system. Different jobs. Outside Korium / Your people and connected tools Meetings, documents and work produce something worth keeping. A connected assistant or integration sends the memory. Your accounts are not copied automatically. Authenticated MCP connection · workspace and permissions checked Inside Korium 01 **Save** `agent_capture` Content + type + scope + source + importance **Validate and accept** Check the request and account limits. A refusal is not a save. **Valkey staging + queue** Keep the new record and queue it for processing. Back to the caller: a memory ID and receipt. The agent can continue. 02 **Prepare the memory** **Background jobs** Split long inputs into linked pieces. Create embeddings and extract entities. **PostgreSQL record** Store the memory, search information, source fields and relationships. **Compare and connect** Where enabled, check related memories for duplication, support or conflict. This work is asynchronous. A new result can still be provisional. 03 **Find it when needed** `agent_search` A question + an optional scope filter **Keyword** Match the words **Vector** Match the meaning **Fuse → rank → connect** Combine the lists. Weigh importance and use. Follow relationships to the supporting sources. Answer the question: a count, a clarification or the exact passage, with source context and completeness information. Search reads staged and settled memory. It does not have to wait for the entire background pipeline. The assistant reads the sources and uses them in the task 04 **Put it to work** **Memory** What do we already know? **Code, when needed** Where is the implementation? **Skills** How should this task be done? **Workflow** Do the steps. Get the reviews. **Save the outcome, the correction and the reason.** They go back through capture for the next task. Capture, processing and recall run separately. The assistant does the work; Korium supplies the memory, the source trail and the answer to its recall question. ## 01 / Keep the decision and the reason together. Suppose a monthly report included canceled orders. The team fixes the report and agrees that the next one must check for them before it goes out. Saving “check the numbers” would lose the useful part. The memory needs the mistake, the decision, the reason and the source that supports it. The assistant calls `agent_capture` with that content, a memory type, the agent recording it, the work phase and an importance value. Scope, evidence and who actually approved the decision add context; an agent’s name is not proof of a person’s approval. The service validates the request, writes the new record to Valkey staging and places it on the processing queue. It returns an ID without waiting for extraction, embedding or conflict analysis. [See the receipt and try a first save →](docs/korium/getting-started.html#receipt) Illustration / Not a customer record ### Check canceled orders before sending the monthly report. Why The previous report counted canceled orders as revenue. Source The report review and the corrected query. Type Decision Scope `reporting.monthly` Approval Record the actual reviewer. Do not invent one. A useful memory explains a decision to someone who was not in the room. ## 02 / Do the expensive work after the save. A quick acknowledgment and a fully processed memory are different things. Background jobs turn the accepted record into something that can be found, compared and inspected later. 01 ### Make the meaning searchable. An embedding model turns the content into a vector, a numerical representation used to find similar meaning. The hot embedding job can add that vector to staging; before it arrives, keyword search can still find the new record. 02 ### Write the long-term record. The drain moves staged work into PostgreSQL. It can reuse an embedding already produced or create the one still needed, while preserving the memory’s original capture time. 03 ### Keep the useful passage connected to the whole meeting. A long transcript is kept as an original record with smaller pieces linked back to it. Extraction reads those pieces, so a person mentioned in one turn and a topic discussed in another can be connected through the same meeting. One saved transcript counts as one memory of storage room, however many pieces processing creates. A search can return the relevant passage with its source, without filling the page with the same meeting repeated. 04 ### Identify the people, topics and relationships. Entity extraction finds names and subjects in the text. A separate role pass identifies participants and topics; the graph keeps the evidence connecting those entities to the source passages. A name appearing in two places is not sufficient proof that it is the same person. Keep the source trail, and correct a mistaken connection rather than letting it become an unexplained fact. 05 ### Check how the new memory relates to earlier ones. Where the account’s processing features enable it, later jobs compare the new record with nearby memories. A duplicate can be folded into an existing record; a supporting claim or a correction can be linked to what came before. A successful save does not mean this analysis has finished, or that it got every judgment right. Keep the sources and inspect consequential corrections. “Saved,” “searchable” and “fully processed” are separate checks. A receipt proves acceptance; it does not certify the content or guarantee that the same record will remain current after duplicate processing. ## 03 / Find the right memory, not just a similar sentence. The next assistant asks, “What should we check before sending this month’s report?” It calls `agent_search` instead of relying on the conversation it happens to have open. Korium runs a keyword search and a meaning search. Keyword search finds specific language such as “canceled orders”; meaning search can find the earlier decision even when the new question uses different words. The two ranked lists are combined using reciprocal rank fusion. A memory returned by both searches becomes one candidate, not two copies. What should we check before sending the report? **Keyword search** Words and names **Vector search** Similar meaning **Reciprocal rank fusion** Combine positions from both lists **Importance + activation from use** Reorder the candidate memories Source memories + available related context ### Here is the ranking, without the hand-waving. For a memory found by both searches: ``` fusion = 1 / (60 + keyword_rank) + 1 / (60 + vector_rank) final = w_rrf × normalized_fusion + w_importance × importance + w_activation × activation ``` A search that did not return the memory contributes nothing to its fusion score. Korium normalizes that score across the candidates before blending it with importance and activation; the weights come from configuration, not one universal ratio. Importance is set when a memory is written, with type defaults where needed. Activation uses the history of times the memory was presented in results, including their timing. Being retrieved often is a ranking signal, not proof that a statement is correct. Search supplies candidates; the answer layer uses the question to decide what to return. A question about how many meetings someone attended calls for a count of distinct meetings, not a count of every turn they spoke. If a person is connected to several invoices and the question does not say which one, Korium asks you to choose. If the person and invoice are clear, it returns the relevant words once, linked to their source. The graph connects people, topics, passages and their original records. A missing connection or incomplete graph must be shown as incomplete information, not converted into a confident zero. [Read the retrieval details →](docs/korium/how-memory-works.html#relevance) Back to the report example ### The useful result is a changed plan. The assistant adds a canceled-order check and asks for the required review before the report is sent. Repeating “last month’s report was wrong” would not be enough. This illustrates the intended workflow, not a measured result or a live query response. ## A correction changes the guidance, not the past. Later, the team changes the rule: the report owner and the data owner both need to review the totals. Save that correction with the actual reason and source, then link it to the earlier decision. The relationship points from the new memory to the old one and is called `supersedes`. Where the client supports attached relations, the save and link can be written together; otherwise they are separate calls whose results must both be checked. Current guidance and historical evidence have different jobs. Use a trace or history browse to inspect earlier records, rather than assuming a normal search includes everything that has ever been stored. New correction ### Both owners review the totals. Keep who changed the rule, when and why. supersedes Earlier decision ### Check for canceled orders. The original mistake and its explanation remain part of the record. Age, use and replacement are not the same mechanism. The current implementation also has type-based expiry that can mark records no longer current without deleting them. The [lifecycle guide](docs/korium/how-memory-works.html#stale) lists the defaults and explains the distinction. ## The code map finds the implementation. Memory explains it. If fixing the report involves software, the assistant needs to find the right code as well as understand the decision. That is a different search over a different index. The Mac CLI extracts symbols such as functions, classes and methods from the repository. It sends symbol information and locations tied to a commit, not the source file bodies. A code query returns candidates with a file, line span and indexed commit. The assistant opens those locations in the local checkout and checks the actual code before editing it. An older index can still provide a lead, but its line numbers are not evidence of the current implementation. A completed upload is also not proof that the new index is answering searches. Separate from the memory write path 1. **Your checkout** The source files stay here. 2. **Korium CLI** Extract a commit-linked symbol map. 3. **Korium:code** Search the map and return locations. 4. **Your assistant** Read and verify the real source locally. The current symbol index covers Elixir / Rust / Swift / Python / shell / JavaScript / TypeScript / Go / Java / Ruby. It is not an index of PDFs, HTML, Markdown, SQL or configuration files. [See the code-index setup and limits](docs/korium/indexing-your-code.html). ## 04 / Memory informs the work. Skills and workflows put it into practice. The model can reason, and tools let it act. Neither tells it why your team rejected an approach last month, which checks your team requires, or who must approve the result. Korium:mem ### Read the reason. Find the canceled-order mistake and the current review rule. Keep the source IDs with the plan. Korium:code ### Find the code. Locate the reporting logic and verify it in the checkout. Skip this step if there is no software task. Korium:skills ### Load the method. Use reviewed instructions for checking totals, comparing examples and reporting discrepancies. Korium:workflows ### Do it in order. Prepare, check, review, approve and hand off. A person’s approval is still a person’s approval. **Then save what the work taught you.** If the check found another edge case, record it with the test and the resulting decision. The next task should benefit from it. A skill is instruction text, not a permission grant. A workflow describes the sequence; the configured assistant or runner executes it. Connecting memory alone does not install every playbook or schedule the work. [Build the small worked example →](docs/korium/capabilities.html#workflow-example) ## The moving parts underneath. MCP The authenticated connection used by assistants to call memory and code-search tools. Each client needs its own working connection and the right permissions. Elixir / BEAM The service runtime. It handles requests and supervises the work without making the capture wait for all background processing. Valkey The staging record and processing queue for new captures, with search over records that have not yet completed the move into long-term storage. PostgreSQL The settled memories, source fields, time information and relationships. Database row-level security restricts records to the authorized tenant. Oban workers + models Background jobs produce embeddings, extract information and, where enabled, compare memories. Their completion and failures are separate from the initial receipt. Search and ranking Keyword and vector retrieval, rank fusion, importance and use-based activation. Available relationships add context to the returned sources. The architecture explains how the work is divided; it is not a guarantee that every prediction is correct. For data handling, access and retention commitments, read the [security overview](legal/security.html) and [access guide](docs/korium/security-and-access.html). ## Keep the source. Correct what changes. ### See where the answer came from. A passage points back to the original record. Relationships retain the evidence behind the connection, and a partial answer says what information is missing. [Understand the response →](docs/korium/tool-reference.html#search-response) ### Keep the history when a decision changes. Save the new decision and link it to the one it replaces. The next task can use the current rule, while a review can follow the reasons the rule changed. [Work with decisions and corrections →](docs/korium/working-with-memory.html) ### Correct the connection, too. Marking a relationship wrong is different from removing a link you no longer want. The correction becomes a labeled example of the mistake, with the original evidence available to inspect. [Check a source and its connections →](docs/korium/release-status.html#memory) ## Give it a decision you keep explaining. Save the decision, its reason and its source. Open a fresh conversation, ask for it back and check whether the next plan actually uses it. [Sign up for Korium →](https://app.kyroco.ai/pricing.md) [Already have an account? Save your first memory →](docs/korium/getting-started.html) [Compare Korium with other memory tools →](korium-vs.html)