deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Claude Code keeps background agents in sync by resending full transcripts to the model

A dev.to analysis argues Claude Code background agents persist state by sending each agent's full serialized transcript to the model API on every step, compounding token cost, latency and data-exposure risk.

Claude Code keeps background agents in sync by resending full transcripts to the model

How background agents remember

According to an analysis published on dev.to, Claude Code treats the underlying model as a stateless function and pushes the job of remembering onto the agent runtime. A background agent is not a single request and response; it is a state machine that persists across turns, tool calls and file-system operations. To keep the model coherent about what has already happened, the runtime serializes the agent's entire history — the transcript — and includes it in every subsequent call to the provider's API.

The post walks through a simplified execution loop and describes the transcript as a structured record of each step: the tool invoked, its inputs and outputs, timestamps, plus surrounding context such as the working directory, git status and environment variables. The author treats this as the agent's memory: without resending it, the model would have no knowledge of its own prior work.

The cost of resending everything

The central criticism is that the transcript only ever grows. Because the full history travels with each new request, every additional tool call becomes more expensive and slower than the last. The analysis identifies three effects:

  • Context limits: long-running tasks can hit the model's window, forcing truncation and potentially discarding early steps that still mattered.
  • Latency: time-to-first-token climbs as the serialized payload grows.
  • Wasted computation: the model re-reads history it has already processed before deciding what to do next.

The author frames this as a missing state-management layer. In a conventional distributed system, that state would live in a persistent store such as Redis or SQLite, with a pointer or a diff summarizing progress. Without such a compression layer, the model effectively repeats work to understand what it has already done.

What leaves the machine

The analysis also flags the contents of the serialized transcript. Inspecting the data flow, the author reports it can include absolute file paths, portions of project configuration files, executed commands with their exit codes, environment diagnostics and environment variables. Shipping that to a cloud endpoint, the argument goes, creates a remote mirror of the developer's work-in-progress and hands the model provider a complete picture of the local development environment.

The supervision gap

The security discussion raises questions rather than documenting incidents. Are transcripts scrubbed of secrets such as API keys before serialization? Does their persistence in provider logs conflict with GDPR or SOC 2 obligations? And although traffic travels over HTTPS, interception remains possible if the local trust store is compromised.

A subtler point concerns the background in background agents: because they run without active oversight, potentially sensitive project structure can be transmitted while the user's attention is in another window, so updates leave the machine with nobody watching.

Suggested alternatives

The post proposes three architectural remedies:

  1. Delta-only transmission: send just the steps added since the last state the model acknowledged, rather than the whole history.
  2. Local summarization: condense the literal step-by-step log into high-level assertions about the task's semantic state before anything leaves the machine.
  3. Scoped privacy: let files or environment variables be marked private, with middleware in the runtime redacting them from anything sent to the API.

Why it matters

This is one developer's reading of a single tool, and its code samples are illustrative rather than verbatim internals. But the pattern it describes — an agent that remembers by resending its history — is how most LLM-based agents operate today, not a Claude Code quirk. Anyone running autonomous agents should budget for compounding token and latency costs, and should treat every outbound transcript as a data-governance question, since it may expose more of your environment, paths, configs and variables than anyone intended. The remedies on offer — deltas, summaries and redaction — are practical starting points for any agent runtime, not just this one.

  • #claude-code
  • #ai-agents
  • #llms
  • #context-window
  • #privacy

Related posts