Three Kinds of AI Agent Memory and How to Use Them

Picture a travel-planning agent. In round one you say, "I'd like to take my parents to Japan on a modest budget, and I don't want a rushed schedule." In round two you confirm, "We'd rather go to Kansai, not Tokyo." In round three you add, "My parents can't walk very far, so the hotel should be close to a subway station."

If none of that was kept, what happens in round four? It might recommend Tokyo again, a route with lots of walking, or a hotel three kilometers from the subway. The cause is that what you confirmed and ruled out was never written down.

A plain chat often works fine as one question and one answer. An agent has to push a task forward over many turns. An agent that starts from scratch at every step repeats its questions, recommends options you already ruled out, and forgets boundaries you already set.

01 What an agent needs to know

To keep a task moving, an agent needs to know:

What the user's goal is
What has been confirmed
What has been ruled out
Which step it's on now
What the next step is

That knowledge comes from three different kinds of information, and they belong in separate places.

02 Three kinds of information, three jobs

Sort the information first, so you can decide how long to keep each piece and where to use it:

Once the user confirms the Kansai route, where does that sentence go? The original words can stay in the conversation history for lookup, and "destination set to Kansai" is distilled into task state for use when choosing a hotel. One sentence serves two purposes: history keeps the context, state records the current conclusion, and long-term preferences guide later tasks.

Now compare two statements. You ask an agent to write a complaint email and say, "Make the tone firm." That applies only to this task. A thank-you note, a partnership email and a job application each call for a different tone, so it counts as a temporary request. But if you tell the agent several times, "I prefer short, direct writing without filler," that looks like a long-term preference and can shape many later writing tasks.

A long-term preference is a default, and an explicit request for the current task takes priority:

Explicit request for this task  >  long-term preference

If the user wants a detailed explanation this time, give one. Keep the necessary reasoning, because "you always like it short" is no reason to cut it. As for "Customer A's contract is not yet confirmed," that's Customer A's task state and is used only within that task, so contract terms stay with Customer A.

Anthropic’s work on long-running agents connects sessions through progress records and handoff artifacts, letting the next session recover what has already been done.

03 Keep only what the next step needs

A dependable agent keeps only information that affects how the task moves. A customer follow-up agent, for example, needs the customer's current stage, the key point of the last conversation, what has already been promised, the next follow-up action, and which items need human confirmation. Small talk, unrelated background and expired temporary judgments can usually go.

To decide whether to keep something, ask:

If the agent forgot this, would it affect the next judgment?

If yes, and permissions allow it, put the content into conversation history or task state. If not, leave it where it is.

Task state can be organized as a "state card":

Task: investigate login failures
Current finding: the API returns 401
Ruled out: network disconnected, wrong API address
To confirm: whether the token has expired, whether user permissions are normal
Next step: check the request headers and the session refresh logic

This card makes the next step clear. Still, go back and verify that each "ruled out" item is backed by a check. A 401 alone doesn't confirm the API address is right, and "the token may have expired" is only a suspected cause. Keep facts, verified eliminations and guesses apart, and the next round can proceed from reliable progress.

A state card can use Anthropic’s structured note-taking approach: write key progress to a persistent file and read it into the current context when needed.

04 Stored information can go wrong too

Saved information can go stale, be misused or leak, so think about which information is truly useful.

First, old information expires. A user says "budget 5,000" and later changes it to "budget 8,000":

Wrong: keep both 5,000 and 8,000 and lose track of which one is valid
Right: record "budget: 8,000 (replaces the earlier 5,000)" and proceed on the new budget

After updating a number, recheck the judgments that depended on the old budget. A hotel ruled out because it cost 6,000 can now be reconsidered. A hotel ruled out because it was too far to walk is still unsuitable, because the parents' trouble with walking hasn't changed. If you change the number but keep the old screening result, the change hasn't reached the action.

Second, temporary requests are used only within their task, and stable preferences that carry across tasks need separate confirmation.

Third, information from one task can contaminate another. The handling rules for the previous customer apply only to that customer.

Fourth, sensitive information may be stored when it shouldn't be. If a user hands over an ID number, a medical record, a contract quote or a customer's phone number during one task, the agent may use it temporarily to finish that task and keeps it within that task: no long-term storage and no use elsewhere.

05 Three questions to decide what to keep

Three questions tell you whether a piece of information should be kept:

Personal privacy, trade secrets and account permissions call for shorter retention, a narrower scope of use and clearer user control.

06 State lets the next round pick up where you left off

A meeting-notes follow-up agent works the same way. If it records the current task, the material at hand, the steps done, the items awaiting confirmation and the next step, the next round can handle the open items and the email draft from those records. Before resuming a task, check whether the material has changed. If the meeting record now names an owner, the old state's "two owners unclear" must be updated. If only the layout of the draft changed, the action items you already checked can be used as they are.

Say the customer has already seen the demo. Should the next step be asking about budget, or introducing the product again? Only with this state saved does the agent have a basis for following up. Otherwise every round starts with "hello, let me introduce our product," which wastes time and looks unprofessional. How the state gets updated at each step comes up again in making an agent work in steps. Whether memory works well depends on how it supports later tasks:

Memory and state let the agent know:
who I'm helping,
what job I'm doing,
how far along it is,
which information has been confirmed,
and which information I must handle carefully.