An engineering note from the team building Shepherd. Updated September 8, 2026.
You ask an agent to make a change, start a test run beside it, and move on to something else. Later, you close the application. When you return, the natural expectation is that the work is still there.
That expectation sounds small. Meeting it changes how a terminal workspace has to be built. A window is temporary: people open it, close it, move it, and reconnect to it. A task has its own lifetime. We built Shepherd around that distinction.
Work has a different lifetime from its window
A coding session contains more than the text currently on screen. There is a running program, an environment around it, and a place in the project where it belongs. Recreating the visible arrangement does not necessarily preserve any of those things.
This matters especially when agents are involved. Work can continue for long stretches without keyboard input. Having to keep a particular window open becomes an invisible dependency: the user has to remember which interface is responsible for keeping which job alive.
Our design moves that responsibility out of the window. The interface should help you observe and direct work while it is open. Its presence should not be the condition that allows the work to continue.
Give the session an independent home
At a high level, Shepherd separates the visible workspace from the part of the system that maintains a terminal session. The session has an owner whose lifetime is independent of the desktop view. Opening a window attaches a view to that work; closing the application removes the view without making that the default end of the session.
That separation gives us a clearer set of responsibilities. One part maintains the running terminal. Another organizes projects and sessions. The interface presents the current state and carries the user’s input back to the right place.
The useful result is familiar: you can step away and return. The engineering decision underneath it is to treat the session as a continuing resource, with the application as one way to reach it.
Reconnecting means finding the same work
An independent lifetime is only half the problem. On return, the interface needs to find the correct session and show its current state. A tab with the old name is not sufficient evidence that the original task is still running.
We keep the identity of the session separate from its presentation. This lets the workspace reconnect to existing work instead of treating every new window as a request to start another shell. The view then catches up with the terminal it has rejoined.
This is also why we distinguish a live session from saved output. Old text can help explain what happened, but the ability to send input to the continuing process is a different kind of continuity.
Closing the app and ending the task are different actions
Once sessions outlive the interface, ending work needs its own meaning. Closing the application is not the same decision as explicitly closing a terminal or stopping its process.
We carry that distinction into the lifecycle of the workspace. A temporary loss of the view should not silently become a request to destroy the resource behind it. Equally, a session that has actually ended should not be presented as a healthy running task merely because its previous layout can be drawn again.
The boundary matters: persistence does not make an execution host immune to shutdown, a process immune to failure, or a local task continue through system sleep. For work to proceed while a client is away, the machine running it must remain able to execute it.
Continuity reduces the work of returning
The purpose of this architecture is to reduce how much you have to reconstruct when you come back. You should be able to ask what happened and what needs your attention, with the original working context still within reach.
That leads directly to another design problem: once several tasks can keep running independently, how do you know which one needs you? Our approach to monitoring coding agents starts with that question. The workspace context story explains how we keep the task connected to its place in the project.
Your next workspace
Put it to work.
Try Shepherd on an Apple silicon Mac. The iOS app is currently listed as coming soon.
Get Shepherd for Mac