You hand a long media job to an AI agent and walk away. Cut the footage, color it to brand, reframe it for three channels, caption every version, export. An hour in, the agent is redoing a crop it already did, second-guessing a color pass that was right the first time, asking for a brief it was given at the start. The work is not wrong so much as lost. The agent is not picking up where it left off, because as far as it knows there is no left off.
Here is what is going on underneath. The agent did not get confused. It never kept the work in the first place. The model underneath it has no memory of its own, so the asset, the edits it already made, and where it was in the job all live in a working space that gets wiped the moment the context fills or the session ends. This is fixable. Full disclosure: Layermetry is one surface built to hold the state that fixes it, so we will lay out both paths, building it yourself versus adopting one, and let you decide.
A long job is the one thing the model is built to forget
Start with the part that surprises people. The large language model your agent runs on is stateless. It does not carry the last turn, the last file, or the edit it made five minutes ago. An agent is a model given hands, wired to tools so it can run an edit and check its own work, but the model at its core takes one input and returns one output with no loop that holds anything between calls.
The context window is working memory, not storage
Everything the agent "knows" right now sits in its context window, and that window is working memory, not a hard drive. One engineering breakdown of stateless models puts it plainly: the context window behaves like RAM, and when the inference call ends that working memory is discarded. A 2026 agent-memory writeup makes the same point and names the consequence. The window is good at holding the active state of the current task, and using it to hold long-lived facts produces failures that look like the model misbehaving but are really the work falling out of memory.
A long media pass is many calls, not one
A real media job almost never fits in a single turn. Cut, color, reframe, retouch, caption, localize, export is a sequence of calls, and a long one. Every call re-reads the whole context, and once the window fills the oldest turns get dropped to make room. So the crop you ran at the start and the color profile you settled on age out of the window as the job runs. Nothing carried them anywhere. They were only ever in RAM, and the RAM moved on.
A bigger context window is not a save file
The obvious fix is to make the window bigger and pour the whole job into it: the full brief, the entire edit log, every intermediate. In 2026, with windows reaching hundreds of thousands of tokens, that feels like it should work. It does not, and there is now solid evidence why.
Long context quietly rots
A widely cited 2025 technical report on context length tested 18 frontier models across the families teams actually use and found performance degrading as the input grew, even on deliberately simple tasks, well before the advertised limit. These are controlled benchmarks rather than a universal law, but the direction is consistent. The longer the prompt you pour the job into, the less reliably the model holds any one detail buried inside it, so the edit you logged earlier is exactly the thing it half-recalls by the time it acts. A bigger window does not give you a reliable record of the job, just a longer place for the record to blur.
And re-reading everything costs you on every turn
There is a second cost. Because every call re-processes the entire window, stuffing the full history into each turn means you pay for all of it again on every step of a long job. You pay more to be less reliable. A larger window is not memory, and a long prompt is not a save file. What a long job needs is state that lives outside the prompt, written down and addressable, so the agent reads it on purpose instead of hoping it is still in the window.
The three things a working agent has to keep
If the model has no memory and the window cannot be trusted to hold the job, then the work has to live somewhere durable that every turn reads and writes. For a long media job, that durable state comes down to three things. This is the asset-and-work persistence layer, and it is distinct from holding your visual identity steady, which is the job of shared brand state across turns, and distinct from carrying context across the join between two agents, which is the job of a good handoff at the seam. Here it is the work itself that must survive.
The asset, at one stable address
First, the asset needs one home with a stable address, not a copy that travels turn to turn. When each turn re-encodes or re-uploads the media to pass it along, the file degrades and the turns disagree about which version is current. Keep the asset in one place every turn points at, and the agent operates on the same object across the whole job instead of mailing itself photocopies. The work stops eroding because it is never being re-transcribed at every step.
The edit history, as an ordered record
Second, the edits need to be written down as an ordered log: which operation ran, with what parameters, in what order. This is the difference between an agent that knows it already cropped and an agent that crops again because the evidence aged out of its window. With an edit history it can read, the agent can resume where it stopped, skip work already done, and undo a step cleanly when a later pass goes wrong. A 2026 agent-memory architecture guide frames this as the split between fast working memory and a durable record of what happened, and that durable record is what lets a long job be more than a blur of recent turns.
The working task state, as a checkpoint
Third, the job needs a checkpoint: the goal, the current step, what is finished, and the next expected action, all held outside the model context. A 2026 state-persistence guide recommends exactly this, a separate task state that tracks completed actions, pending items, and the overall goal, independent of the model's active window. With that checkpoint in a durable store, a fresh context, a new session, even a restart after a crash can read the checkpoint and pick the job back up at step seven instead of starting over.
Make the state durable enough to survive a restart
Writing the three things down is half of it. The other half is making sure a turn that runs twice does not corrupt the record, because long jobs get interrupted and resumed all the time.
Checkpoint after each step, and resume from the last one
The pattern the field landed on is durable execution: save progress at each meaningful step to a real store, and on failure resume from the last good checkpoint instead of from the top. An open-source agent framework's durable-execution docs describe persistence that lets a workflow recover from a failure and continue from where it stopped, rather than replaying the whole run. For a media job, that is the difference between a timeout costing you one step and a timeout costing you the hour.
Make each operation safe to run twice
Resuming safely has one requirement worth stating plainly. Each operation has to be safe to repeat, because a resumed run may re-attempt the step it crashed on. Call this property idempotent: running the same edit twice leaves the asset in the same state as running it once. When operations are idempotent and the edit log is the source of truth, a restart is boring. The agent reads the checkpoint, sees what already ran, and continues without double-exporting or re-cropping. Get this wrong and a resume quietly duplicates work or corrupts the asset, which is worse than starting over.
Build the state layer yourself, or adopt a surface that carries it
This is the decision, and it is genuinely yours. Both paths work, so here is the honest cost of each.
Building it yourself: total control, ongoing upkeep
You can build this. A store for the asset at a stable address, an ordered edit log, a task checkpoint every turn reads and writes, and idempotent operations so a resume is safe. The win is real. Total control over the shape of your state and no dependency on anyone else. The cost is the part teams underestimate. The store, the schema, the checkpoint format, the idempotency guarantees, and the observability to see where a long run stalled are all standing work, not a one-time setup. Change one agent or one model and the whole flow can behave differently, so the watching that catches a half-finished job never stops.
Adopting a surface: speed and lower maintenance, one dependency
The other path is to adopt a surface that already holds the asset, the edit history, and the working state, so your agent reads and writes a durable job instead of you building the plumbing. You trade some control for speed, lower maintenance, and observability that is built in rather than assembled.
Layermetry is one such surface. It keeps the asset at one address, records the edits as an ordered history, and returns results an agent can read back on the next turn, so a long job survives the window filling and the session ending. It is extensible too, so you can ship your own tools alongside the native ones rather than being boxed in. The honest tradeoff is the dependency, which you should weigh the way you would weigh any infrastructure you buy instead of own.
Here is the whole thing in one line. The model will not remember the job, and a bigger prompt will not hold it, so the asset, the edits, and the working state have to live in a durable place the agent reads on every turn. Whether you build that place or adopt one, the agent primitives in /docs show how persistent, addressable state anchors a long media pipeline.
Frequently asked questions
Why does a long-running AI agent lose its work between sessions?
Because the model underneath the agent is stateless, and everything it knows for a given call lives in the context window, which is working memory, not storage. When the session ends or the window fills and old turns drop, that knowledge is gone. A long media job is really many calls in a row, so unless the asset, the edit history, and the task state are written to a durable store the agent reads on every turn, each turn starts in the dark and earlier work is lost. And as the 2025 context length research shows, pouring everything into one giant window does not save you, because accuracy degrades as the input grows.
What state does a long-running media agent actually need to persist?
Three things, all outside the context window. The asset itself at one stable address, so every turn points at the same object instead of passing copies. The edit history as an ordered record of which operations ran with what parameters, so the agent can resume, skip finished work, or undo cleanly. And the working task state, the goal, current step, what is done, and the next action, so a fresh context can pick the job back up. A 2026 state-persistence guide recommends keeping that task state separate from the model's active window for exactly this reason. The /docs reference covers the patterns this relies on.
Should I build the agent state store myself or adopt one?
Both are valid and it is your call. Building it yourself gives total control and no dependency, and a first version is reachable. The cost is the upkeep: the store, the schema, the idempotency, and the observability to see where a run stalled all keep working only as long as you maintain them. Adopting a surface that already carries the state trades some control for speed and lower maintenance. Layermetry is one such surface, and it is extensible, so you can ship your own tools alongside its native ones rather than being locked in.
The work was never going to live in the agent
The instinct is to make the agent smarter so it remembers the job. That is the wrong place to put the effort. No model holds the work, no window is big enough to keep it, and a session ends whenever it ends. Memory was never the agent's to keep. Give the work a home outside the agent and the agent is free to do the one thing it is good at: run the next step.
Decide which path fits you. Build that state layer and own every part of it, or adopt a surface that already carries it and spend your effort on the agentic work that sets you apart. Either way, the rule is the same. Stop asking the agent to remember the job, and give it one place to keep it. The agent primitives in /docs are a good next step on either path.