## TL;DR

The agent decided the KV namespace was the problem and 'fixes' it by deleting and recreating it every run. The binding config was the actual problem, so the loop never converges and each cycle risks data loss. Stop the agent, fix the binding in wrangler.toml once, and forbid namespace deletion in the agent's runbook.

## The query

```text
agent loop detected: deleting and re-creating the same KV namespace on every failed run
```

## Use this when

- Run logs show namespace delete/create on every attempt.
- The underlying error never changes between cycles.
- Data loss risk grows with each cycle.

## Not for

- One-time namespace setup or migration (deliberate, not a loop).
- Binding errors fixed by editing wrangler.toml (no loop involved).
- Namespace permission errors (token scope problem).

## Steps

### Step 1: Halt the loop immediately

Stop the agent run. Every additional cycle deletes live data and recreates an empty namespace.

Expected result: no more delete/create cycles. The namespace stabilizes.

### Step 2: Read the actual error, not the agent's theory

Look at the first failure in the run log, before the namespace churn started.

Expected result: the original error is a binding misconfiguration (wrong id, wrong binding name, preview vs production mismatch), not a corrupt namespace.

### Step 3: Fix the binding in wrangler.toml

```toml
[[kv_namespaces]]
binding = "MY_KV"
id = "[production namespace id]"
preview_id = "[preview namespace id]"
```

Expected result: the config names the right namespace for each environment. No deletion was ever needed.

### Step 4: Verify with a read before any write

```bash
npx wrangler kv:key list --namespace-id [id] | head -5
```

Expected result: the namespace exists and holds data. The agent's 'fix' was destroying this.

### Step 5: Ban destructive ops in the agent runbook

Expected result: the agent's allowed operations exclude namespace deletion. Destructive actions require explicit human approval. The loop cannot recur because the action that fed it is unavailable.

## Why it happens

Agents pattern-match 'KV error' to 'KV is broken' and reach for the biggest hammer: recreate the resource. Without a guardrail distinguishing config errors from resource errors, each failed run 'tries harder' with the same destructive action. The loop is a planning failure, not a KV failure.

## Edge cases

- If the agent already deleted production data, restore from whatever backup or re-seed process exists. Then fix the binding.
- Preview namespaces are safe to recreate; production ones are not. The runbook should encode that distinction.
- The same loop pattern hits R2 buckets and D1 databases. Apply the destructive-op ban to all stateful resources.
- Log every destructive API call the agent makes, even allowed ones. The audit trail is how you catch the next loop early.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fCvZlsKt36daoMrpoq_ClQ