AI Agent Memory and Sessions: What Should Your Agent Remember?

Today's outcome: Understand how sessions preserve the current interaction while memory carries selected goals and progress into future interactions.

This is Day 9 of AI Agents in 30 Days. In Day 8, we gave an agent tools. Today, we give it continuity.

Why agents need continuity

Imagine opening a study planner every evening and explaining the same information again:

• you are preparing for Java interviews;

• graph problems are your weakest area;

• your interview is approaching; and

• you completed arrays yesterday.

The model can respond to each individual message, but the application is not very useful if every interaction begins from zero.

Continuity solves this problem. It allows the application to reuse relevant information from earlier interactions. The important word is relevant. A good memory design does not simply collect every message forever.

Session and memory are related, but different

A session groups the items that belong to one continuing interaction. It may contain user messages, model responses, tool calls, and other events needed to understand the current thread.

For example, the OpenAI Agents SDK sessions guide describes sessions as a way to store conversation history for a specific session and automatically include that history in later turns using the same session.

Memory, in the broader application-design sense used in this lesson, is information deliberately preserved because it may improve future interactions. It may be stored as structured profile fields, progress records, preferences, summaries, or another durable representation.

Some frameworks use the word memory for session history as well. Names vary, so focus on the design question: Is this working context for the current thread, or a selected fact worth carrying forward? OpenAI's sandbox-agent documentation similarly distinguishes conversational session memory from a separate memory capability that can preserve lessons for later runs.

This is not a rule that every application must implement two separate databases. It is a mental model for deciding what should remain temporary and what deserves durable storage.

Practical example: a study planner

Suppose a learner says:

I have 90 minutes tonight. Move graph practice before Java collections, and remove the mock interview because I already completed it.

The current session needs enough context to revise tonight's plan correctly:

• the existing schedule;

• the new 90-minute limit;

• the requested order; and

• the completed mock interview.

After the revision is finished, not every detail deserves long-term memory.

The agent might preserve:

• Goal: Prepare for Java interviews.

• Weak area: Graph problems need additional practice.

• Progress: Mock interview completed.

• Preference: Put problem-solving practice before reading when possible.

It probably does not need to preserve:

• the greeting used in the conversation;

• temporary wording choices;

• intermediate drafts of the same schedule; or

• an abandoned suggestion that never became part of the plan.

The next time the learner asks for a schedule, the planner can begin from useful facts without replaying every old message.

The selective-memory rule

Before saving information, ask four questions:

1. Future value: Will this improve a later interaction?

2. Accuracy: Is it confirmed, or merely an assumption made by the model?

3. Lifetime: Should it expire, be updated, or remain until the user removes it?

4. Control: Can the user see, correct, or delete it?

The goal is not maximum recall. The goal is useful continuity with clear boundaries.

Try this today

Choose an agent you want to build. Draw two columns:

Remember

Write three pieces of information that would make the agent more useful next time.

Forget after the session

Write three details that are only needed for the current interaction.

Then add one sentence explaining how the user can update or delete saved information.

Completed example you can copy

Agent: Study Planner

Remember:
1. Goal: Prepare for Java interviews.
2. Weak topic: Graph algorithms.
3. Progress: Arrays and linked lists completed.

Forget after the session:
1. Intermediate schedule drafts.
2. Temporary greetings and conversational filler.
3. Suggestions the learner rejected.

Update rule:
When the learner changes a goal or marks a topic complete,
replace the old value instead of adding a conflicting memory.

User control:
Show saved memory in settings and allow correction or deletion.

Optional build exercise

Represent selected memory with a small structured object instead of saving the complete transcript:

{
  "goal": "Prepare for Java interviews",
  "weakTopics": ["graphs"],
  "completedTopics": ["arrays", "linked lists"],
  "updatedAt": "2026-08-20"
}

The exact fields depend on the application. Start with the minimum information required to produce a better next interaction.

Common mistakes

Saving the complete transcript as permanent memory

A transcript can be useful for a continuing session, but it may contain repetition, sensitive information, incorrect assumptions, and obsolete details. Select or summarize what deserves longer retention.

Treating model guesses as user facts

If the model infers that a learner dislikes mathematics, do not silently store that as truth. Save confirmed information or ask the learner to verify it.

Appending changes without resolving conflicts

If a learner changes the interview date, keeping both dates creates unreliable behavior. Define how the latest confirmed value replaces the earlier one.

Hiding memory from the user

Users should be able to understand what the application remembers. Review, correction, deletion, and sensible retention rules make memory more trustworthy.

Assuming every agent needs long-term memory

Many tasks are complete in one interaction. Add durable memory only when continuity genuinely improves the experience.

Quick knowledge check

1. What is the main purpose of a session?

2. What makes a fact a good candidate for memory?

3. Why should memory be updateable?

4. Does every agent require long-term memory?

Answers

1. A session preserves the working context of a continuing interaction.

2. It should be confirmed, useful in future interactions, and appropriate to retain.

3. Goals, preferences, and progress change; stale values can make the agent behave incorrectly.

4. No. One-shot or short-lived tasks may not benefit from durable memory.

Download the handwritten notes

Use the one-page notes to review the Session-vs-Memory mental model, the study-planner example, memory controls, and today's exercise.

Continue learning with Korshub

Memory design becomes easier when you build small projects and inspect how state changes across interactions. Korshub helps learners discover course listings and continue to the official course platform to review the current details and enrol when a course fits their goals.

Browse Korshub for learning resources on AI agents, Python, TypeScript, APIs, databases, and application security. Course prices, access methods, and availability can change, so verify current details on the official course page before enrolling.

Series navigation

• Previous: Day 8 - Function and Tool Calling

• Roadmap: AI Agents in 30 Days

• Next: Day 10 - Build a Study Planner Agent (link after publication)