Why Coding-Agent Memory Is Not Enough: Agents Also Need Durable Task State

The real failure

The failure was not that the agent had forgotten a useful fact. A session ended in the middle of work, and the next session could not reliably tell the difference between what had been discussed, what had been attempted, and what had actually been verified.

A transcript contained the conversation. A summary described the broad outcome. Neither was authoritative for the questions that mattered: which step was active, which requirement was incomplete, which files changed, which checks passed, and what the next agent should do first.

That is how an apparently finished task gets reopened, repeated, or quietly left half-done.

Why transcripts and summaries are insufficient

Transcripts are historical records. They contain useful detail, but they are noisy, long, and not designed to be the source of truth for a task.

Summaries are easier to read, but they compress away important distinctions. “Authentication was updated” does not say whether the change was tested. “The migration is complete” does not identify the command that verified it. “The next step is deployment” may be stale if another session changed the repository afterward.

Neither format provides safe state transitions. A transcript cannot reject a stale update. A summary cannot require evidence before a step becomes verified.

Historical memory versus current state

Historical memory answers questions such as how a bug was fixed before, which convention a repository follows, or why a file changed.

Current task state answers different questions: what the active objective is, which ordered step is pending, what decisions and failures belong to this task, which evidence supports verification, and what checkpoint or handoff the next agent should use.

Termyte treats those as different kinds of information. Memories are supplemental. Authoritative task state is primary when a task is active. This prevents a relevant historical memory from overruling the current plan.

The Termyte architecture

Termyte records agent activity as traces, then keeps derived records connected to their sources. Alongside that historical pipeline, it stores explicit task state:

1. A task has an objective, requirements, and ordered steps.
2. Decisions, failures, checkpoints, and verification evidence are recorded against that task.
3. Updates use an expected version, so stale writes can be rejected.
4. Resume packets compile current task state and account for workspace drift.
5. Handoffs persist the state needed by another supported agent.
6. Historical memories are added as context, but do not replace authoritative task state.

The important design choice is not “memory everywhere.” It is the boundary between what happened before and what is true now.

A real Claude Code → Codex handoff

Claude Code can create and work on a task, then checkpoint it before handing it to Codex:

termyte task create --repo my-project --title "Finish authentication migration" --objective "Move authentication to the new provider and verify the production path"

termyte task add-step --task TASK_ID --title "Update the provider adapter" --position 1 --version 1
termyte task add-step --task TASK_ID --title "Run integration verification" --position 2 --version 2

termyte task checkpoint --task TASK_ID --workspace C:\\work\\my-project --platform claude-code
termyte task handoff --task TASK_ID --source claude-code --target codex --workspace C:\\work\\my-project

Codex can start by compiling current state rather than guessing from a transcript:

termyte task resume --task TASK_ID --workspace C:\\work\\my-project

The packet can include the objective, ordered steps, decisions, failures, evidence, checkpoint information, and detected drift. Codex still has to do the work. Termyte does not pretend a handoff is completion; it makes the starting state explicit.

Step verification also requires explicit confirmation and evidence. “The agent said it passed” and “the user verified the step” are not the same event.

Honest limitations

Durable task state solves a narrower problem than general agent memory:

• It only knows activity captured through a configured integration.
• Workspace drift can still require human judgment.
• A checkpoint records a state; it does not freeze the repository.
• A handoff transfers task information, not the previous agent’s full capability or context window.
• Historical retrieval is bounded and may abstain.
• Recorded evidence does not prove that context caused a successful outcome.

The point is not perfect continuity. The point is to stop treating a transcript, a summary, and a current task plan as interchangeable.

Install Termyte

npm install -g termyte
termyte init

Then open the local viewer to inspect sessions, tasks, evidence, memories, and handoffs:

termyte viewer

Tell us where this breaks

Try one real handoff: end a session before the task is complete, resume it with another supported agent, and compare the result with what you would have reconstructed from the transcript alone.

What state was missing? Which evidence was unclear? Did the next agent start from the right step? Send the failure case, not just the success story. That is the feedback needed to make durable task state genuinely useful.