Persistent memory for long-running AI agents

A long-running AI workflow needs memory outside the model’s context window. The useful kind holds the current work, visible progress, and the lessons one session leaves for another. An external runner or client starts those sessions; the persistent record gives them a shared handoff.

The model doesn’t have to stay alive for weeks. A runner decides when to start it, the client reads the work state, and the client writes back before the session ends. A later runner can begin from the same record.

This is the persistence problem behind long-running agents.

Long-running agents use separate sessions

A long-running workflow can look continuous from the outside. Underneath, a runner starts finite model sessions as work arrives or a schedule calls for it. Processes restart. Machines sleep. Providers change. Old conversation turns are compacted or dropped.

Anthropic’s work on long-running agent harnesses describes the same constraint: complex jobs span several sessions, and each session needs clear artifacts from the one before it. Cloudflare’s long-running agents guide treats an agent as a durable identity that wakes, works, and sleeps. Its in-memory variables disappear; its stored state survives.

Those are runtime designs. The same idea applies one level above the runtime, where the agent needs to recover the meaning of the work.

A checkpoint can tell a process which function to resume. It can’t tell a fresh model why a product decision was made last Tuesday, which workaround failed twice, or how the owner wants releases handled. That knowledge needs its own durable record.

Four records support the workflow

Useful persistent agent memory has more structure than a transcript or a vector index full of old messages. A runner and its sessions need four kinds of state.

Standing context tells the agent who it works for and which rules apply. This includes preferences, constraints, tools, and definitions that shouldn’t change from one run to the next.

Task records give an external runner work state to query. Assignment, status, priority, due date, dependencies, comments, and custom fields stay with the task. The runner decides which records to select and when. Custom-field values remain data that the runner interprets for itself.

A work record says what happened. Status changes, checklist items, comments, and project history make progress visible to a person and recoverable by a later run. “Done” means more when the reason and result are attached.

Durable lessons change future work. A project decision belongs with the project. A vendor gotcha belongs in knowledge. A better release procedure belongs in a reusable Agent Skill. Each lesson has a home and can be corrected when reality changes.

The four records have different lifetimes. A task may matter for a day. A project decision may matter for a year. A skill may apply to every project. Mixing them into one memory stream makes retrieval worse and leaves the agent guessing which old statements still count.

Agent learning means changing the next run

“Continuous learning” can sound like the model is retraining itself after every job. Most working agent systems are doing something simpler and more useful: they change the context and procedures available to the next run.

Suppose an import agent discovers that a vendor sometimes appends a blank row. It can patch today’s failure and close the task. If that is all it does, tomorrow’s run has to rediscover the behavior.

A learning loop leaves two more artifacts. The task comment records the cause and the patch. A note or skill records the rule that should guide future imports. When a similar job arrives, retrieval brings that rule back into the context window.

The model’s weights haven’t changed. Its behavior has, because the shared record got better.

This is why automatic chat capture is a weak foundation for agent learning. A transcript preserves everything with equal weight: wrong turns, abandoned guesses, stale constraints, and the final answer. A durable lesson is authored. The agent states what changed, where it applies, and what a later run should do with it. You can open that sentence and correct it.

What’s worth keeping for your AI uses a simple filter: save the things you would hate to explain again. For an ongoing agent, the filter gets one addition. Save anything that should change how the next run works.

Working with vtriv from an external runner

vtriv puts these records behind one hosted MCP connection. Your external runner handles schedules, model choice, tools, selection policy, retries, and the execution environment. vtriv stores and exposes the working state around those sessions.

A typical external-runner workflow has five steps:

A runner starts a client session, which reads vtriv_context for its standing profile, active projects, available skills, and recent activity.
The runner queries vtriv_tasks, applying filters such as assignment or status, then selects work under its own policy and fetches the full task with its comments and attachments.
The client records the task as in progress, does the selected work with the tools in its environment, and writes material progress on the task thread.
The client writes durable findings into the relevant project or knowledge document. If the better method should travel across projects, it updates an Agent Skill.
The client records the task as done. A later runner starts another session from the updated record.

The workflow can use Claude Code today and another MCP client tomorrow. Search spans the work the client can reach, while spaces keep unrelated or private contexts apart. The source stays in plain markdown, with structured tasks and timelines alongside it.

One connection also makes handoffs less fragile. A human can add a comment to a finished task, and a later runner can query that task and see the same goal, attachments, decisions, and thread. The handoff is a record, not a summary pasted into a new chat.

Retrieval needs a budget

Persistence creates a second problem: the record grows while the context window stays finite. Loading the full history on every run eventually costs too much and pulls old noise back into the model’s attention.

The start of a session should be small. Standing context supplies the few things that always apply. The runner uses task records to decide what comes next. Search and context packs pull only the relevant passages from project notes, knowledge, tasks, and skills, within a token budget.

That separation matters more as the loop ages. An agent that has run for six months should have more knowledge available without needing a six-month prompt. Persistent memory is the source; retrieval builds the working set for this run.

The maintenance rule is equally plain. Agents should update existing knowledge when a fact changes, remove stale instructions, and keep transient narration on the task thread. More memory is useful only when it makes the next decision easier.

A useful first loop

The first version can be small: one agent identity, a short profile, one project document, and a few task records. An external runner starts a client session, queries the records, selects work, and writes the result and any durable lesson back before the session ends. If you are choosing the store for that record, the MCP memory server comparison separates a Markdown knowledge base, a local graph, and a work-oriented context layer.

Run that pattern for a week. The evidence is in the second and third runs. The agent should ask fewer setup questions, repeat fewer dead ends, and leave work that is easier to audit.

vtriv stores the durable side of that workflow. Persistent memory for Claude across sessions covers the client setup, and it is free to start.