AI Agent Memory: How Agents Remember Between Runs

An AI agent without memory starts every run as a stranger to its own job. It re-reads the same emails it triaged yesterday. It re-fetches the same competitor pricing page and reports the same prices as if they were news. It burns tokens rediscovering context it already had, and it hands you a report full of things you already know.

AI agent memory is the fix. It is the persistent state an agent carries between runs: which items it has already processed, what the world looked like last time it checked, and what conclusions it reached. With memory, the second run is not a repeat of the first. It is a delta: shorter, cheaper, and focused on what actually changed.

This article explains how cross-run memory works mechanically, using Skopx agents as the concrete example. We will cover the two workhorse memory structures (cursors and baselines), why delta reports are the payoff, what memory should never be used for, and how to reason about memory when you write agent instructions.

What agent memory actually is, and what it is not

The phrase "AI agent memory" gets used loosely, so it is worth separating three different things that sometimes share the name.

Model context is the conversation window a language model sees during a single run. It vanishes when the run ends. It is not memory in any durable sense, any more than your short-term recall of a phone number is a filing system.

Training knowledge is what the underlying model learned before you ever used it. You do not control it, it does not update when your agent runs, and it knows nothing about your Slack channels or your CRM.

Cross-run memory is the durable state an agent writes at the end of one run and reads at the start of the next. This is the subject of this article, and it is the only one of the three that makes an agent genuinely stateful over time.

In Skopx, every autonomous agent built through Create Agent has this third kind of memory as a first-class part of its anatomy, alongside its instructions, trigger, grants, and budgets. The agent persists what it needs between runs: cursors, baselines, and working notes. When the next run starts, that state is available before the agent touches a single external tool.

The distinction matters because a lot of frustration with agents comes from expecting one kind of memory to do another kind's job. A model's context window cannot remember last Tuesday. Training knowledge cannot know your ticket queue. Only cross-run state can do either, and it has to be designed deliberately.

Cursors: remembering where you left off

The simplest and most valuable memory structure is a cursor: a marker that records how far through a stream of items the agent has processed.

Think of an agent that triages a support inbox every hour. Without a cursor, every run fetches the whole inbox, and the agent must work out from scratch which messages are new. With a cursor, the previous run recorded something like "processed through message received at 14:03 UTC" or "last handled thread ID X." The next run reads that marker and asks the mail API only for what arrived after it.

The consequences compound:

• Fewer reads. The agent fetches twenty new messages instead of two thousand old ones.
• Fewer tokens. The model reasons over twenty items, not two thousand. Since Skopx agents run under explicit token budgets per run and per day, a cursor is often the difference between finishing comfortably and hitting a cap.
• No duplicate actions. An agent that labels, replies to, or files items must never process the same item twice. The cursor is the idempotency line. Everything behind it is done; everything past it is work.

Cursors apply to anything stream-shaped: emails, Slack messages, new CRM leads, GitHub issues, Stripe events, rows appended to a database table. If the data arrives over time and each item should be handled once, the agent should keep a cursor.

One honest caveat: cursors can go stale or drift. If a source lets items arrive out of order, or lets old items be edited, a naive timestamp cursor will miss things. Good agent instructions acknowledge this. For example: "track the newest message timestamp you have processed, but also re-check the last hour's items for edits." Memory is a tool, not a guarantee, and the agent's run report should say what the cursor was and what it skipped, so you can audit the boundary. This is one reason run transparency matters so much for stateful agents: when every run shows its step timeline and you can expand the raw results, a wrong cursor is a five-minute diagnosis instead of a mystery.

Baselines: remembering what the world looked like

Cursors handle streams. Baselines handle snapshots.

Some jobs are not "process each new item once" but "watch this thing and tell me when it changes." Competitor pricing pages. A KPI dashboard. Your app's review score. A ranking position. The set of open bugs tagged critical. For these, the agent stores a baseline: a structured snapshot of the state of the world as of the last run.

A concrete, hypothetical example. You build a Skopx agent with the instructions: "Every Monday at 9:00 UTC, check the pricing pages of these four competitors and report changes." The first run has no baseline, so it does the expensive version of the job: fetch all four pages, extract the plans and prices into a structured summary, and store that summary as the baseline. Its report is a full inventory, because everything is new information.

The second run starts differently. It loads the baseline, fetches the four pages again, and compares. Three pages match the stored snapshot. One shows a plan renamed and a price raised. The report for run two is a few paragraphs: here is what changed, here is what it was before, here is the diff. Everything else is a single line saying "unchanged since last week."

That comparison step is where the intelligence lives. Diffing structured state is dramatically more useful than re-describing raw state, because the diff is exactly the part you did not already know. It is also cheaper: the agent spends its reasoning on the one changed page, not on re-summarizing four unchanged ones. If you are building a watcher like this, the competitor monitoring pattern is essentially this baseline mechanic applied to a specific domain.

