A Kuaapy proposal about memory, personalization and the value of knowledge built between a person and their AI agents.
You spend hours working with an agent. You explain the project, correct an interpretation and find a better way to review the work. Through the conversation's context, it learns that you prefer to hear an explanation, that a particular decision has already been made and that a procedure needs to follow a specific order.
That work produces something beyond the completed task. It produces knowledge about how to work with you.
When continuity is lost, part of that investment has to be made again. You explain what you have already explained, correct what you have already corrected and rebuild agreements that were working. The model may remain capable. What is missing is the path you built together.
Knowledge is too valuable to be treated as a conversation's leftovers.
The proposal is to let each agent preserve and develop its own working configuration with the user. Memory, instructions, skills and conversational style would be part of that continuity. Opening a new session should not require starting that working relationship from scratch.
A shared foundation, different configurations
A person can work with several agents and want different things from each one.
The infrastructure agent needs to track decisions about servers, dependencies and operating conditions. The editorial agent needs to preserve the author's voice, language choices and publication criteria. The marketing agent may work with a different pace, vocabulary and way of presenting ideas.
They can all share general guidance. That does not mean they should receive exactly the same configuration.
Each agent should have its own operating instructions: role, priorities, review process, level of detail, tone and available skills. The person would choose what applies to everyone and what belongs only to that agent.
Those choices should be available in an accessible interface. More direct or more conversational. Brief or detailed explanations. Headings, lists and emojis. A preference for text or voice. Procedures specific to the role. People who want to edit the files could do that too, but knowing configuration syntax should not be a condition for personalizing their own tool.
Keeping the conversation is not enough
A history preserves what was said. To help with the next task, the system also needs to distinguish what still applies.
Imagine a text review. The author explains that a particular phrase is part of her voice and asks to preserve it. The agent needs to keep more than the phrase: it needs to recognize the decision and the context in which it was made. If the author later changes her mind, the memory should reflect that change.
In the architecture we propose, a record-keeping process would work in the background. It would organize the history and identify decisions, constraints, preferences and procedures worth keeping available. Notes would retain a link to their origin so the reason they were recorded could be checked.
This would not require including the entire conversation in every new request. The history could be organized in layers: recent details immediately available, summaries of earlier stages and access to the original records when needed.
A passing suggestion should not become a permanent rule simply because it appeared in a conversation. Nor should an individual preference be promoted indiscriminately into an instruction for all agents.
Memory needs review too
Keeping a wrong decision for months does not improve an agent. It merely gives continuity to the error.
Another part of the proposal is therefore periodic consolidation. At times configured by the user, a process would review what had accumulated: merge duplicates, identify contradictions, mark superseded information and check what still matches the project.
A note about code could be compared with the current files. A communication preference could be reviewed against more recent guidance. An unanswered question would remain marked as such until an answer existed.
The user should be able to inspect and correct this memory. Knowing what the agent believes about the work is part of being able to personalize it.
Recovering agreements at the right moment
A well-organized memory still needs to reach the agent when it makes a difference.
If the conversation returned to an earlier decision, the system would search related records and supply the necessary context. If a summary was insufficient, the agent could retrieve the original passage. A pending item could also resurface when the time came to address it.
Periodic reminders would be another option. The person could set intervals for reviewing current goals, constraints and decisions. This would help keep long-running work on course without dumping the entire history back in or interrupting the conversation with every reminder.
The important thing would be to retrieve what is relevant to the current task while preserving where it came from and whether it still applies.
What is learned can become a skill
Some knowledge begins as a correction and eventually becomes a method.
After several reviews, an editorial agent might assemble a procedure: preserve the original, separate firsthand accounts from verifiable claims, check sources, present changes and wait for the author's direction on images. Another agent might develop its own procedure for preparing a software update.
Our proposal is to allow those patterns to become reusable skills. They would describe when the procedure applies, which steps to follow, which mistakes to avoid and how to check the result.
For example, a person could configure a weekly review in which the agent proposes updates to its skills based on that week's work. The interval would be a choice, not a universal rule. The system would need to distinguish a procedure that worked from a behavior that merely repeated itself.
That skill could stay with the individual agent or be shared at the user's discretion. The blog agent would not automatically need to inherit the server administrator's method.
Continuity can be local
This proposal does not depend on retraining the model after every conversation. The application can maintain instructions, memories and skills in files and local storage. When carrying out a task, it assembles the appropriate material and presents it to the model.
That is the sense in which the agent would learn from the person: by adding retrievable knowledge and procedures to its working configuration. This does not, by itself, mean changing the model's weights.
If reviewing those memories uses AI, it could rely on a local model or a remote service, depending on the configuration. Keeping files on the machine does not automatically make all processing local. The user should be able to choose where each stage happens, how often and at what cost.
They should also be able to separate each agent's memory from a project's shared memory. Collaboration does not require mixing everything together. Some decisions need to reach the whole team; some knowledge makes sense only within a particular role.
The value lies in the work built together
Two agents can start with the same model and the same instructions. They then receive different tasks, go through different corrections and build different procedures with the person using them.
Preserving that trajectory gives the user something they should not need to rebuild with every session: continuity.
Changing the model, opening another conversation or completing a task should not require abandoning accumulated knowledge. The person should be able to keep, review, export and take that working configuration with them.
That is what we mean when we say agents should not be disposable. Their value also lies in the time invested in making the collaboration work. In the explanations, adjustments and solutions that grew out of use.
The more that knowledge helps the person work, the more reason there is to preserve it.