Cross-Session Agent Context Persistence Without Re-Prompting

An agent works a problem for an hour, builds up a sharp understanding of what it's doing, and then a context compaction event fires. Afterward, the agent cannot recall the project parameters it opened the session with. No query brings them back, because the summarization step that ran during compaction already threw them away. This is the failure this whole piece is built around: not a retrieval problem, but a destruction problem. Standard API calls to language models are stateless by design. The model delivers a response and keeps nothing; the next call starts from zero unless something outside the model carries history forward. The context window is a working buffer, not storage, and it flushes when the session ends. Making the window bigger doesn't fix this. The MOMENTO paper makes a related point about how this gets evaluated: many agent benchmarks test performance inside a single session and never measure what happens across sessions, so the cross-session failure mode barely appears in the numbers the field uses to grade itself. In production this looks mundane and expensive at the same time. A research agent re-reads and re-summarizes documents it already processed last week. None of that is the model being dumb. It's the workspace disappearing underneath the model every time a session ends.

How the field currently attempts to solve cross-session persistence

The field's answer to this has mostly taken the same shape: treat the agent's workspace as something temporary, then build infrastructure to reconstruct it at the start of every session. The common pattern is tiered external storage. Short-term context for the current conversation sits in a fast cache keyed to a session ID, while long-term knowledge gets written out to a vector store or a graph and pulled back in semantically once a new session starts. A number of dedicated products have been built around this model, each with its own take on where the data lives and how it's retrieved. Mem0 combines vector, graph, and key-value storage behind a managed API with partial support for scoping memory across multiple agents. What they share, despite differences in architecture and licensing, is the assumption that the workspace itself is temporary and has to be saved out, then rebuilt from scratch at the next session.

What "save and re-inject" costs at the architectural level

Treating the workspace as temporary carries costs that no amount of better retrieval engineering removes, because the costs come from the pattern itself, not from any one tool's implementation. Re-injection is lossy by construction. Summarizing and embedding information both compress it, so what an agent receives at the start of a new session is a reconstruction of what it once knew, not the original state, and some of what mattered is already gone before the session even starts. Retrieval also depends on the agent knowing what to ask for. Semantic search returns results similar to a query, but an agent that doesn't realize it forgot something has no query to run, so the gap stays invisible until it causes a visible mistake. Judgment errors compound the problem over time: if an agent decides in session one that some detail isn't worth saving, that decision quietly shapes every session that follows it, and by session ten the agent is working from a version of the project that drifted away from reality several sessions back. Automated extraction pipelines reduce how often this happens, but they don't eliminate it, because the pipeline still has to guess at what matters. Multi-agent setups make the problem worse. When several agents write to the same memory store, each one records its own version of events, and a single piece of context can fork into two or three competing accounts of what actually happened. Every framework described in the previous section accepts the premise that the workspace has to be torn down and rebuilt. None of them asks the more basic question: what if the workspace just didn't go away?

What a persistent, shared filesystem provides over memory frameworks

A persistent filesystem removes the teardown step entirely, leaving reconstruction unnecessary. Files, directories, intermediate outputs, and working notes written during one session are still sitting there, unchanged, when the next session opens. Nothing had to be saved out and nothing has to be reconstructed, because nothing was ever destroyed. This also changes how an agent builds context. Instead of needing everything relevant injected up front, an agent can explore the filesystem the way a person opens a project folder: look around, read what's needed, and build understanding step by step as the work progresses. That has a practical effect on tooling, too. Every custom tool bolted onto a memory framework costs context window tokens and gives the model one more way to fail a tool call. Collapsing that surface down to bash, an interface the model already knows cold from training, cuts both the token overhead and the failure surface at once. Shared filesystem mounts also solve multi-agent coordination differently than a shared memory store does. Multiple agents can read and write the same filesystem at the same time, with POSIX guarantees like atomic rename, file locking, and hard links keeping things consistent without any central service arbitrating between them. A persistent filesystem that remains mounted across sessions eliminates this class of failure entirely: the agent's state never needs to be saved, extracted, embedded, or re-injected because it was never destroyed. Archil, a serverless filesystem that mounts cloud storage as a native POSIX filesystem, enables exactly this pattern, letting agents work against a stable, durable workspace that survives session boundaries independently of the context window. None of this replaces a database for data that actually has a clean schema. User records, transaction tables, structured knowledge bases: those belong in a relational or graph database with real indexing, and nothing here argues otherwise.

The POSIX requirements that make or break agent filesystem use

Not every system that calls itself a filesystem gives an agent what it actually needs, and the gap usually appears in the POSIX details that existing code quietly assumes are there. Atomic rename is one of them. Agents that write to a temporary file and then rename it into place, a standard safe-write pattern, need that rename to happen as a single indivisible step; without it, a crash or a competing agent can leave a half-written file sitting where a complete one should be. File locking through flock and fcntl matters whenever multiple agents coordinate access to the same files, because without advisory locks, one agent can read a file in the middle of being written by another and get a version of it that never actually existed. Hard links and symlinks show up constantly in real codebases and data pipelines, and a filesystem missing either one forces code changes that undo the whole point of a drop-in filesystem layer. Sparse files matter for large model checkpoints and embedding indexes, which rely on not having every byte physically written out; a filesystem that materializes the full size of a sparse file burns the storage savings that made checkpointing efficient. The test that actually matters here is simple: agent scaffolding, tools, and libraries were written against full POSIX semantics, and they only run unmodified on a filesystem that delivers all of it. A filesystem that demands SDK changes or code rewrites brings back the exact migration cost the whole approach was supposed to avoid.