Baselines have their own failure mode worth admitting: representation drift. If the baseline stores prose ("the Pro plan costs about forty dollars"), comparisons get fuzzy and the agent may hallucinate changes or miss real ones. The fix is to instruct the agent to keep baselines structured and specific: names, numbers, URLs, dates. Structured state diffs cleanly; vibes do not.

Delta reports: why the second run is the one you actually want

Put cursors and baselines together and you get the signature output of a stateful agent: the delta report.

Every Skopx run ends in a markdown report rendered as a document, evaluated against the success criteria you defined for the agent. On a first run, that report is necessarily a full survey, and it is the most expensive report the agent will ever produce. From the second run onward, the report can be organized around change:

• What is new since last run (from cursors)
• What changed since last run (from baselines)
• What stayed the same (one line, not ten paragraphs)
• What the agent did about it, including anything parked for your approval

This is the format humans actually read. Nobody wants a weekly document that is 90 percent identical to last week's. A delta report respects the reader's memory as well as the agent's: it assumes you saw the previous report and only tells you what moved. If you want to go deeper on structuring these documents, see how agent reports work.

Delta reports also change the economics. Here is the honest comparison between a first run and a typical steady-state run of the same agent:

"Typically much lower" is the honest phrasing. A week where everything changed will produce an expensive run regardless of memory. What memory guarantees is that you never pay full price for an unchanged world. On Skopx, where each agent runs under a per-run and per-day token budget, this is not just a cost nicety: it is what keeps a scheduled agent comfortably inside its limits month after month. There is a fuller treatment of sizing those limits in the guide to token budgets for agents.

What belongs in memory, and what does not

Memory is powerful enough that the temptation is to stuff everything into it. Resist that. Good agent memory is small, structured, and purposeful. A reasonable rule: memory should hold pointers and summaries, not copies of the world.

Belongs in memory:

• Cursors: last processed ID, timestamp, or page token per stream
• Baselines: structured snapshots of watched state, compact enough to diff
• Working conclusions: "flagged account X for churn risk on 08-04, no action taken yet"
• Counters and streaks: "third consecutive week this metric declined"

Does not belong in memory:

• Full copies of documents, threads, or tables the agent can re-fetch from the source
• Anything the source system already versions better than the agent can
• Secrets or credentials (in Skopx, connected credentials are stored encrypted and managed by the platform, not scribbled into agent state)
• Stale judgments the agent should re-derive fresh, like "this customer is unhappy," which deserves re-checking rather than caching forever

The last point deserves emphasis because it is where memory quietly turns from asset to liability. A cached cursor is a fact. A cached opinion is a bet that the world has not changed. Instructions like "re-evaluate any account you flagged more than 30 days ago instead of trusting the old flag" keep memory honest. When you write agent instructions, treat memory hygiene as part of the spec, not an afterthought; the instructions guide covers how to phrase this kind of rule so the agent actually follows it.

Memory and safety: state does not expand permissions

A stateful agent is a more capable agent, so it is fair to ask whether memory weakens your control. In Skopx's model it does not, because memory and permissions are separate systems.

Grants are set per integration toolkit, and each grant has a tier: the action runs automatically, the agent asks first every time, or the agent decides when to ask, with a drafts-only mode available for communication tools. Nothing about accumulated memory changes those tiers. An agent that has watched your CRM for six months has exactly the write permissions it had on day one.

Approvals interact with memory in one specifically useful way. When a write-shaped action parks as a pending approval, you see the exact call and arguments before anything executes; approving runs exactly that parked call once, and rejecting runs nothing. Memory lets the agent attach history to that request: not just "send this follow-up email" but the context that this is the third week the invoice has been outstanding and the previous two reminders got no reply. You approve with the timeline in front of you instead of reconstructing it yourself.

Two more control surfaces are worth knowing. Run history is append-only, so the sequence of what the agent knew and did is auditable after the fact; memory can be updated, but the record of each run cannot be rewritten. And pausing an agent is a kill switch for queued runs, so if you suspect the memory has gone wrong (a corrupted cursor, a baseline captured during an outage), you can stop everything, inspect recent runs, correct the instructions, and resume. Practical techniques for that inspection loop are in debugging agent runs.

Designing memory into your agent from day one

You do not program memory in Skopx; you describe the job in chat and the agent is assembled from that description, with instructions you can edit and version afterward. But the way you describe the job determines how well memory serves it. Four habits help.

Name the stream and the snapshot. Be explicit about what is stream-shaped ("new tickets since last run") versus snapshot-shaped ("current state of the four pricing pages"). This tells the agent to keep a cursor for the first and a baseline for the second, rather than improvising.

