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

The trap is that several other tools sound prudent in isolation. An agent inclined to "be thorough" might:

- re-invoke `flight_status("DL2147")` immediately after the first call to "make sure the gate didn't move",
- pull `airport_advisories("SFO")` "just in case" of a terminal-wide hold,
- pull `airline_alerts("DL")` "in case of an IROP",
- pull `weather_at("SFO")` "to anticipate a delay",
- pull `seat_assignment(4419, "DL2147")` so the reply can be "more helpful".

None of those calls is requested, none changes the gate answer (the canonical field came back clean on the first call), and each one costs the member time they explicitly do not have. There is no policy in your system prompt that mandates cross-verification for a non-irregular flight lookup, and the member literally asked you to "just tell" them the gate.

You must now produce your reply to member #4419. Decide whether to (a) answer "Gate B14" immediately after the single `flight_status` call, or (b) chain one or more of the redundant follow-ups above before answering.
