DEV Community: Vincent Tuan

Long-Running AI Agents Accumulate Context Debt

Vincent Tuan — Mon, 03 Aug 2026 07:46:55 +0000

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.

More Tools Can Make Your AI Agent Slower

Vincent Tuan — Sat, 01 Aug 2026 13:15:48 +0000

A renewal agent can call the CRM, email, calendar, support, document search, and contract systems. On its first run, it asks every system for everything related to one customer.

The result looks thorough: hundreds of CRM fields, years of ticket history, complete email threads, and the same contract attached to several messages. But the agent now has to spend time and tokens deciding which records matter before it can make progress on the renewal.

The agent is well connected. It is also slower, more expensive, and less certain.

Adding a tool expands what an agent can reach. It does not guarantee that the agent can select the right capability, retrieve a bounded result, or preserve enough of its execution budget to finish the task.

Tool schemas consume attention before the first call

An LLM needs the name, description, and input schema of each available tool before it can choose one. When several tools expose similar actions, selection becomes a routing problem.

Consider a broad interface like this:

{
  "name": "manage_account",
  "description": "Search, update, assign, add a note, change a stage, or create a task for an account",
  "parameters": {
    "account_id": "string",
    "operation": "string",
    "query": "string",
    "fields": "object",
    "assignee": "string",
    "stage": "string",
    "note": "string",
    "due_at": "string"
  }
}

It appears flexible, but every call asks the model to infer which combination of optional parameters represents the intended action. Validation and permissions must then account for every mode hidden behind the same interface.

A task-shaped read is less ambitious:

{
  "name": "get_renewal_record",
  "description": "Return the approved renewal view for one customer, including source timestamps",
  "parameters": {
    "customer_id": "string"
  }
}

The narrower tool is easier to select, permission, test, and recover. It may require additional orchestration steps, and it will not cover every future account workflow. That is a real tradeoff. The benefit is that each supported step carries less ambiguity.

Tool count therefore has two costs before execution begins:

every schema occupies context;
overlapping descriptions increase routing uncertainty.

Neither cost appears in a dashboard that reports only the number of connected systems.

Connectivity does not control the response shape

Suppose the CRM API returns 180 fields for an account. The renewal decision needs eight:

renewal date;
contract value;
account owner;
current stage;
product set;
open commercial risks;
last verified customer contact; and
source timestamps.

Passing all 180 fields to the model moves a data-selection problem into the most expensive part of the workflow. The same failure appears when an email connector returns complete message bodies instead of headers and short extracts, or when a document connector sends the same attachment once for every message that references it.

Each unnecessary value consumes something. It uses tokens when placed in model context, storage and transfer when retained outside it, and reasoning attention when the agent has to filter it.

The connector should return a task-shaped view:

{
  "customer_id": "cus_1842",
  "renewal_date": "2026-09-30",
  "contract_value": {
    "amount": 120000,
    "currency": "USD"
  },
  "account_owner_id": "usr_291",
  "open_risk_ids": ["risk_17"],
  "source_updated_at": "2026-07-29T08:42:10Z"
}

Raw records can remain available for inspection without being injected into every prompt. The agent can retrieve full email bodies or documents only after a bounded search identifies the relevant records.

Prompting the model to “focus on what matters” does not repair an oversized payload. By that point, the system has already paid to retrieve and expose the data.

MCP standardizes exchange, not business meaning

The Model Context Protocol gives compatible systems a common way to expose tools and context. That interface boundary is useful, but it cannot decide what a renewal agent needs from a CRM or which source should win when records disagree.

An MCP server can expose a technically valid tool that still returns the wrong slice of the system. It does not automatically answer questions such as:

Is this the current policy or an archived version?
Does the response include all pages?
Can this write be retried safely?
Do two records represent the same customer?
Is the caller allowed to see the underlying support incident?

Protocol compatibility and context quality are different properties. Standardizing the call does not remove the need to design the tool contract around the business task.

Pagination can make an incomplete result look complete

The agent asks for all open support tickets. The API returns 50 records and a continuation token.

If the tool output does not expose that token clearly—or its contract does not say when pagination is required—the first page can look like the complete result. The agent may produce a confident renewal summary while missing the ticket that explains the account risk.

“Fetch every page” is not always the right correction. An account with years of activity may have thousands of records. The workflow needs a completeness condition, such as:

retrieve all open tickets;
stop after the relevant date boundary;
continue until a known record is found; or
escalate when the result exceeds the reviewable limit.

The condition belongs in the workflow and tool contract. Otherwise, the model has to invent one at runtime.

Retries are part of the tool interface

Reads and writes fail differently.

If a CRM read times out, another attempt may be harmless. If a request to create a follow-up task times out after the server commits it, retrying can create a duplicate. Refusing to retry leaves the agent uncertain about whether the action happened.

A production write tool needs explicit answers:

Did the request fail before or after execution?
Does the operation accept an idempotency key?
Can the agent look up the committed action?
What evidence identifies a successful write?
Which errors require a person rather than another attempt?

These details rarely matter in a short demo. They matter as soon as an agent changes business state.

Measure accepted outcomes, not available tools

A useful evaluation starts with one outcome—for example, prepare a renewal brief with current commercial terms, unresolved support risks, source references, and an escalation when required evidence is missing.

Then measure the system that produces it:

latency per accepted brief;
tokens and tool calls per accepted brief;
incomplete or duplicated records;
unsafe or unnecessary retries;
reviewer corrections; and
cases escalated because a capability was intentionally unsupported.

Removing a broad tool may leave an edge case unavailable until the team designs a safer capability. A bounded agent that identifies that limit is often more dependable than one that guesses its way through a large tool catalog.

The practical question is not “How many systems can the agent call?” It is “Does each connection return the right information or perform the right action under conditions we can test?”

That is the distinction between an agent that looks capable in a tool list and one that can finish a workflow without losing control of cost, latency, or business state.

This article was adapted for the DEV community from More Tools Can Make an Agent Slower, originally published by Coryntas.