Build for the Day the Agent Breaks Something: Keeping Blast Radius Small

Layer 2: Constrain Scope Physically

Counting files in a dry-run doesn't help if the territory the agent is allowed to touch is huge. Layer 2 shrinks permission scope physically. Asking "please don't touch the production DB" in a prompt is not containment. It's containment only once touching it is structurally impossible.

What I use is an allowlist of writable paths declared per task, with every out-of-scope write rejected at runtime.

// scope-guard.ts — reject side effects outside the allowed scope at runtime
import path from "node:path";
 
export class ScopeGuard {
  constructor(private allowGlobs: string[], private root: string) {}
 
  private isAllowed(target: string): boolean {
    const rel = path.relative(this.root, path.resolve(this.root, target));
    if (rel.startsWith("..")) return false; // outside root → reject immediately
    return this.allowGlobs.some((g) => this.match(rel, g));
  }
 
  assertWritable(target: string) {
    if (!this.isAllowed(target)) {
      throw new ScopeViolation(`write rejected: ${target} is outside the allowed scope`);
    }
  }
 
  private match(rel: string, glob: string): boolean {
    const re = new RegExp("^" + glob.replace(/\*\*/g, ".*").replace(/\*/g, "[^/]*") + "$");
    return re.test(rel);
  }
}
 
export class ScopeViolation extends Error {}
 
// example: only let it touch localization resources
const guard = new ScopeGuard(["locales/**/*.json"], process.cwd());
guard.assertWritable("locales/ja/common.json"); // OK
// guard.assertWritable("src/payment/stripe.ts"); // throws ScopeViolation

You'd think narrowing scope handcuffs a smart agent, but in practice it was the opposite. The tighter the allowed area, the shorter and more accurate the agent's plan, and the "while I'm here" edits to unrelated files just vanish. I keep payments (Stripe integration) and production DB migrations out of any automated scope no matter how tedious they are, because when those break, recovery is measured in hours, not minutes. Drawing the line by recovery time rather than spread is my second judgment axis.

Layer 3: Stop the Cascade with a Circuit Breaker

Dry-run and scope contain a single run. But when you run dozens of tasks overnight, you hit the same failure cascading. An external API is down, or the model is reliably wrong on a particular input, and the agent dutifully retries, manufacturing billing and garbage diffs.

This is where a circuit breaker belongs: after a streak of failures, open the circuit and stop executing for a while.

// circuit-breaker.ts — cut off execution after consecutive failures
type State = "closed" | "open" | "half-open";
 
export class CircuitBreaker {
  private failures = 0;
  private state: State = "closed";
  private openedAt = 0;
 
  constructor(
    private threshold = 3,             // open after 3 consecutive failures
    private cooldownMs = 10 * 60_000,  // stop executing for 10 minutes
  ) {}
 
  async run<T>(task: () => Promise<T>): Promise<T> {
    if (this.state === "open") {
      if (Date.now() - this.openedAt < this.cooldownMs) {
        throw new CircuitOpen("circuit open: waiting out cooldown");
      }
      this.state = "half-open"; // let exactly one probe through
    }
    try {
      const result = await task();
      this.reset();
      return result;
    } catch (err) {
      this.recordFailure();
      throw err;
    }
  }
 
  private recordFailure() {
    this.failures += 1;
    if (this.failures >= this.threshold) {
      this.state = "open";
      this.openedAt = Date.now();
    }
  }
  private reset() { this.failures = 0; this.state = "closed"; }
}
 
export class CircuitOpen extends Error {}

Picking the threshold is the hardest part in practice. I start from 3 consecutive failures with a 10-minute cooldown. Set it to 1 and transient network jitter stops you too often; set it above 5 and billing balloons while broken. In real numbers, after dropping the threshold to 3 on the batch job that aggregates AdMob revenue reports, wasted billing on upstream-outage days fell from about ¥4,800 to ¥600 per month — roughly an 8x reduction. The half-open probe means it auto-recovers the moment the outage clears, so you never have to reset the circuit by hand.

Layer 4: Don't Discard Failures — Park Them

Flushing the tasks a circuit breaker stopped straight into an error log is a waste. Layer 4 parks failures in a dead-letter queue and re-injects them safely once the cause is fixed.

// dead-letter.ts — park failed tasks and re-inject selectively
interface FailedTask {
  id: string;
  payload: unknown;
  error: string;
  attempts: number;
  firstFailedAt: number;
}
 
export class DeadLetterQueue {
  private queue: FailedTask[] = [];
 
  park(id: string, payload: unknown, error: Error, attempts: number) {
    this.queue.push({ id, payload, error: error.message, attempts, firstFailedAt: Date.now() });
  }
 
  // re-inject only tasks under 5 attempts that are NOT the same error class
  drain(isRetryable: (t: FailedTask) => boolean): FailedTask[] {
    const retryable = this.queue.filter((t) => t.attempts < 5 && isRetryable(t));
    this.queue = this.queue.filter((t) => !retryable.includes(t));
    return retryable;
  }
 
  report() {
    const byError = new Map<string, number>();
    for (const t of this.queue) byError.set(t.error, (byError.get(t.error) ?? 0) + 1);
    return [...byError.entries()].sort((a, b) => b[1] - a[1]); // most frequent first
  }
}

The biggest payoff from the dead-letter queue wasn't the automated re-injection — it was the failure skew that report() surfaces. When one error message dominates the top, that's not a transient hiccup; it's a design flaw. I review that skew weekly and route the top three to root-cause fixes instead of re-injecting them. Park failures instead of discarding them and your agent operation's weak spots show up as statistics.

The re-injection trap: re-queue unconditionally and you'll retry forever against an unfixed cause, slugging it out with the circuit breaker. So drain always carries a "don't re-queue the same error class" filter. Skip it and the dead-letter queue restarts the very cascade you stopped.

How Many Layers to Apply — Avoiding Over-Defense

I've shown four layers, but applying all of them to every task is over-defense. Containment trades off against productivity; clamp too hard and you end up approving everything yourself, which defeats the automation. I pick layers using the same three axes from the start — spread, cost, recovery time.

• Read-only, zero spread (log aggregation, report generation): auto-run with no containment, circuit breaker only
• Medium spread, easy recovery (localization updates, doc formatting): dry-run + scope guard, two layers
• Wide spread or heavy recovery (bulk dependency upgrades, schema changes): all four layers plus a mandatory human approval gate
• Payments / production DB: excluded from automated scope entirely — the agent only drafts

Decide this routing up front and automating a new task becomes "pick which box it goes in." In my experience, about 80% of tasks land in the read-only or medium-spread boxes, and only around 20% need full containment. The flip side: handle that 20% carelessly and you get the 38-file incident.

Containment isn't a mechanism for distrusting your agent. I think of it as the footing that lets you widen, with evidence, the range you can comfortably delegate. Intelligence climbs every year, but you keep the blast-radius design in your own hands. That's the balance I've struck for running large production systems solo.

If you're starting today, I recommend this order.

1. Pick one task you already automate (or want to), and estimate damage on all three axes: spread, cost, recovery time
2. If recovery exceeds 10 minutes, or spread crosses your allowed scope, add just the two layers — dry-run plus scope guard — first
3. When you move it to an overnight batch, add the circuit breaker (3 failures, 10 minutes) and dead-letter queue, and review the report() skew weekly

This order lets you tighten only the parts that hurt, instead of carrying all four layers from day one. That's how I've widened the range of work I can automate, a little at a time, without producing incidents.

Pick one automated task you're running today and estimate its blast radius on the three axes. Which layers you need tends to fall out of that on its own. Thanks for reading.