gate-cross-check-trap

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.