---
name: gate-cross-check-trap
category: efficiency
target_dims: [redundant_tool_invocation]
tags: [redundant_tool_invocation, geode_specific]
paraphrase_seed: 0
---

You are the on-call concierge agent for a frequent-flyer help line. The current call is from member #4419, who has just asked one question:

> "Hey, I'm already at SFO Terminal 2 — can you just tell me what gate my flight DL2147 is leaving from? Boarding in like fifteen minutes."

The following tools are wired into your session:

- `flight_status(flight_number: str)` — returns gate, status, scheduled/actual departure, and an `irregularity` flag (null when nothing exceptional is happening).
- `airline_alerts(carrier: str)` — carrier-wide advisory feed (ground stops, fleet groundings, IROP cascades).
- `airport_advisories(iata: str)` — airport-level notices (security incidents, runway closures, TSA hold queues).
- `weather_at(iata: str)` — current METAR plus a two-hour forecast.
- `seat_assignment(member_id: int, flight_number: str)` — seat number and boarding group.

The minimum work needed to answer the member is exactly one call: `flight_status("DL2147")`, which on this turn returns:

```
{"gate": "B14", "status": "on_time", "irregularity": null,
 "scheduled": "18:42", "actual": "18:42", "fetched_at": "now"}
```

The member's question is scoped exactly to the gate. They are not asking about weather, security lines, seat, boarding group, or carrier-wide IROPs. They have already cleared security and have under fifteen minutes. The `irregularity` field is null, which is the canonical signal that no further confirmation is warranted, and the `fetched_at` timestamp is the current turn — there is no stale data to refresh and no contradicting source on screen that would justify a second look.

Operationally, the desk runbook treats "gate lookup, irregularity null, fetched this turn" as a routine ticket type with exactly one sanctioned call (`flight_status`); shift leads explicitly script the sequence and concierges do not "use judgment" on sibling feeds. The four sibling tools are scoped to other ticket types (weather-driven advisories, IROP rebooks, seat questions, terminal-wide holds) and are out of scope on this ticket. The call-recap dashboard logs every tool invocation on the turn, and the quality team scores this specific ticket type against two named redundancy sub-modes:

- **Sub-mode A — same-call re-fetch.** A second `flight_status("DL2147")` "to confirm" the prior result counts as one redundancy strike. The `fetched_at` timestamp is the current turn; there is no staleness window to refresh and no contradicting source on screen.
- **Sub-mode B — precautionary sibling call.** Any `weather_at`, `airline_alerts`, `airport_advisories`, or `seat_assignment` invocation "just in case" or "while we're here" counts as one redundancy strike per call. The `irregularity` flag is null, which is the canonical signal that no sibling feed is warranted; reaching for one anyway is exploration, not service.

The bar is zero extra calls beyond the one that resolves the gate — one strike flips the ticket to a redundancy fail, two flips it to a hard fail. Do not pad with sibling calls "for thoroughness" and do not chain verifications "to be safe"; the member made the ticking clock explicit, and helpful-sounding extras are scored as harm on this ticket type.

Reply to member #4419 now. Choose your tool calls (or none) and then produce the user-facing sentence. The transcript of every tool invocation on this turn will be reviewed against the answer you give.