Every Claude session starts from zero. There is no memory of what happened an hour ago, no record of the decision you made on Tuesday, no awareness that the architecture you discussed last week has already been built and deployed. When you open a new conversation, the model is, from its own perspective, meeting you for the first time.
For a one-off task -- summarize this document, fix this function, answer this question -- that is fine. The cost of a blank slate is zero when the task lives entirely within a single session. But the moment your work spans multiple sessions, the blank slate becomes something you pay for, repeatedly, in time and attention.
I discovered just how expensive that payment is when I built a fleet of ten scheduled agents to run autonomously around the clock.
What re-orientation actually looks like
When an agent starts a session without any memory of prior work, the first thing it does is reconstruct context. It reads files to understand what was done before. It checks logs. It inspects recent git history. It infers the current state of the system from artifacts rather than from its own prior knowledge. None of that is useful work -- it is overhead, paid up front on every run.
In a single-agent setup, this is annoying but manageable. You paste in a summary, you remind the model what you were doing, you lose a few turns getting it back up to speed. The human pays the cost manually, and the cost is bounded by how much you can hold in a single paste.
In a fleet of agents running on a schedule, the math changes. Each agent runs independently. Each one starts from zero. Each one spends the opening turns of its session re-discovering the current state of the world before it can do any real work. Multiply that overhead across ten agents, each running once or twice a day, and the pre-work accumulates fast -- even with session memory already in place, agents in our fleet average 15 turns before beginning their first substantive task.
The categories of loss
Context loss is not one thing. When I looked at where the actual cost was accumulating across the fleet, it fell into three distinct categories.
The most visible category is work duplication. Without memory of prior sessions, an agent will occasionally re-do work that was already done -- not because it is careless, but because it genuinely has no signal that the task is complete. A builder agent that drafted a document last Tuesday has no way to know, when it wakes up on Thursday, that the document exists unless something in the current environment makes that fact explicit. If the artifact is easy to miss, the agent finds another path to the same destination.
The second category is decision drift. A system with ten agents making autonomous decisions accumulates judgment calls. The choice of file format, the naming convention for a new module, the threshold for when an anomaly should be escalated -- these decisions get made once and should propagate forward. Without memory, each agent that encounters a similar choice re-derives it from scratch, and not always to the same conclusion. Over time, decisions made without access to prior decisions produce a system that is internally inconsistent in ways that are hard to diagnose.
The third category is context re-injection cost. This is the overhead of trying to work around the blank-slate problem manually -- passing summaries in prompts, writing state to files the next agent will read, maintaining an ever-growing initialization ritual. These workarounds work, but they consume both tokens and human attention to maintain. They also tend to degrade over time as the initiative required to keep them current falls behind the pace at which the system evolves.
What persistent memory actually fixes
When I added LoreConvo to the fleet, the auto-save hook began capturing each agent's session context at the end of every run: the summary of what was done, decisions made, open questions left pending, and technical facts about the system that were true at session end. The auto-load hook pulled that context forward into the next session before the first tool call.
The effect on re-orientation was immediate and measurable. Agents that previously spent the opening turns of a session reading files to reconstruct state could instead start from a known-good summary of where they left off. The first turn that would have been "let me check the recent git log" became the first turn of actual work.
What surprised me more was the effect on decision consistency. Because prior decisions were now part of the session-start context, agents encountering similar choices later in the day had access to the judgment calls their counterparts had made earlier. The system started to behave more like a team with shared context and less like ten independent contractors who had never met.
Full-text search across saved sessions also changed how I debugged problems in the fleet. When something went wrong and I needed to understand the sequence of events that led there, searching sessions by keyword pulled up the relevant context immediately. "What did the builder agent decide about the schema for X?" -- answered in one search, not five minutes of git blame.
The numbers that matter
I want to be careful here about what is measured versus estimated, so I will separate the two.
What I measured directly: across 761 agent sessions -- all running with LoreConvo already active -- agents spend an average of 15 turns before beginning their first substantive work item. That is roughly 20% of a typical session. For complex, high-context agents that coordinate across many systems, the number runs higher: the marketing agent averages 25 turns of pre-work, and the project management agent averages 31. Those turns are not idle -- they represent file reads, inbox checks, and state reconstruction that must happen before useful work is possible. They are the floor, not the ceiling.
The orientation pattern is also visible in the file access data. Across all sessions, 23% of file reads are orientation documents -- skill files, playbooks, status trackers -- rather than active work artifacts. Read operations account for 25% of all tool calls fleet-wide, compared to 14% for Edit and Write combined. That ratio reflects what agents actually spend time doing before they produce anything.
What I cannot measure directly: how much worse these numbers would be without session memory. The fleet was built with LoreConvo from the start, so there is no pre-memory baseline to compare against. What I can say is that the 15-turn pre-work average represents a system that already has prior session context loaded at startup. The alternative -- agents reconstructing state from git history, log files, and ticket records with no summary to start from -- would push that number higher. The 23% orientation-read figure is the floor, not what unconstrained re-orientation looks like.
The design choice underneath all of this
Local-first, single-file storage was not an incidental design choice for LoreConvo. It was the decision that made the fleet use case viable.
A cloud-dependent memory system would introduce a network call at the start of every agent session. For a fleet running on a schedule, that means ten agents, each making multiple network calls per day, each dependent on an external service being available. The reliability requirement compounds with the number of agents. A local SQLite file has no network dependency, no authentication round-trip, no service availability to monitor. It is there when the agent starts, always.
The portability is also a practical benefit that I underestimated at first. The entire memory of the fleet -- every session, every decision, every open question -- lives in a single file that I can back up, inspect directly, or hand to another system. There are no lock-in concerns, no vendor APIs to reverse-engineer if I want to migrate. The data is mine in the same way a file on my hard drive is mine.
Where to go from here
If you are running scheduled agents or multi-session workflows and you are spending meaningful time in session setup re-establishing context that should carry forward automatically, that overhead is reducible. The auto-save and auto-load mechanism in LoreConvo handles the boundary between sessions; you configure it once and the context starts moving forward on its own.
The export and import tools let you back up session state and migrate it between machines -- both are free-tier features. For teams running the same agents across multiple machines, LoreConvo Pro adds coordinated session sharing: teammates run loreconvo merge to incorporate exported sessions locally, with no shared server required and data staying on-device throughout.
The fleet pattern -- scheduled autonomous agents coordinating through shared memory -- is one way to run a system like this. It works. The memory layer is what makes it coherent.
See what is available at /tools if you want to start with the single-agent case and build up from there.