How a cloud-native filesystem connects to object storage

Whatever solves this has to sit in front of the object storage that already holds the data, not ask teams to move that data somewhere new first. Most enterprise data already lives in S3, GCS, Azure Blob, or R2, and any persistence layer that requires migrating it before it's usable adds exactly the upfront cost the "no ETL, no code changes" pitch is supposed to avoid. The working architecture points the filesystem at an existing bucket and mounts it directly: the bucket stays the source of truth, the filesystem layer supplies the POSIX interface on top of it, and no second copy of the data sits anywhere outside the customer's own account. Writes get replicated before the call returns to the agent, then flush to the bucket asynchronously, so there's a real durability guarantee without the agent stalling on a round-trip to object storage every time it saves something. Cloud-agnostic mounting matters for teams running across more than one cloud: S3, GCS, R2, and Azure Blob should all mount the same way, with no separate migration step or ETL pipeline per cloud, because context stuck inside one cloud's storage just recreates the silo this whole approach is meant to break down. Data residency stays a customer decision under this model too: cache nodes sit near the compute that uses them, and nothing moves across regions unless it's explicitly configured to, which matters for regulated industries where data sovereignty rules apply at the storage layer itself. Access can also be revoked cleanly, since the vendor never holds a persistent copy outside the customer's account in the first place, so cutting off access just leaves the data exactly where it already was. Archil is built on exactly this architecture: point it at an existing bucket on S3, GCS, R2, Azure Blob, or another S3-compatible store such as Wasabi, Backblaze B2, or DigitalOcean Spaces, mount it as a POSIX filesystem, and the agent's workspace is durable immediately, with no migration, no ETL, and no code changes required.

Serverless execution as the missing piece for agent workspaces

A durable filesystem solves where an agent's state lives, but an agent that writes a script still needs somewhere to run it, and a separate sandbox brings the session boundary right back in through the execution layer. If an agent writes a script to its filesystem in one session and needs to run it in the next, a sandbox that spins up fresh for each session has to re-stage that filesystem before anything can execute, which recreates the exact problem the durable workspace was supposed to solve. The cleaner design treats execution as a service attached directly to the filesystem, accepting bash commands and returning results, with compute attached to the data. Under that design, an agent can read, write, and run commands against the same persistent workspace across sessions and across parallel runs, with no separate coordination needed between a storage system and a standalone compute environment. All of this requires execution that scales to what the agent actually needs at that moment, rather than a pre-provisioned VM that has to stay running between sessions just in case. Archil ships serverless execution directly alongside its filesystem, so an agent can run commands against its filesystem without standing up a separate sandbox, which makes the filesystem a complete persistent context and not just a place to store files. The billing follows the same logic: elastic storage charged on what's actively cached lets a workspace grow from a small footprint to a large one without anyone pre-provisioning capacity, since an agent's actual memory needs aren't known ahead of time anyway.

The boundary of where a filesystem stops being the right answer

This argument applies to unstructured and semi-structured working state, not to every kind of data an agent touches, and treating it as a universal replacement for databases would undersell both tools. Anything with a clean, query-able schema, such as user profiles, transaction records, or a structured knowledge base, is served better by a relational or graph database with proper indexing and real query semantics. The filesystem's advantage is clearest specifically with logs, drafts, code artifacts, intermediate outputs, and research notes: data that doesn't fit a schema and doesn't get more useful by being forced into one before an agent can touch it. Vector stores still do their job well for semantic similarity search across a large corpus, when an agent is searching for something relevant it has no direct path to. The filesystem doesn't compete with that kind of search; it removes the need to re-inject context that was never lost. The practical line to draw: if the agent already knows where to look, a filesystem path beats a vector query on speed and reliability every time, and if the agent needs to discover something buried in a large unstructured corpus, embeddings remain the right tool for that job. Healthcare, finance, and government systems show this complementarity clearly. Clinical notes, financial documents, and government records become usable to an agent through a filesystem layer without anyone having to design a schema for them, while structured patient records and transaction data stay in databases where they belong, and the two layers run side by side in the same production system without conflict.

Matching persistence architecture to agent workload type

Choosing the right persistence architecture comes down to what kind of state an agent is carrying and whether that state needs to survive across sessions, get shared across multiple agents, or get discovered gradually through exploration. An agent working on a persistent project, such as a codebase, a research corpus, or a long-running analysis, fits a durable shared filesystem well, since state just accumulates in place and multiple sessions or multiple agents can work against the same workspace with no re-injection pipeline required. The clearest signal that a filesystem is the right primitive: the agent's actual work product is files, its state builds up across sessions rather than resetting, and the main way it fails is losing context it built over time, not failing to retrieve one specific fact. For teams whose agents work on persistent projects against data that's already sitting in object storage, mounting that storage as a durable POSIX filesystem, with serverless execution attached, removes the re-injection pipeline entirely and makes the agent's workspace the actual source of truth rather than a reconstruction of one, which is the specific gap Archil is built to close.