Auto-fix your calendar when a flight slips, and flag what's at risk

Build me an agent that treats my calendar as the record of my travel day and keeps it truthful. When a flight moves, I want the calendar entry corrected in place, and I want to be told which of that day's meetings I am now about to miss. I do not want a running commentary on every small delay.

Trigger: cron, every 30 minutes between 6am and 10pm in my calendar timezone. Each run is one agent turn that decides whether anything is worth acting on, and the common case is that nothing is and the run exits quietly.

1. Read the day. Call Google Calendar List Events on my primary calendar from the start of today to the end of tomorrow, with singleEvents true and ordered by start time. This single call serves two purposes: it finds the flights, and it is also the list of meetings I will later check for conflicts, so do not fetch the calendar twice. Note the calendar's timezone, since every time you write or quote must be in it.

2. Find real flight numbers. Scan each event's title, location, and description for IATA-style flight designators: a two-character airline code (two letters, or a letter and a digit) followed by one to four digits, with an optional space, case-insensitive. 'BA 249', 'UA1234' and 'LH 401' all count. Be deliberately conservative about false positives: ignore matches that sit inside a longer alphanumeric token, and ignore common lookalikes such as quarter labels (Q3 2026), half-year labels (H1 2026), priority tags (P1), and version numbers (v2 1234). If no event carries a flight designator, exit without calling anything else.

3. Protect the request budget before looking anything up. AviationStack plans carry a monthly request quota and the free tier is small, so the lookup set must stay tight. Deduplicate by flight number plus date, so one flight appearing on several events is looked up once. Only look up a flight when it is actually in play, meaning from roughly six hours before its scheduled departure through its scheduled arrival. A flight sitting on tomorrow evening's calendar does not need checking at 7am today. Never look up a flight number that did not come off the calendar.

4. Check live status. For each remaining flight, call AviationStack Get Flights (Real-time and Historical) filtered by the flight's IATA number. Read the flight status (scheduled, active, landed, cancelled, incident, diverted), and for both departure and arrival read the scheduled, estimated and actual times, the delay in minutes, and the gate and terminal.

5. Convert timezones before comparing anything. AviationStack reports each airport's times in that airport's local time, and each departure and arrival object carries its own timezone. Convert both into my calendar's timezone first, then compare. Never compare an airport local time against a calendar time directly, and never write an unconverted time to the calendar or to Slack. This is the single most likely source of a wrong answer, so be explicit with yourself about which timezone each value is in.

6. Decide whether this is material. It is material when the departure or the arrival has moved by 15 minutes or more against what the calendar currently says, or when the status has become cancelled or diverted. Anything smaller is noise: ignore drifts under 15 minutes entirely, and do not touch the event for a gate change alone. Cancelled and diverted are always material even if no time changed.

7. Do not repeat yourself. Keep the last status you acted on in the event description as a short machine-readable line, for example 'Acted on: delayed / dep 14:35 / arr 17:20'. At the start of each run, parse that line from the event. If the flight's current state matches what you already acted on, stop there and send nothing, even though the flight is still delayed. Only a further change of 15 minutes or more, or a move to cancelled or diverted, justifies acting again.

8. Correct the calendar entry. Use Google Calendar Patch Event so that only the fields you name are touched and the rest of the event survives. Move the start and end to the live departure and arrival times, expressed in my calendar timezone. Rewrite a clearly delimited status block at the end of the description holding the current status, departure and arrival times with the original times in brackets, gate, terminal, the last-checked timestamp, and the 'Acted on' line from the previous step. Preserve whatever I wrote in the description myself: replace only your own block, never the whole field.

9. Work out what is now at risk. This is the part I care about most. Take the corrected arrival time, add a realistic ground allowance for deplaning, baggage and getting to the meeting (default to 60 minutes, and treat it as a tunable), and call that the time I am genuinely free. Then walk the rest of that flight's day in the calendar I already fetched. Name every event that now starts before I am free, in order, and say by how much I miss it. For the events I can still make, say how much slack is left before each one. If a delay costs me nothing, say that plainly rather than inventing a risk.

10. Tell me in Slack. Call Slack Open a Conversation to get my direct message channel, then Slack Send a Message. Lead with what changed on the flight, in one line: flight number, route, the new time versus the old, and gate and terminal if known. Then the conflict list, which is the real payload. Keep it short and scannable with Slack mrkdwn, and bold the change. Use plainly stronger wording for a cancellation or a diversion than for a delay, and in that case lead with the disruption rather than the times.

Edge cases: if AviationStack cannot resolve a flight number, tell me once so I can fix the calendar entry, then stop retrying that event for the day. If the same flight is on several events, correct the one that looks like the real travel block and do not send duplicate messages. Leave all-day events alone rather than trying to give them times. If a flight has already landed and nothing changed, do nothing. If my monthly request quota is exhausted, tell me once in Slack instead of failing silently, because a quiet workflow and a broken one look identical from the outside.