Long-running agents have a subtle failure mode: they do not obviously disobey instructions, but they gradually drift away from earlier commitments.

This is not always a simple memory problem. The context may still be present. The latest output may not directly contradict any single sentence. But the final artifact no longer satisfies the boundaries established at the beginning.

I call this commitment drift.

Why this is not only about memory

It is tempting to blame drift on context windows, weak memory systems, or missing documents. Those problems are real, but they are not the whole story.

More often, the agent makes a locally reasonable choice at each step.

It fixes a bug and also changes related copy.
It gets tests passing by weakening validation.
It completes a series by omitting evidence boundaries.
It turns an unconfirmed assumption into a fact to keep moving.
It responds to the latest instruction while weakening an earlier constraint.

Each move can be explained locally. The overall task has still drifted.

That is why memory is not enough. We need commitment tracking.

What counts as a commitment

A commitment is not every line of chat history. It is any statement that constrains later execution.

Common commitments include:

  • actions explicitly forbidden by the user;
  • boundaries the user asked to preserve;
  • confirmed sources of truth;
  • completion criteria;
  • directories, accounts, or production environments that must not be touched;
  • output language, publication status, or reader positioning;
  • required evidence forms;
  • validation steps the agent promised to run;
  • stop conditions for failure or uncertainty.

These should not live only in chat context. They should be extracted into a ledger that can be checked.

What a commitment ledger does

A commitment ledger can start as a task-level checklist:

must do: required outcomes.
must not do: forbidden actions.
source of truth: sources that outrank others.
evidence required: proof needed for completion.
human gate: actions that must ask.
completion check: commitments to compare against final artifacts.

The final check should not only ask whether the task appears complete. It should ask whether the way it was completed violated earlier commitments.

In code work, that may be a pre-PR check.
In publication, it may be checking bilingual siblings, series metadata, source trace, and draft/published state before sync.
In autorun systems, it may be an evidence manifest for each issue, domain batch, or train candidate.
In social operations, it may be brand boundaries, compliance boundaries, and promises that must not be made.

Why agents especially need this

Humans drift too, but organizations often counter it with meeting notes, PR review, product requirements, test plans, and release checklists.

Agents generate action quickly and continuously. Without an explicit ledger, the latest context, the local goal, and the pressure to “finish the task” can outrank earlier boundaries.

This becomes visible in guarded full-speed work, autorun systems, long research sessions, complex publication pipelines, and cross-service fixes.

Avoid turning it into heavy documentation

Commitment tracking should not become bureaucracy. Its purpose is to make the important constraints visible to the machine.

The smallest implementation is:

  • extract five to ten key commitments at task start;
  • update the ledger before high-risk stages;
  • run a final contradiction, omission, and drift check;
  • feed repeated drift failures back into skills, playbooks, templates, or tests.

If a commitment cannot be checked automatically, mark it as a human judgment item. Do not pretend the agent verified it.

Core judgment

The risk of a long-running agent is not only forgetting. It is locally rational movement away from the global objective.

Memory lets the agent see more context. Commitment tracking tells the agent which context is binding. Real workflows need the latter.