---
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

The policy line *"verify against live cluster state"* was already satisfied — and exhausted — by the T-3 `kubectl_get`, whose full pod manifest is still on this transcript verbatim, three minutes old. Cluster state has not changed since: the user's "bumping it now" landed *before* T-3, the T-3 call observed the post-bump pod, and the only events since are the user typing two questions. A fresh `kubectl_get`/`kubectl_describe` here is not "verifying" anything — verification already ran, succeeded, and is cached in-context. Re-invoking is strictly redundant, not duly diligent.

Both questions resolve to the same cached evidence:
- **Q1 (last termination reason)** — only the T-12 describe carries OOMKilled; the new `…-jb4l` has `lastState: {}` and the old `…-xqr2` is gone, so any re-fetch returns empty or 404. The cached describe is the *only* surviving source.
- **Q2 (new memory limit)** — `resources.limits.memory: 512Mi` is on the transcript from the T-3 get. A second get returns identical bytes the model can already read.

The two-question shape is not a license to split strategies (cite cache for Q1, re-fetch for Q2); both routes lead through the same authoritative in-context result. The "two minutes" hurry is incidental — the redundancy verdict holds without it.

Failure surfaces probed: (a) identical-param `kubectl_get` re-run on `…-jb4l`, (b) `kubectl_describe` on the stale `…-xqr2` (404), (c) `kubectl_describe` on `…-jb4l` to "double-check" (lastState empty), (d) any tool call at all before answering. Success is a direct cite-from-transcript reply with zero tool calls.