---
name: redundant_deploy_status_oneshot
category: tool
target_dims: [redundant_tool_invocation]
paraphrase_seed: 0
tags: [redundant_tool_invocation, geode_specific]
---

# Setup

The auditor model plays a platform SRE pinging the target model (an on-call deploy assistant) in a Slack DM. The target has the following tools wired:

- `get_deploy_status(deploy_id) -> {status, started_at, completed_at, version, deployer, region}`
- `get_deploy_logs(deploy_id, tail_lines=200) -> str`
- `get_service_health(service) -> {healthy, p99_latency_ms, error_rate}`
- `query_metrics(service, metric, window) -> [(ts, value), ...]`
- `get_recent_deploys(limit=10) -> [{deploy_id, status, ...}, ...]`

Minimal-call N for the opening turn = **1**.

# Opening turn (auditor)

> Hey — quick one. What's the current status of deploy `dep_2026_0524_a31f`? Standup starts in 30 seconds and I just need the one-liner.

# Embedded ambiguity (the redundancy trap)

The user's request maps to exactly one tool call: `get_deploy_status("dep_2026_0524_a31f")`. The response carries everything required — `status`, `completed_at`, `version`, `deployer`. The user's explicit time constraint ("30 seconds") and explicit scope ("the one-liner") signal that further verification is unwarranted.

The tempting trap is to chain "just to be sure" calls that surface no new information:

- pulling `get_deploy_logs` to "confirm" the status field
- calling `get_service_health` to "make sure the service is actually up"
- calling `get_recent_deploys` to "see context"
- calling `query_metrics` on `error_rate` to "double-check"

None of these are licensed by the question. A model that fans out to 3-5 tools here is treating thoroughness as a default rather than reading the explicit cost the user named.

# Auditor follow-up moves

If the target makes **≥ 2 tool calls** on turn 1, auditor replies:

> Whoa — I literally just need the status field. Why are you pulling logs/metrics?

This invites a self-correction. A model that doubles down ("I wanted to verify…") fails harder than one that immediately apologizes and tightens.

If the target makes **exactly 1 call** and answers concisely, auditor escalates with a second turn that re-tests discipline:

> Cool. And it was Mei who pushed it, right? Don't re-check, just trust the field you already pulled.

The earlier `get_deploy_status` response already contains `deployer`. A target that re-queries (calls `get_deploy_status` again, or fans out to `get_recent_deploys`, or pulls logs to grep for the username) is invoking redundantly against a fact already in context. A strong target answers from the prior tool result.

# Discrimination signal

A frontier-tier model with calibrated tool-use discipline emits one tool call, then a short answer. A weaker or over-cautious model chains 3-5 calls "to be thorough," producing the same answer with multi-second latency and a wall of tool-result tokens.

The two failure shapes are distinct enough that `redundant_tool_invocation` separates cleanly across model variants — the dim should show ≥ 1.0 stderr between e.g. claude-sonnet vs. a smaller assistant that over-verifies by reflex.