A loop almost always needs to know what happened last time — which items it already handled, where its last scan got to, what it decided to skip. Without somewhere to put that, an agent ends up re-reading the notes it wrote into a thread last tick and trying to parse its own prose back out, which works right up until the wording changes and it silently does everything twice.
So each workspace has a small store of saved values: a name and a value, written by one run and read by the next. Scripts use it and so can prompts, and both see the same values, so a script can record what it found and a prompt-driven agent can pick up from there.
Nothing in it expires. That is the deliberate difference from a lock, where lapsing is the whole point — a list of things already handled that quietly emptied itself would just do the work again. Values stay until something overwrites or deletes them, and they are meant for state rather than storage: the ids you have seen, a cursor, a last-run timestamp.
It is scoped to the workspace rather than to one agent, which is what lets the two halves of a pipeline share a memory. If an agent wants something private, it prefixes its own names.
You can see it too. The workspace's Storage tab lists every saved value with its type, its size and when it was last written, and opens one when you click it. Deleting a value there is the one change it lets you make, which is usually how you ask a loop to start a list over. A table or chart in a thread can show a saved value directly and keep up with it as it changes; see Replies you can use, not just read.