2026-08-16

A Coding Session Is Not Factory Memory

A long coding session can feel like a system. It remembers the discussion, holds the plan, and keeps moving. Then the session ends, and you find out how much of the system only existed in the conversation.

The session is a workbench

Good session discipline matters. A clear objective, relevant context, deliberate course corrections, and a clean stopping point all help an agent do better work. If you are operating an assistant by hand, those habits reduce wasted motion and keep the conversation from collapsing under its own history.
But that is operator technique, not factory architecture. The session is a temporary workbench. It is useful because the current task, recent decisions, and active tools are close together. It becomes dangerous when the organization treats that temporary arrangement as the durable place where the work is understood.
A factory has to survive the loss of any one workbench. Another agent must be able to take the next task without reconstructing the last conversation. A reviewer must be able to judge the result without trusting the agent's summary. An interrupted run must restart from recorded state instead of somebody's memory of where it stopped.

Context has a carrying cost

More context is not free understanding. Every extra instruction, transcript, file, and tool result competes for attention inside the run. Some of it is essential. Some is stale. Some describes a decision that should already have become code, a test, a policy, or a checked artifact. Keeping all of it alive makes the session heavier without making the system smarter.
This is an inventory problem. The factory should bring in the smallest body of current material that lets the agent act correctly, then move durable results back out. Requirements belong in an executable specification. Standards belong in enforced checks. Decisions belong in records other workers can retrieve. Evidence belongs beside the change it proves.
When a conversation carries all four, you pay for the same understanding again on every run. You also make recovery depend on a model interpreting a growing pile of prose the same way twice. That is not memory. It is a recurring reconstruction bill.

Compression does not create state

Summarizing a session can extend useful work. It cannot turn the session into an operating record. A summary chooses what to keep before the next failure reveals what mattered. It may preserve the plan while dropping the rejected alternative, the boundary that stopped a bad change, or the observation that explains why a test exists.
The factory needs state with consequences. A completed step changes the task record. An accepted decision changes the specification. A failed check blocks release and leaves evidence for the next attempt. A permission is granted through a control the agent cannot rewrite in its own narrative. These are not nicer notes. They are transitions in the machinery.
That distinction is what allows sessions to stay short. The agent does not need the full biography of the project when the system can present the current task, the relevant constraints, and the proof required to finish. Fresh work starts from durable state instead of inheriting a transcript and hoping the important parts survived compression.

Build the return path

The practical test is simple: end the session on purpose. Can a different worker tell what changed, why it changed, what remains open, and which evidence is authoritative? Can it resume without asking a person to retell the story? Can the verification run somewhere the original agent did not control? If not, the session is still doing work your factory should own.
Start by separating inputs from outputs. Assemble task context from versioned sources. Give the agent bounded tools and a finish condition. Require it to return changes, decisions, and evidence through explicit write paths. Let automated gates decide whether those outputs advance the job. Preserve failures as routing information, not as paragraphs buried in chat history.
Our position is that the best coding sessions will get shorter as factories get better. Not because the models need less information, but because the machinery will deliver the right information at the right step and retain the result after the worker leaves. The conversation can disappear. The capability compounds only when the system remembers.