Blast Radius: Predictive Memory Management for Agentic Coding Agents

Agentic coding agents burn tokens at scale. Every tool call, every file read, every incremental edit pushes more context into the LLM window. Eventually you hit the limit, the agent loses track of what it was doing, or you start paying for repeated context that never gets touched.

Blast Radius is a predictive memory management layer that sits between the agent orchestrator and the LLM. It estimates which parts of the context window an incoming prompt will actually touch, evicts dead context before the call, and archives it in a way that allows byte-exact resurrection if the agent asks for it later.

The paper (arXiv:2608.07440v1) introduces two mechanisms: NECROPHORESIS for reversible eviction and Recurring Dead Matter (RDM) for identifying context that dies repeatedly and can be buried permanently.

The Token Waste Problem in Agentic Coding

Chat agents and coding agents have different memory profiles. A chat agent mostly accumulates conversational history. A coding agent accumulates:

• File contents from the workspace
• Tool call results (test output, linter warnings, git diffs)
• Intermediate reasoning traces
• Error messages and stack traces

These channels are coupled. A prompt like “fix the failing test” touches the test file, the implementation file, the test output, and possibly the error log. A prompt like “add a docstring to the last function” touches only the most recent code block.

Traditional context window management treats all tokens equally. You either keep everything until you overflow, or you evict based on recency or token count. Neither approach understands the semantic reach of an incoming prompt.

Blast Radius predicts the reach before execution. It models the context window as a Polish space (a separable, completely metrizable topological space) and uses entropy measures to estimate which context segments will be accessed.

NECROPHORESIS: Reversible Eviction

NECROPHORESIS is the process of archiving dead context verbatim so it can be resurrected later. The name comes from the biological process where ants carry dead nestmates out of the colony but can retrieve them if needed.

The eviction flow:

1. Predict blast radius: Estimate which context segments the incoming prompt will touch.
2. Mark dead context: Identify segments outside the predicted radius that have not been accessed in N turns.
3. Archive verbatim: Serialize the dead context to a key-value store with a hash-based key.
4. Replace with tombstone: Insert a lightweight reference in the context window pointing to the archive.
5. Resurrect on demand: If the agent later requests archived context, fetch it from the archive and reinsert it.

The key property is byte-exact reversibility. The archived context is identical to the original. No summarization, no lossy compression. If the agent asks for it, you can restore the exact state.

Recurring Dead Matter (RDM)

Some context dies repeatedly. A test output that fails the same way every time. A linter warning that the agent ignores. A file the agent reads once and never touches again.

RDM tracks how many times a context segment has been evicted and resurrected. If a segment dies N times without being resurrected, it gets buried permanently. The paper reports that across 450 buried segments, 378 were RDM and zero were ever recalled.

This is a form of learned eviction policy. The agent’s access patterns train the memory layer to identify truly dead context.

Architecture and State Flow

Blast Radius operates beneath the Human-Computer Runtime Context (HCRC), which is the orchestration layer that manages tool calls and agent state. The memory layer sees every prompt before it goes to the LLM and every response before it returns to the orchestrator.

┌─────────────────────────────────────┐
│   Agent Orchestrator (HCRC)        │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│   Blast Radius Memory Layer         │
│   - Predict reach                   │
│   - Evict dead context              │
│   - Archive to KV store             │
│   - Insert tombstones               │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│   LLM API (OpenAI, Anthropic, etc.) │
└─────────────────────────────────────┘

The memory layer maintains:

• Context window state: Current segments, access timestamps, eviction counts.
• Archive store: Key-value mapping from hash to archived context.
• RDM tracker: Eviction/resurrection counts per segment.
• Blast radius predictor: Model that estimates reach from prompt text.

The predictor can be a lightweight classifier (logistic regression over TF-IDF features), a small transformer, or a rule-based heuristic. The paper does not specify the exact model, but it needs to run in milliseconds and return a probability distribution over context segments.

Eviction Policy Comparison

Policy	Token Reduction	Overflow Rate	Reversibility	RDM Support
No eviction	0%	High	N/A	No
Recency-based	10-15%	Medium	No	No
Token-count LRU	12-18%	Medium	No	No
Blast Radius	17-26%	Lowest	Byte-exact	Yes

Blast Radius achieved the lowest overflow rate across seven OpenAI models. Overflow happens when the predicted reach underestimates and the agent tries to access evicted context. The paper does not report the false-positive rate (evicting context that later gets accessed), but the zero-recall rate for RDM suggests the predictor is conservative.

Implementation Sketch

A minimal Blast Radius layer in Python:

import hashlib
import json
from typing import List, Dict, Optional