Ask for deltas by name. Put it in the instructions: "From the second run onward, report only changes since the previous run. List unchanged items in one line." Agents follow the report structure you specify, and the difference between a delta report and a weekly wall of text is usually one sentence of instruction.

Expect an expensive first run. The first run builds the baseline and has no cursor, so it will fetch more, reason more, and produce a longer report. Budget for it, read it carefully (it is your one full inventory), and judge the agent's steady-state behavior by run two and beyond. If you evaluate a stateful agent on its first run alone, you will overestimate its cost and underestimate its usefulness.

Schedule with memory in mind. Memory and scheduling are natural partners. A scheduled agent that runs every Monday only makes sense if it remembers last Monday; otherwise you have built an expensive way to re-read the same data weekly. Conversely, memory lets you schedule more frequently than you otherwise could, because an unchanged world produces a nearly free run: cursor advances, baseline matches, short report, done.

Limits worth being honest about

Memory makes agents better. It does not make them clairvoyant, and there are real limits.

Memory records what the agent saw, not what happened. If a run was stopped mid-flight, or a source API returned partial data, the stored state reflects that partial view. This is why Skopx runs carry a full step timeline with expandable raw results: when a delta looks wrong, you can check what the agent actually fetched on the runs that wrote the state.

Diffs are only as good as the snapshot's structure. A baseline that stored ambiguous prose will produce ambiguous diffs. If your agent keeps "detecting changes" that are really rephrasings, tighten the instructions to store structured fields.

Memory does not transfer between agents. Each agent's state belongs to that agent. Two agents watching adjacent things do not automatically share conclusions. If one job needs another job's findings, either merge them into one agent or have the first save its conclusions to a shared surface like the Insights Hub, where other work can pick them up.

Failure handling still matters. Skopx auto-pauses an agent after three budget failures, and memory does not exempt an agent from that rule. If a source suddenly grows (a viral week floods the inbox past the cursor), the run may hit its cap regardless of how efficient the memory is. Treat that pause as a signal to revisit either the budget or the scope, not as a memory bug.

None of these limits argue against memory. They argue for treating memory as an engineered part of the agent, described in the instructions, visible in the reports, and checked when something looks off.

FAQ

Does an AI agent's memory persist if I edit its instructions?

In Skopx, instructions and memory are separate parts of the agent. Instructions are editable and versioned; memory is the state the agent carries between runs. Editing instructions does not wipe cursors or baselines, which is usually what you want: you can refine how the agent reports without forcing it to rebuild its view of the world. If you change the job so fundamentally that old state no longer applies, say so in the instructions ("ignore any previously stored baseline for the old pricing pages") so the agent re-establishes state cleanly on its next run.

Why is the first run of an agent so much more expensive than later runs?

Because the first run has nothing to compare against. It must fetch everything in scope, reason over all of it, and write both a full report and the initial memory: cursors positioned at the current edge of each stream, and baselines snapshotting each watched surface. Every later run starts from that state and pays only for the difference. This is normal and worth budgeting for. Judge an agent's ongoing cost from its second and third runs, not its first.

Can agent memory leak data or bypass my approval settings?

Memory does not change what an agent is allowed to do. Grants are configured per toolkit with explicit tiers, write-shaped actions still park as pending approvals showing the exact call and arguments, and connected credentials are encrypted and never part of agent state. What memory adds is context: an approval request can reference history, like prior reminders sent, so you decide with more information. Run history is append-only, so what the agent knew and did on each run remains auditable.

What is the difference between a cursor and a baseline?

A cursor marks position in a stream: "I have processed everything up to this ID or timestamp." It suits data that arrives item by item, like emails, tickets, or events, where each item should be handled exactly once. A baseline is a snapshot of state: "this is what the pricing page, dashboard, or record set looked like last time." It suits data that changes in place, where the job is detecting and explaining differences. Most useful agents keep both: cursors for their inputs, baselines for the things they watch.

Do second runs always cost less than first runs?

No, and any platform that promises that is overselling. A second run is cheaper when the world mostly held still, which is the common case for monitoring and triage jobs. A week where everything changed produces a run that costs accordingly, because there is genuinely more to fetch, compare, and explain. What memory guarantees is the absence of waste: you never pay to re-discover an unchanged world, and per-run and per-day token budgets cap the downside on volatile weeks.

Memory is what turns a tool into a colleague

The difference between an agent you run and an agent you rely on is continuity. A stateless agent answers the question you asked. A stateful agent notices what changed since you last asked, skips what you both already know, and gets cheaper as its picture of your work sharpens.

Mechanically, that continuity is unglamorous: a cursor here, a structured baseline there, a report template that leads with the diff. But the compound effect is the whole point of autonomous agents. Describe the job once in Create Agent, let the first run pay the one-time cost of learning the landscape, and every run after that starts where the last one ended. That is what memory is for: making sure the work, once done, stays done.