Sessions Are Not Chat Logs: Engineering the Unit of Execution

The previous section discussed memory engineering, but memory alone is not the complete answer. You can persist knowledge, yet still lack a critical abstraction: what exactly is being saved, resumed, interrupted, or migrated? Without answering this question, so-called "long-running" operations inevitably degrade into a pile of scattered transcripts, temporary files, and ad hoc human conventions.

In Harness Engineering, what truly needs to be engineered is not the "chat log" but the Session. If the model is like a CPU and the Harness is like an operating system, then the Session is closer to a process. It is not simply an array of messages, but a complete unit of execution: the current objective, context state, tools in use, bound files, intermediate outputs, and runtime constraints should all be encapsulated within this unit.

A minimally viable Session must contain several categories of information. The first is context state: system prompt, conversation history, and working memory. The second is associated resources: which files it is reading and writing, which databases or MCP services it depends on, and which tools it can invoke. The third is metadata: name, priority, creation time, last active time, and owning Agent. The fourth is lifecycle state: running, suspended, sleeping, or terminated. Only when all of this information is bundled together can a Session be considered an object that can be recovered, scheduled, and governed.

With this definition of Session, an important distinction becomes clear: a Session is not an Agent. An Agent is a role or identity; a Session is a specific unit of work in that role's hands. An HR Agent might simultaneously own three Sessions: "monthly payroll," "recruitment screening," and "social insurance filing." They belong to the same Agent but should have entirely different contexts and boundaries. Mixing all of these into one super-long conversation only causes cross-contamination of context; splitting them into dedicated Sessions is the only way to truly control complexity.

This is also why Sessions are the key abstraction for solving context explosion. Many teams' first instinct is to give the Agent a larger context window and stuff more material into it. But the truly scalable approach is not unlimited expansion; it is slicing work into multiple dedicated, independent Sessions. Each Session serves a single clear objective and binds only the minimal context needed to achieve it. The HR payroll Session binds the salary table, social insurance base rates, individual tax rules, and last month's results. It gets activated on the first of each month, completes its computation, suspends, and waits for the next activation. It does not need to know about interview scheduling, nor should it be disturbed by that information.

Once you treat Sessions as units of execution, a set of operational primitives naturally emerges around them. The most basic are save, load, and compress, which let a Session survive across conversations. Going further, there are activate, suspend, interrupt, and cancel, which enable scheduling. Further still, fork, merge, send, and migrate allow Sessions to branch into side quests, move across models, and communicate with each other. These operations do not all need to be implemented from the start, but they give the Harness a clear system call table rather than continuing to rely on ad hoc scripts and manual gestures.

Sessions also have a frequently overlooked but important dimension: dependencies. A Session depends not only on its prompt but also on its surrounding environment. If the spec, code directory, or configuration files it is bound to change, the Session may need to be reactivated. This means Heartbeat evolves from mechanical polling toward event-driven activation. An API documentation Session can be woken up after a new commit lands in the src/ directory; a payroll Session can automatically recalculate after the social insurance base rate table is updated. Sessions transform from "passive archives" into "responsive units of work."

Of course, this analogy is not perfect. Processes in an operating system are deterministic; Sessions are not. Process state can be precisely snapshotted; Session compression and restoration are often lossy. Merging two processes raises no semantic issues; merging two Sessions can produce conflicting viewpoints. But this is not a reason to abandon the abstraction. It only means that Session system calls must be more conservative and more explicit than POSIX. Implementing only the highest-value operations in the first version is far more realistic than pursuing full virtual-machine-style migration from the outset.

From here, we naturally arrive at the topic of the next chapter. Multi-Agent collaboration is not just "opening more chat windows." It is multiple Agents, each owning a set of Sessions, coordinating through isolation, contracts, and integration mechanisms. Without Sessions as an intermediate layer, multi-Agent systems quickly degrade into a mass of temporary conversations that are difficult to schedule, difficult to recover, and difficult to govern.