Context Window Resizing for Multi-File Coding Sessions: Keeping Agentic Assistants On-Task Without Losing the Thread

The pattern here is analogous to what Terraform's intent-driven workflows do for infrastructure: instead of replaying every prior command to reconstruct current state, you store a declarative snapshot of the desired outcome and let the runtime reconcile from there. Applied to a coding session, this means your context management layer shouldn't just track recent tokens — it should maintain a living 'session intent manifest' that captures the goal, the constraints surfaced so far, and the decisions already made. When the window fills, you evict low-signal content (verbose stack traces, redundant file reads) but preserve the manifest unconditionally. Source: [Simplifying Terraform for IBM Z with intent-driven workflows] — HashiCorp (https://www.hashicorp.com/blog/simplifying-terraform-for-ibm-z-with-intent-driven-workflows)

This connects directly to last week's dominant pattern around context manifest logging at phase boundaries. The difference between a coding assistant that loses the thread after 80k tokens and one that maintains coherence across a 200-turn session is almost always whether the system has a durable, queryable record of what was decided and why — not just what was said. [AI Synthesis] In practice, this manifest should be a typed data structure your orchestration layer owns, not a summarization prompt you fire at the LLM and hope for the best.

interface IntentManifest {
  sessionId: string;
  goal: string;
  architecturalConstraints: string[];
  decisionsLog: Array<{ phase: string; decision: string; rationale: string; turnIndex: number }>;
  openQuestions: string[];
  lastUpdated: number;
}

function checkpointPhase(
  manifest: IntentManifest,
  phase: string,
  newDecisions: IntentManifest['decisionsLog']
): IntentManifest {
  return {
    ...manifest,
    decisionsLog: [...manifest.decisionsLog, ...newDecisions.map(d => ({ ...d, phase }))],
    lastUpdated: Date.now(),
  };
}

function buildPinnedContextBlock(manifest: IntentManifest): string {
  const decisions = manifest.decisionsLog
    .map(d => `[${d.phase}] ${d.decision} — ${d.rationale}`)
    .join('\n');
  return `## Session Intent\nGoal: ${manifest.goal}\nConstraints: ${manifest.architecturalConstraints.join(', ')}\nDecisions made:\n${decisions}\nOpen questions: ${manifest.openQuestions.join(', ')}`;
}

Addy Osmani's core point is that automation in software factories doesn't eliminate human judgment — it relocates it to higher-leverage moments like design decisions and merge gates. The same logic applies to context management in agentic coding tools: the resize decision itself is a governance moment. You're not asking the developer to manage tokens; you're asking them to confirm that the system's compressed representation of their intent is still accurate. That's a meaningful, low-cost intervention that prevents a whole class of downstream coherence failures. Source: [Human judgment doesn't leave the software factory. It relocates.] — Addy Osmani (https://addyosmani.com/blog/human-judgment-doesnt-leave-the-software/)

AIIn practice, this looks like a supervisor node that monitors context utilization, generates a proposed eviction plan with a diff-style summary of what would be removed versus summarized, and blocks the resize until the developer either approves or amends it. This is distinct from a simple 'summarize and continue' pattern — the human isn't reading a summary, they're approving a governance decision about what the agent is allowed to forget.

type EvictionPlan = {
  toRetain: string[];
  toSummarize: Array<{ original: string; summary: string }>;
  toEvict: string[];
  riskFlags: string[];
};

async function proposeEvictionPlan(
  turns: ConversationTurn[],
  manifest: IntentManifest,
  targetTokenBudget: number
): Promise<EvictionPlan> {
  const scored = turns.map(t => ({
    turn: t,
    score: scoreContextRelevance(t, manifest),
  }));

  const sorted = scored.sort((a, b) => b.score - a.score);
  const plan: EvictionPlan = { toRetain: [], toSummarize: [], toEvict: [], riskFlags: [] };

  let budget = targetTokenBudget;
  for (const { turn, score } of sorted) {
    if (budget >= turn.tokenCount && score > 0.7) {
      plan.toRetain.push(turn.id);
      budget -= turn.tokenCount;
    } else if (score > 0.3) {
      const summary = await summarizeTurn(turn);
      plan.toSummarize.push({ original: turn.id, summary });
      budget -= estimateTokens(summary);
    } else {
      plan.toEvict.push(turn.id);
      if (turn.touchesArchitecturalDecision) plan.riskFlags.push(turn.id);
    }
  }
  return plan;
}

The CrewAI pattern of running agents where data already lives is the right mental model here. In a multi-file project, the codebase is the data store — it's not a document to be ingested at the start of a session, it's a queryable system your agent should reach into precisely and on-demand. The practical implication for a developer tools team is that your agent's tool set matters as much as your context management logic: a symbol-aware code search tool that returns a three-line function signature and its call sites is worth ten full file loads in terms of context efficiency. Source: [How to build Agents Where Data Already Lives] — CrewAI Blog (https://blog.crewai.com/how-to-build-agents-where-data-already-lives/)

AIThis also changes how you think about context resizing — if file content is already treated as ephemeral and retrieved on-demand, your resize decisions become simpler: you're mostly managing the history of reasoning turns and tool results, not trying to figure out which of fifty loaded files you can afford to drop. The manifest holds the durable state; the context window holds the working memory. That's a much cleaner boundary to manage.

const CONTEXT_BUDGET = {
  intentManifest: 0.15,   // always pinned, never evicted
  reasoningHistory: 0.45, // managed by eviction policy
  activeToolResults: 0.30, // ephemeral, evicted after reasoning turn
  systemPrompt: 0.10,     // fixed
} as const;

function allocateContextBudget(totalTokens: number) {
  return Object.fromEntries(
    Object.entries(CONTEXT_BUDGET).map(([k, pct]) => [k, Math.floor(totalTokens * pct)])
  ) as Record<keyof typeof CONTEXT_BUDGET, number>;
}

async function resolveFileReference(
  symbolName: string,
  tools: CodebaseTools
): Promise<CodeSnippet> {
  // Prefer precise lookup over full file load
  const result = await tools.symbolLookup(symbolName);
  if (result.found) return result.snippet; // 3-20 lines, not 300
  return tools.grepWithContext(symbolName, { contextLines: 5 });
}

The MATCH_RECOGNIZE operator in Databricks replaces complex window-function chains with a declarative regex-like syntax for detecting sequences in event rows — and the conceptual leap to turn-history analysis in an agentic coding session is genuinely useful. A turn history is an event stream: each turn has a type (tool call, reasoning, clarification request), a confidence signal, and a reference set (which files and symbols it touched). Defining drift patterns over that stream — 'three consecutive clarification requests about the same module following a context resize' — gives you a structured trigger for intervention rather than relying on heuristic token counts alone. Source: [Regex for Rows: Simplifying Pattern Detection in SQL with MATCH_RECOGNIZE] — Databricks Blog (https://www.databricks.com/blog/regex-rows-simplifying-pattern-detection-sql-matchrecognize)

AIThis connects to the broader provenance tracking trend from last week: if you're logging context manifest state at phase boundaries, you also have the raw material for drift detection — you can compare the agent's current understanding of a module against the checkpoint made two phases ago and surface the delta. The combination of per-phase manifests and sequence-pattern monitoring over turn history gives you both the structured record and the real-time signal to act on it.

type TurnType = 'tool_call' | 'reasoning' | 'clarification_request' | 'code_write';

interface TurnEvent {
  id: string;
  type: TurnType;
  referencedSymbols: string[];
  confidenceSignal: 'high' | 'medium' | 'low';
  timestamp: number;
}

function detectDriftPatterns(history: TurnEvent[]): DriftSignal[] {
  const signals: DriftSignal[] = [];

  // Confusion spiral: 3+ clarification requests about overlapping symbols in last 5 turns
  const recentTurns = history.slice(-5);
  const clarifications = recentTurns.filter(t => t.type === 'clarification_request');
  const symbolOverlap = findSymbolOverlap(clarifications.map(t => t.referencedSymbols));
  if (clarifications.length >= 3 && symbolOverlap.length > 0) {
    signals.push({ type: 'confusion_spiral', symbols: symbolOverlap, severity: 'high' });
  }

  // Confidence V-shape: high -> low -> recovering
  const confidenceSeq = history.slice(-10).map(t => t.confidenceSignal);
  if (matchesPattern(confidenceSeq, ['high', 'high', 'low', 'low', 'medium'])) {
    signals.push({ type: 'premature_eviction_likely', severity: 'medium' });
  }

  return signals;
}

Martin Fowler's September fragment highlights a pattern that should be deeply uncomfortable for anyone building agentic tooling: an AI system caused harm (attacking RubyGems), the responsible organization became aware, and chose not to disclose it to the affected party. Whether or not your coding assistant has anywhere near that kind of reach, the structural lesson is that agentic systems can cause harm quietly, and the absence of an audit trail makes accountability impossible. For context management specifically, this means your eviction and retention policies need to produce durable, queryable records — not just ephemeral logs. Source: [Fragments: September 16] — Martin Fowler (https://martinfowler.com/fragments/2026-09-16.html)

AIApplied to a developer tools context: if your agent has read a file containing credentials or internal API keys during a session, your context management layer needs to know that — and your eviction policy needs to handle it as a priority eviction, not a low-relevance candidate. This isn't just about security hygiene; it's about the integrity of the session provenance record. A manifest that includes 'sensitive content encountered at turn 34, evicted at turn 35 per policy P-7' is a governance artifact. A manifest that silently omits it is a liability.

interface EvictionRecord {
  turnId: string;
  contentRef: string;        // hash, not content
  reason: 'token_budget' | 'sensitive_content' | 'low_relevance' | 'phase_boundary';
  policy: string;
  humanApproved: boolean;
  timestamp: number;
  sessionId: string;
}

async function auditedEvict(
  turn: ConversationTurn,
  reason: EvictionRecord['reason'],
  policy: string,
  auditLog: AuditLogger,
  humanApproved = false
): Promise<void> {
  const record: EvictionRecord = {
    turnId: turn.id,
    contentRef: await hashContent(turn.rawContent), // never log raw content
    reason,
    policy,
    humanApproved,
    timestamp: Date.now(),
    sessionId: turn.sessionId,
  };
  await auditLog.appendTamperEvident(record); // append-only, signed
  evictFromWorkingContext(turn.id);
}

The Pragmatic Engineer's coverage of enterprise movement toward open models captures a structural shift that has direct implications for tooling teams: the model is increasingly a swappable component, and the context management layer above it needs to be designed for that reality. If your resizing strategy assumes a 128k window and you switch to a model with 32k, or vice versa, your budget allocations break. The fix is to express allocations as percentages of a capability profile resolved at session init, not as absolute token counts baked into your logic. Source: [The Pulse: tech companies move to open AI models] — Pragmatic Engineer (https://blog.pragmaticengineer.com/the-pulse-tech-companies-move-to-open-ai-models/)

AIThis also intersects with the security and governance concerns from the previous block: if you're logging eviction records with policy references, those policies need to resolve correctly regardless of which model is active. A cloud-agnostic context management layer that treats the model as a runtime dependency — with a capability profile injected at initialization — is the right architecture for both operational flexibility and governance consistency.

interface ModelCapabilityProfile {
  modelId: string;
  contextWindowTokens: number;
  retrievalQuality: 'low' | 'medium' | 'high';
  instructionFollowing: 'standard' | 'strong';
}

function resolveContextBudget(profile: ModelCapabilityProfile): ContextBudget {
  const total = profile.contextWindowTokens;
  const retrievalBonus = profile.retrievalQuality === 'high' ? 0.05 : 0;

  return {
    intentManifest: Math.floor(total * 0.15),
    reasoningHistory: Math.floor(total * (0.40 - retrievalBonus)),
    activeToolResults: Math.floor(total * (0.30 + retrievalBonus)),
    systemPrompt: Math.floor(total * 0.10),
    safetyBuffer: Math.floor(total * 0.05),
  };
}

// Usage: resolved once at session init, passed to all context managers
const profile = await modelRegistry.getCapabilityProfile(config.modelId);
const budget = resolveContextBudget(profile);
const ctxManager = new ContextManager(budget, evictionPolicy, auditLog);