# Persistent desks: stop making your agent start from zero Source: https://bszczyglo-landing.vercel.app/blog/persistent-desks Author: Bartłomiej Szczygło Published: 2026-07-15 Format: Deep Dive Topics: agent-infrastructure Term introduced: persistent desk > A stateless agent re-clones the repo, re-installs the dependencies and re-derives the same conclusions on every run. Giving it a durable workspace — a desk that survives the session — removes more failure modes than a bigger context window ever will. Watch a stateless coding agent work twice on the same repository. Run one: clone, install dependencies, read the project structure, discover that the test command is non-standard, fix an environment quirk, do the task. Run two: clone, install dependencies, read the project structure, discover the same non-standard test command, hit the same environment quirk, do the task. Everything except the task itself was rework. And the second run is not just slower — it is *worse*, because the agent burned attention rediscovering context instead of spending it on the problem. ## The naive fix is memory, and it does not work The instinctive response is to give the agent memory: a vector store of past runs, a summary file, a larger context window. I have built all three. They help at the margins and they miss the point. The thing a working agent accumulates is not primarily *knowledge*. It is *state*: - an installed toolchain that took four minutes and one network flake to get right - a cloned repository with the right branches and a warm build cache - a virtualenv or `node_modules` tree that matches the lockfile - an authenticated CLI session - a half-finished worktree from a task that was interrupted None of that fits in a context window, and none of it is recoverable by remembering harder. Retrieval gives an agent the sentence "the tests need a local Postgres". A desk gives it a machine where Postgres is already running. ## The persistent desk A **persistent desk** is a durable workspace bound to an agent identity rather than to a session. Same path every time, same contents as when the last session ended, surviving restarts and redeploys. In practice that means a handful of conventions: - A stable root directory that the agent knows is its own. - `repos/` for long-lived checkouts, so the expensive clone happens once. - `notes/` for things the agent writes to its future self — decisions, gotchas, plans in progress. - A manual at the root describing the environment: what is installed, what is not, which shortcuts exist. The agent reads it at the start of a session and updates it when the environment changes. - Dependencies installed *on the desk*, never in a container layer that resets. The result is an agent whose first minutes are useful instead of ceremonial. ## Second-order effects The interesting part is not the saved minutes. It is what a desk makes possible. **Resumability.** An interrupted task leaves artefacts on disk. A new session can look at the worktree, read the notes and continue instead of restarting. Long jobs stop being all-or-nothing. **Honest self-documentation.** When an agent knows its notes persist, writing them down has a payoff. Session summaries stop being theatre and start being infrastructure. **Cheaper context.** Instead of stuffing a project description into every prompt, the agent reads the desk manual on demand. Context becomes something the agent *fetches*, not something you *pre-load*. **Real tool state.** Authenticated CLIs, warm caches, generated fixtures — all the things that make a human developer fast, made available to an agent for the same reason. ## What breaks Persistence is not free, and the failure modes are specific. **Concurrency.** The moment two instances of the same agent share a desk, they will edit the same file. The fix is boring and mandatory: every task gets its own git worktree, never the shared checkout. Without that rule, a desk turns into a merge conflict with a filesystem attached. **Drift.** A desk accumulates junk: abandoned branches, stale virtualenvs, half-downloaded artefacts. Something has to clean up, and "the agent will remember to" is not a plan. Bake tidy-up into the end of a task, not into good intentions. **Stale beliefs.** A desk manual that lies is worse than no manual. If the agent installs a tool, the manual has to change in the same session, or the next session will confidently do the wrong thing. **Blast radius.** A durable workspace with authenticated sessions is a durable target. Desks want the same isolation you would give a build server: one identity, scoped credentials, no shared secrets between agents that do not need them. ## Why this is infrastructure, not a feature Most agent frameworks treat the workspace as a temporary directory — an implementation detail of a run. That choice quietly decides what your agents can be. Ephemeral workspaces produce agents that answer questions. Persistent workspaces produce agents that *maintain things*: a repository, a pipeline, a backlog, a service. If you want the second kind, the desk is not an optimisation you add later. It is the first thing you build.