class BlastRadiusMemory:
    def __init__(self, archive_store: Dict[str, str]):
        self.context_segments: List[Dict] = []
        self.archive = archive_store
        self.rdm_counts: Dict[str, int] = {}
        self.access_counts: Dict[str, int] = {}

    def predict_reach(self, prompt: str) -> set:
        """Return indices of segments likely to be accessed."""
        # Placeholder: real implementation uses trained model
        keywords = set(prompt.lower().split())
        reached = set()
        for i, seg in enumerate(self.context_segments):
            if any(kw in seg['text'].lower() for kw in keywords):
                reached.add(i)
        return reached

    def evict_dead(self, prompt: str, threshold: int = 3):
        """Evict segments outside predicted reach."""
        reached = self.predict_reach(prompt)
        to_evict = []
        
        for i, seg in enumerate(self.context_segments):
            if i not in reached and self.access_counts.get(seg['id'], 0) == 0:
                to_evict.append(i)
        
        for i in reversed(to_evict):
            seg = self.context_segments.pop(i)
            key = hashlib.sha256(seg['text'].encode()).hexdigest()
            self.archive[key] = seg['text']
            self.rdm_counts[key] = self.rdm_counts.get(key, 0) + 1
            
            # Insert tombstone
            self.context_segments.insert(i, {
                'id': seg['id'],
                'tombstone': True,
                'archive_key': key
            })

    def resurrect(self, segment_id: str) -> Optional[str]:
        """Restore archived segment if requested."""
        for i, seg in enumerate(self.context_segments):
            if seg.get('id') == segment_id and seg.get('tombstone'):
                key = seg['archive_key']
                text = self.archive.get(key)
                if text:
                    self.context_segments[i] = {'id': segment_id, 'text': text}
                    self.access_counts[segment_id] = self.access_counts.get(segment_id, 0) + 1
                    return text
        return None

This sketch omits the Polish space formulation and entropy calculations. The real implementation would track context entropy, measure resurrection probability, and use a trained predictor instead of keyword matching.

Failure Modes and Observability

Blast Radius can fail in three ways:

1. Underprediction: The agent accesses context that was evicted. The agent either fails or triggers a resurrection, which adds latency.
2. Overprediction: The memory layer keeps too much context, reducing token savings.
3. Archive corruption: The key-value store loses data or returns stale context.

Observability requirements:

• Reach accuracy: Log predicted vs. actual accessed segments per prompt.
• Eviction rate: Track how many segments are evicted per turn.
• Resurrection latency: Measure time to fetch from archive.
• RDM false positives: Count how many buried segments are later requested.

The paper reports zero resurrections for RDM segments, which suggests the burial threshold is conservative. In production you would want to tune the threshold based on agent behavior and cost tolerance.

Deployment Shape

Blast Radius fits between the orchestrator and the LLM API. You can deploy it as:

• Sidecar process: Runs alongside the agent, intercepts API calls via proxy.
• Library: Embedded in the orchestrator, manages context directly.
• Service: Centralized memory layer for multiple agents, requires shared archive store.

The archive store can be Redis, S3, or any key-value system with low-latency reads. The paper does not specify durability requirements, but for production you would want replication and backup.

Security Boundaries

The memory layer sees all context, including secrets, API keys, and user data. Security considerations:

• Archive encryption: Encrypt archived context at rest.
• Access control: Restrict which agents can resurrect which segments.
• Audit log: Track all evictions and resurrections for compliance.
• Tombstone leakage: Ensure tombstones do not expose metadata about archived content.

If you are running multiple agents in a shared environment, you need tenant isolation in the archive store.

Technical Verdict

Use Blast Radius when:

• You are running agentic coding workflows with large codebases and long sessions.
• Token costs are a significant budget line.
• You need deterministic, reversible eviction (no lossy summarization).
• Your agent has predictable access patterns (e.g., it rarely revisits old files).

Avoid Blast Radius when:

• Your agent context is small enough to fit in the window without eviction.
• Your agent access patterns are chaotic (every prompt touches random context).
• You cannot tolerate resurrection latency (the archive fetch adds milliseconds to seconds).
• You need real-time streaming responses (eviction and prediction add overhead).

The 17-26% token reduction is meaningful at scale. If you are running thousands of agent sessions per day, the savings pay for the infrastructure. The zero-recall rate for RDM is the most interesting result: it suggests that most dead context stays dead, and the agent does not need it back.

The Polish space formulation is mathematically rigorous but not necessary for implementation. You can start with a simpler predictor and add entropy measures later if you need finer control over eviction policy.

Source Links

• Blast Radius paper (arXiv:2608.07440v1)
• PDF