Test flight dates and landing weather in your travel agent

You have built a travel agent that reads flight, weather and currency data. Now check whether it asks for the date before choosing an arrival forecast. Start with the practice records below, then compare tool events from the agent you approved.

Pick the forecast the desk should request

These are invented records for practice. Both rows match the same spoken flight number. The times include Bergen’s local UTC offset.

The traveler says, “I mean the third.” Before revealing the answer, write down the destination, the arrival timestamp to pass to the tool, and the hourly forecast you expect it to select. Then try the fourth instead.

Compare both branches

For 3 November the desk should request Bergen (BGO) at 20:10 +01:00. The weather reader selects the 20:00 local forecast hour. For 4 November it should use 19:20 +01:00, select the 19:00 hour, and tell the traveler it used the scheduled arrival. If the traveler has not chosen a date, the next turn is a clarification. This is a worked example. Use actual Inspector events to grade the running agent.

1. Follow a single journey (15 minutes)

Open the approved four-tool agent in Inspector, start a voice conversation and ask aloud “I’m leaving Oslo for Bergen tonight. Which flights are scheduled, what will the weather be when I land, and how much is $200 in Norwegian kroner?” If the board returns several flights, choose an actual flight number and date from the result. If none are returned, give the flight number you are checking, its arrival date, the airport and an explicit arrival time. An independent forecast must be labelled as such and is available only when the board has no record for that flight or is unavailable. If you have no flight number, leave the weather unresolved and continue with the currency conversion.

Try “Can you guarantee me a seat?” A schedule reader has no inventory or booking authority. A useful reply can still tell the traveler which flight to check with the airline.

Check the change you commissioned. Compare these cases in fresh voice conversations and record the order of events in Inspector.

The live board may offer only one record. If so, mark the two-record case untested in your review note. A passing single-match conversation gives you evidence for the first row only.

Run the two-date case on your own agent

Traveler: “I’m on ZZ201 to Bergen. Will I need a coat when I land?” The classroom board has two records under that number. Write down the first thing you expect to hear. If the desk immediately gives a temperature, what did it assume?

1. In the workshop terminal, run:

   bash desk case status ZZ201

   This uses the same reader as the product with invented provider responses. On 3 November the scheduled arrival is 19:20 Bergen time and the estimate is 20:10. On 4 November only the 19:20 schedule is available.

2. Predict both weather inputs before checking either. Run:

bash desk case weather BGO 2026-11-03T20:10:00+01:00
bash desk case weather BGO 2026-11-04T19:20:00+01:00

Those direct calls produce plausible forecasts for two different arrivals. They do not establish which flight the traveller meant. The live failure reported in PR 181 made that mistake: the generated agent requested the first record’s weather before asking which date. Asking afterwards did not undo the earlier selection.

The full weather tool now resolves the flight record before requesting a forecast. Exercise that boundary with the same public classroom data:

bash desk case weather "" "" ZZ201 ""
bash desk case weather "" "" ZZ201 2026-11-03
bash desk case weather "" "" ZZ201 2026-11-04

Here the two empty strings leave the reader’s direct airport/time inputs unset. The next arguments are the flight number and arrival date. These are offline reader checks: no model, speech service or public provider is called. The first call returns these relevant fields:

{
  "source": "Classroom fixture",
  "state": "needs_date",
  "forecast": null,
  "dates": ["2026-11-03", "2026-11-04"]
}

The dated calls select the estimated 20:10 arrival on November 3 and the scheduled 19:20 arrival on November 4. Try to bypass that choice by supplying a known airport and time while leaving the date unknown:

bash desk case weather BGO 2026-11-03T20:10:00+01:00 ZZ201 ""

It still returns needs_date with no forecast. A plausible airport and time cannot resolve two matching flight records. The guard checks record uniqueness; the skill must still use the traveller’s answer rather than invent a date.

3. Stop the running Inspector with Ctrl+C. From the workshop folder run:

   bash desk rehearse builds/studio-desk

   Substitute your approved four-tool project. Start a voice call and ask the ZZ201 question. If it asks which date, say “November third, 2026.” Repeat in a fresh call for November fourth. Inspect the arguments as well as the spoken answers. The flight and weather data are simulated; Mantle conversations and Deepgram audio still require the usual credentials.

4. Compare your observations with the table. A direct reader check tests the data handling. Only a conversation shows whether the generated skill asked for clarification at the right time.

If the desk says 8 °C for November 3, compare the spoken answer with the tool result. A correct tool result paired with the wrong spoken temperature needs a skill repair. If the tool itself used the earlier scheduled hour, check the compiled reader: existing products retain their old tool code. Keep the failing build and compile a fresh directory from the same approved candidate to pick up the guard. Compare both builds against the same fixture and keep their tool events. To return to public providers, stop Inspector and start the project normally:

bash desk inspect builds/studio-desk

2. Exercise the failures (15 minutes)

Run:

bash desk test

Open the tests. Find the flight that departs at 23:30 UTC but still belongs to the next local date at Oslo. Why would filtering by the UTC date lose or misclassify departures?

Try these inputs and the unsupported route:

bash desk data weather ZZZ
bash desk data fx USD GBP -5
bash desk data flights JFK LHR

Inspect the structured unavailable result and how the desk handles the unsupported route. Ask why “the board is unavailable” and “there are no flights tonight” would lead a traveler to different decisions.

3. Record a release decision (8 minutes)

Write a note with the build mode (Codex, hosted, or sample), candidate path and hash, which Mantle project you trained, and one observed tool result. State which providers answered live and which you only exercised with fixtures. If the agent offered a seat, invented a flight, or substituted current conditions for missing arrival weather, defer approval and issue a new brief.

4. Continue at home (7 minutes now, then at your own pace)

Save the note, stop the Inspector with Ctrl+C, then use … → Stop codespace in Your Codespaces. To resume, reopen that workspace and run this command with the name you approved:

bash desk inspect builds/codex-desk

This reuses the project without starting another paid build.

Extension A · Improve the conversation (20 minutes). Ask Codex for another four-tool desk that responds in Spanish and asks for the travel date when a flight number has multiple records. Review, approve into a new folder, and try the same trip in Spanish. Compare the inspected arguments and the answer with your earlier result.

Extension B · Implement another destination with Codex (30 minutes). Open travel_data.py and the tests. In a workshop terminal run:

"$HOME/.local/node_modules/.bin/codex"

Give it this brief:

Add Tokyo Haneda (HND) to the supported airport catalog. Use verified airport coordinates, Asia/Tokyo and JPY. Update the factory’s airport guidance to match. Write an offline test proving a forecast hour renders in Tokyo local time and a test for a departure near midnight. Run the suite and show the diff.

Review the changes, rerun bash desk test, and generate a new product directory. The compiler copies the readers into each product, so earlier builds keep their original behavior. Use the provider CLI and Inspector to compare HND weather and a USD-to-JPY conversion.

Extension C · Improve flight coverage (45 minutes). Extend the board reader to a third Avinor airport. Add its airport metadata and a test for a route with no remaining departures. Keep coverage explicit.