Memory for long-running agents

This page shows how an agent that runs for weeks or months can start each new session with the instructions and decisions that still apply, instead of a replay or a summary of every earlier session.

The problem

An operations agent runs several times a day and publishes a weekly report. Each run is a new session with an empty context window. In March, its operator told it to publish every Monday morning and list every alert. On April 9, in a chat with the agent, the operator changed that: publish every Friday, with incident summaries instead of raw alerts.

When run 214 starts, the agent must follow the April instruction, not the March one, and it must not lose the standing instructions that never changed, such as who receives the report.

Why the usual approach falls short

Replaying earlier transcripts grows with every run. Cost and latency rise each time, the history eventually exceeds the context window, and trimming it drops the oldest turns first, which can be a standing instruction that still applies. While both instructions fit, the model sees Monday and Friday and has to work out which came later.
A rolling summary that the agent rewrites at the end of each run stays small but loses a little each time. A summary can keep both schedules, drop the one that still applies or carry an early mistake forward indefinitely, and it holds no date for when each instruction was given.
Session resume and compaction keep one conversation going. The Claude Agent SDK and the OpenAI Agents SDK store a session’s history so it can be resumed, and compaction shrinks context within an interaction (as of October 2026). They keep the conversation, not the facts that outlive it. See Claude Agent SDK sessions and OpenAI Agents SDK sessions.
File-based memory, such as Anthropic’s memory tool, gives the agent files it edits itself. It works well for one agent’s working notes; a changed instruction is a file edit the agent has to make correctly, and conflicts are left to the agent. See Anthropic’s memory tool.

These work for an agent that runs a handful of times. Over weeks of changing instructions, something has to decide which instruction replaced which.

How Alvia changes the design

The agent stores each standing instruction when it is given. After a run in which a person talked to the agent, your runner imports that conversation. Alvia relates each new instruction to the ones it holds. In this example, Alvia classifies the Friday instruction as replacing the Monday one and makes it that instruction’s next version (see Memory formation).

When a run starts, your runner asks Alvia a few specific questions and puts the answers in the agent’s prompt. The agent no longer reads its history to work out what applies. The state of the work itself, such as this week’s incidents and whether a report was sent, stays in the systems that own it.

Set up

Project. Use a project for the agent’s environment, and a separate project for agents whose memories must never be readable together.
Scope. Use the same agent_id, such as ops-agent, on every write and read. When the agent serves individual people, also send a user_id taken from the signed-in session: an agent_id alone does not separate those people’s memories. See Projects and scope.
Memory policy. In the dashboard, exclude access tokens, customer personal data and incident payloads. Keep the instruction, such as the sections and the schedule, not the logs that led to it. See Filter memories.

Example

Store the first instruction

In March, the agent, connected over MCP, stores the instruction it was given with the remember tool:

{
  "content": "Publish the weekly operations report every Monday morning and list every alert from the previous week.",
  "occurred_at": "2026-03-02T09:00:00-05:00",
  "agent_id": "ops-agent"
}

Tell the agent to do this in its instructions:

When you are given a new standing instruction, store it in Alvia with
agent_id "ops-agent", and say what it replaces.

Import the conversation that changes it

After the April 9 run, your runner imports the conversation. speaker names the operator, because the memories are about the agent:

curl https://api.alvia.ai/v1/memories/import \
  -H "Authorization: Bearer $ALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "occurred_at": "2026-04-09T10:12:00-04:00",
    "scope": { "agent_id": "ops-agent" },
    "messages": [
      {
        "role": "user",
        "speaker": "Priya Nair",
        "content": "From now on, publish the weekly report every Friday and include incident summaries instead of listing every alert."
      },
      {
        "role": "assistant",
        "content": "Understood. From the next report I will publish on Fridays with incident summaries."
      }
    ]
  }'

The import returns 202 with an empty body, and formation runs in the background. Import only user and assistant turns; leave out tool calls and system prompts. See Import conversations.

Ask when the next run starts

When run 214 starts, the runner asks:

curl https://api.alvia.ai/v1/memories/context \
  -H "Authorization: Bearer $ALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "What are my current reporting instructions?",
    "scope": { "agent_id": "ops-agent" }
  }'

An illustrative response:

{
  "context": "Publish the weekly report every Friday with incident summaries, as instructed on April 9, 2026."
}

On the agent’s first run, context returns 404, and the agent starts from its built-in instructions. Ask one specific question for each area the run needs: “What are my current reporting instructions?” returns a better answer than “What should I know?”.

Put the answer in the run’s prompt

The runner adds the answer to the prompt it starts the agent with:

You are ops-agent, starting run 214.

Your current reporting instructions, from memory:
<memory>
Publish the weekly report every Friday with incident summaries, as
instructed on April 9, 2026.
</memory>

Read this week's incidents from the incident system, not from memory.

The agent plans the run from the April instruction and never sees the March one. For a full list of the agent’s memories, for example to review them, use GET /v1/memories?agent_id=ops-agent.

Agents in the same project share memory when they use the same scope, and stay apart when they use different scopes. Suppose a triage agent and the operations agent should both follow the team’s escalation rules:

Shared facts. Both write and read the escalation rules with team_id: ops and no agent_id. Alvia relates a new fact only to memories with exactly the same scope, so when either agent records a changed rule, Alvia can relate it to the version the other one wrote.
Each agent’s own facts. Each writes its own instructions with team_id: ops and its own agent_id. A read with team_id: ops and agent_id: triage-agent returns only that agent’s memories; a read with team_id: ops alone returns the shared facts and every agent’s own.
Separation. Different scopes keep memories apart for relevance, but any key in the project can read any scope. Agents whose memories must not be readable by each other need separate projects, and no read or formation crosses from one project to another.

What one agent stores is readable by the others once it forms. Agents consult Alvia as shared context. To hand off a task or keep two agents from taking the same one, use a queue or your work tracker.

What Alvia does here

Formation turns stored instructions and imported conversations into memories
Supersession makes the Friday instruction the next version of the Monday one in this example
Contradiction keeps two conflicting instructions and links them, so context reports both
Occurrence dates keep when each instruction was given, including conversations imported after the run
Scope keeps each agent’s memories together and lets agents share the facts they should
Memory policies keep tokens and incident payloads out of memory
Import forms memories from each conversation
Resolved context returns one answer for the run’s prompt
Forget removes an instruction stored by mistake

Design notes

Formation is asynchronous. The run that receives an instruction acts on it from its own context; formation finishes in less than a minute, so later runs read it shortly after it is stored.
Context is one focused answer. It resolves the best match for one question in one to three sentences, so ask one specific question for each area the run needs.
Work state stays where it lives. Read incidents, schedules and whether a report was sent from their systems. Alvia holds that a task was given; your tracker says whether it is still open.
Keep an audit record. Store the context each run used with that run’s audit record.
Where Alvia fits. Keep fixed instructions in the agent’s prompt, and resume a short-lived session with its SDK. Alvia holds the instructions and decisions that change across weeks of runs. See Alvia compared with other approaches.

Build it with a coding assistant

Give a coding assistant this brief together with Build with an AI assistant:

Give our scheduled agent memory of its standing instructions. Use
agent_id "ops-agent" on every Alvia call. Have the agent store each new
instruction with what it replaces. After a run with a person, import the
user and assistant turns with the run's date. At start-up, ask one
context question per area and put each answer in the run prompt; treat
404 as no memory yet. Read incidents and report status from their own
systems. Test an instruction that replaces an earlier one.