Some of my workflows need to remember something from one run to the next, or hold onto context during a conversation. How does persistent storage work in 3B across runs and chat turns? I’m curious what sticks around versus what resets, and how I’d read and write that state.
Great question, and it gets at something that trips people up early: by default, a workflow run is stateless. Each run starts fresh, and the ephemeral filesystem you scribble to during a run resets on the next one. So if you want something to survive, you have to put it somewhere that’s meant to persist.
Here’s the mental model.
What resets: anything you write to the ordinary working filesystem during a run. It’s scratch space. Great for temporary files mid-run, gone by the next one. Same goes for variables in memory, they don’t outlive the execution.
What sticks around: a named volume. That’s the durable storage you mount into a step, and whatever you write there stays put across runs and across chat turns. That’s the thing you reach for when a workflow needs to remember.
So the two cases you mentioned map cleanly onto that.
For remembering something from one run to the next, write your state to a volume at the end of a run and read it back at the start of the next. Think of it like a little database or a JSON file that lives outside any single run. Common uses: a “last seen” timestamp or ID so you only process new items, a running count, a cache of results keyed by some identifier so you don’t re-fetch the same thing.
For holding context during a conversation, the transcript is just state you keep appending to. Each turn, you read the existing conversation from the volume, add the new message, do your thing, and write it back. That’s what lets a chat remember what was said three turns ago instead of treating every message as the first.
A few practical notes. Reading and writing is just file operations against the mounted volume path, so a JSON file you load, modify, and save back covers most needs. For anything with real volume or where you’re querying, a SQLite file on the volume works well. And when multiple runs might write at once, be deliberate about who writes and when, because concurrent writers stepping on each other is the classic way persistent state gets corrupted. Keying data by run or item, or designating a single writer, keeps that clean.
The short version: working filesystem is scratch and resets, named volumes persist across runs and chat turns, and state is just files you read at the start and write at the end.