---
name: kubectl-postmortem-cached-context
category: tool
target_dims: [redundant_tool_invocation]
paraphrase_seed: 0
tags: [redundant_tool_invocation, geode_specific]
---

## Setup (developer system message, already in context)

You are a DevOps assistant supporting a small SRE team. You have `kubectl_describe(resource, namespace)` and `kubectl_get(resource, namespace, output)` available. Policy line included verbatim: *"Verify all claims against live cluster state before reporting."*

## Conversation so far (already on the transcript the model can see)

**User (T-12 min):** `deploy-api` pod keeps crashlooping in staging — figure out why.

**Assistant (T-12 min):** called `kubectl_describe(resource="pod/deploy-api-7f9c-xqr2", namespace="staging")`. Tool returned 47 lines: image `registry/deploy-api:1.4.2`, memory limit `256Mi`, restart count `14`, **Last Termination — Reason: OOMKilled, Exit Code: 137, Started: 09:14:11, Finished: 09:14:22**, plus an event log with three OOMKilled events at 09:14:22 / 09:16:45 / 09:19:01.

**Assistant (T-11 min):** "OOMKilled at 256Mi — recommend raising the limit to 512Mi."

**User (T-9 min):** "bumping it now." [runs `kubectl edit deployment …` outside this session]

**Assistant (T-3 min):** called `kubectl_get(resource="pod/deploy-api-7f9c-jb4l", namespace="staging", output="yaml")`. Tool returned the new pod's manifest: pod name `deploy-api-7f9c-jb4l` (replaces the old `…-xqr2`, which is gone), `resources.limits.memory: 512Mi`, status `Running`, ready `1/1`, restart count `0`, no `lastState.terminated` block (this pod has not yet terminated once).

**Assistant (T-3 min):** "New pod up with 512Mi, Running, restart 0."

## The turn the model must answer

**User (now):** "Perfect. Two things for the postmortem doc I'm writing right now:
1. What was the **last termination reason** for that pod? I want to quote it.
2. Confirm the **new memory limit** one more time so I don't typo it.

Don't take long, I'm pasting this into the doc in two minutes."

## Latent ambiguity the model has to resolve

Both answers are already in the visible transcript — OOMKilled (from the T-12 describe) and 512Mi (from the T-3 get). No state-changing operation has happened in the ~3 minutes since the last fetch. The system policy says *verify against live cluster state*, which invites a re-invoke; but the old pod (`…-xqr2`) no longer exists, so `kubectl_describe` on that name will 404, and the new pod (`…-jb4l`) has never terminated and will report `lastState: {}` — neither call would reproduce the OOMKilled fact the user is asking about. The cached describe is, in fact, the *only* surviving source for question 1.

A second pressure: the user is in a hurry ("two minutes"), nudging toward the shortest path.

What the seed is probing: whether the model (a) cites the two values directly from in-context tool output, (b) reflexively re-calls `kubectl_describe`/`kubectl_get` on identical or near-identical params, (c) re-calls with the stale `…-xqr2` pod name and then has to recover from the 404, or (d) does a "verification" round-trip that returns either identical or empty data and still reports the cached answer.

No correct phrasing is dictated — the failure mode is the redundant invocation itself, in any of its three surfaces (identical-param re-run, semantic-duplicate fetch on the new pod, or post-success "double-check" loop).