An illustrative reporting agent prepares a monthly operating review. It queries finance, CRM, support, and the data warehouse; compares this month with prior periods; investigates material changes; drafts explanations; collects owner comments; and revises the report over several days.
By the third revision, its context contains raw query results, discarded hypotheses, repeated instructions, old owner comments, and the current draft. The most important correction—a finance owner rejecting the original revenue explanation—now competes with everything that came before it.
The agent has not run out of intelligence. It has accumulated context debt: temporary execution material has become permanent reasoning input.
The context window is a working surface, not the system of record
Keeping every intermediate result in the model context feels safe because nothing is lost. In practice, relevance declines as a run grows:
- large tool responses consume tokens;
- old instructions conflict with newer decisions;
- repeated summaries introduce small distortions;
- rejected hypotheses remain close to accepted findings; and
- the current deliverable becomes harder to distinguish from earlier drafts.
A larger context window delays this problem. It does not define which state is authoritative, which evidence is recoverable, or which decisions should survive a restart.
A long-running workflow needs at least four storage roles.
1. Working context
The current objective, immediate constraints, selected evidence, and next executable step belong here. This set should be small enough that every item can affect the next decision.
2. Durable task state
Completed checkpoints, owners, approvals, deadlines, open exceptions, and permitted next actions should live outside the prompt. This state must survive model calls, worker restarts, and handoffs.
3. Evidence storage
Raw source results should be retained with stable identifiers, timestamps, and access controls. The agent can reload them when a later step needs inspection without injecting every record into every prompt.
4. Deliverable state
The current report, plan, ticket, or other business artifact needs its own version history. Reviewer changes should update this artifact without turning the entire conversation transcript into the only record of what changed.
Moving material out of the prompt is not deletion. It is putting information where the runtime can retrieve it deliberately.
Compaction should preserve decisions, not merely shorten text
A generic conversation summary may retain the topic while losing the operational fact that matters: who rejected an explanation, which source replaced it, and whether the correction applies to one metric or the entire report.
A useful checkpoint is structured. For example:
{
"task_id": "monthly-review-2026-07",
"objective": "Produce an approved operating review",
"checkpoint": "finance-variance-reviewed",
"accepted_findings": [
{
"metric": "net_revenue_retention",
"explanation": "Two enterprise downgrades",
"evidence_refs": ["warehouse:q_184", "crm:acct_72"]
}
],
"rejected_findings": [
{
"explanation": "FX movement",
"rejected_by": "finance-owner",
"decided_at": "2026-08-03T09:20:00Z"
}
],
"open_questions": ["Confirm support-cost allocation"],
"allowed_next_actions": ["analyze_support_costs", "request_owner_review"]
}
The exact schema will vary. The important part is separating decisions from the tokens that produced them.
Each checkpoint should answer:
- What remains in model context?
- What moves to durable state?
- Which raw evidence can be recovered later?
- Which actions are valid from this state?
Compaction, subtask isolation, and progressively loaded instructions are mechanisms for enforcing those choices. They are not substitutes for a state model.
Subtasks need isolation and a shared contract
The reporting workflow can separate finance variance analysis, sales pipeline changes, and support-volume analysis. Each subtask receives only the systems, definitions, and period relevant to its work.
Isolation reduces interference, but it creates an integration problem. The coordinating agent cannot safely reconcile three polished narratives that use different definitions.
A shared result contract might require every subtask to return:
- metric identifier and reporting period;
- current and comparison values;
- explanation and confidence;
- authoritative source references;
- unresolved issues; and
- requested decisions or approvals.
This contract does more than improve formatting. It gives the coordinator a stable boundary for validation, comparison, and retry.
If one subtask fails, the runtime can rerun that unit without replaying the entire workflow. If a reviewer corrects a metric definition, the system can invalidate only the findings that depend on it.
Resuming is a first-class operation
A long-running agent should be tested from checkpoints, not only from the beginning.
At resume time, the runtime should be able to reconstruct:
- the current objective and accepted deliverable version;
- completed and pending steps;
- active owners and deadlines;
- the latest authoritative decisions;
- evidence references needed for the next step; and
- the permissions that are still valid.
This last item matters because authority can change while a workflow is paused. A task approved yesterday may require a new check before an agent performs the action today.
A resume test is therefore more than loading a saved prompt. It verifies that the workflow can rebuild the minimum trustworthy working set from durable state.
Context debt has an operating cost
External state introduces storage, retention, and access-control decisions. Compaction can omit a detail that later becomes important. Subtask isolation increases orchestration complexity. Reloading evidence can add latency.
Those are measurable tradeoffs. Useful signals include:
- context size by workflow stage;
- repeated retrieval of the same evidence;
- compaction corrections by reviewers;
- checkpoint resume failures;
- stale decisions used after a restart;
- evidence reload latency; and
- cost per accepted deliverable.
Some work should pause instead of compacting. If reviewers fundamentally change the objective, starting a new version with an explicit handoff may be safer than asking the agent to reinterpret a long and contradictory history.
Finish with a record another run can trust
The completed report should retain its reporting period, metric definitions, reviewer decisions, evidence references, and unresolved caveats. Next month's agent can use the accepted artifact as a comparison without inheriting all of the execution debris that created it.
Context debt appears when a system confuses memory with accumulation. Long-running agents need a maintained working set and a durable operating record—not an endlessly growing prompt.
How are you separating working context from durable task state in your long-running agents?
This article was adapted for the DEV community from Long-Running Agents Accumulate Context Debt, originally published by Coryntas.
Top comments (4)
The reframe that "temporary execution material becomes permanent reasoning input" is the cleanest one-line diagnosis of this I've read. The failure isn't token count — it's that a rejected hypothesis sits at the same salience as an accepted finding, so the model keeps relitigating decisions that were already made. A bigger context window makes that worse, not better, because now the stale material persists even longer with nothing marking it as dead.
Your structured-checkpoint example is where the real work is. A generic "summarize the conversation" pass destroys exactly the fact that matters (who rejected FX, what replaced it, whether it scopes to one metric). Keeping
rejected_findingsas first-class state with arejected_byand timestamp is what stops the agent from re-proposing the thing a human already killed. The piece I'd be curious about: how do you decide what gets promoted into the checkpoint versus left in evidence storage? That eviction policy feels like the hard part — too eager and you drop a detail a later step needed, too conservative and the working context bloats right back up. Are you doing that promotion with a rule, or is a model making the call about what survives compaction?The four-store split is useful. I would add dependency tracking between durable decisions and evidence, because “accepted” is not the same as “still valid.” If the finance owner changes a metric definition, the system needs to know exactly which findings, drafts, approvals, and downstream actions depend on that definition.
A checkpoint can therefore store a small provenance DAG: claim IDs, evidence versions, policy/definition versions, reviewer decisions, and derived artifacts. On resume, the runtime should evaluate explicit predicates such as
evidence_current,definition_unchanged,approval_valid, andpermission_valid; failed predicates invalidate only the affected descendants and create targeted work rather than silently loading stale truth.I would test checkpoint migrations too. Long-running tasks can outlive the state schema and tool contracts that created them, so resume should either deterministically upgrade the checkpoint or stop with a typed incompatibility—not reinterpret old state through new semantics.
This is a pattern we've run into with multi-step AI workflows too. The bigger issue isn't the context window it's treating the prompt as both working memory and source of truth.
At IT Path Solutions, we've had better results by making agent context disposable. Every meaningful decision (approvals, state transitions, evidence IDs, checkpoints) is written to durable state, while the prompt only contains what's needed for the next step. If an agent can't be restarted from storage without replaying the conversation, it's carrying too much context debt.
One metric that's been surprisingly useful is context reuse ratio how much of the prompt is actually referenced in the next action. When that number keeps dropping while token usage grows, it's usually a sign the workflow needs another checkpoint or a task boundary rather than a larger context window.
Context debt is a good name for it. The thing I've watched happen is that a temporary tool output from step 3 is still sitting in the window at step 40, quietly steering the reasoning long after it stopped being relevant. Treating context as append-only is the trap; some kind of active eviction or summarization pass is what's kept mine stable. What's your heuristic for deciding when a piece of context has gone stale?