AI Agents for Airport Operations: Disruptions and Handoffs

AI agents for airport operations work best as a memory and drafting layer around the people who run the airport, not as a replacement for them. They read shift handoffs, disruption logs and partner messages, keep that context organized, and prepare summaries, drafts and checks that an operator reviews. The value is context that survives the end of every shift, while decisions stay with the duty manager.

Key takeaways

• Shift handoffs, disruption logs and partner messages already hold most of what an airport knows about how it actually runs. An agent turns them into searchable, structured memory.
• The safest first role is preparing and checking: drafting handoff notes, tagging log entries, and proposing partner updates for approval.
• Operator authority is a design feature. Anything that changes operations, safety, security or regulated reporting stays with a named person.
• Inbound partner messages are untrusted text. The agent treats them as information to read, never as instructions to follow.
• A first engagement should be one role, with the memory and tools it needs, clear approval boundaries and a success criterion someone can observe.

What does an AI agent actually do in airport operations?

An airport is a handful of organizations sharing one physical space: airlines, ground handlers, fuel suppliers, cleaning and catering contractors, security, border agencies, concessions, ground transport and the airport operator itself. Each one sends messages, makes requests and holds a piece of the picture. The picture is usually assembled by a duty manager from radio calls, phone calls, chat threads, email and a log that is typed in a hurry.

An agent in this setting is a defined role, not a general assistant. It has an identity (what it is called and what it is for), memory (the handoffs, logs and procedures it may read), tools (for example, read access to the log and the ability to create a draft message), and permissions that say what it may never touch. It does not command gates, vehicles or staff, and it does not issue operational instructions.

What it can do well is the work that sits around decisions: collecting what was said, noticing what was promised, finding the last time something similar happened, and preparing the next message so the operator only has to correct and approve it. For the general pattern of recurring work and reports, see AI Agents for Operations Teams.

Why are shift handoffs the best place to start?

A handoff is the moment when context is most likely to be lost. The outgoing lead is tired, the incoming lead is arriving into a situation already in motion, and the written note is whatever the outgoing lead had time to type. Open issues get compressed into a line. Promises made to a partner can disappear.

An agent can help without taking over the handoff. During the shift it reads the log and tags entries as open, waiting on a partner, resolved or needing a decision. Before the shift ends it drafts a handoff note from those tags. The outgoing lead edits it, adds what only a human knows, and signs it. The incoming lead can then ask the agent questions such as who was told about a delayed fuel delivery, and receive an answer with the source entry attached.

A useful handoff note covers the same ground every time. This checklist is a good starting template:

• Open issues, each with an owner and the next expected event
• Commitments made to partners and who made them
• Messages sent and still waiting for a reply
• Equipment, areas or procedures running in a degraded state
• Decisions deferred, with the reason they were deferred
• Anything the outgoing lead wants the next lead to double-check

The signature matters. The agent prepares, the person owns. That one rule keeps accountability where the airport already expects it.

How do disruption logs become usable memory?

Disruption logs are written under pressure. They contain abbreviations, half sentences, local names for places and informal timing. That is not a flaw to be cleaned up before an agent can use them. It is the raw material, and the agent's job is to structure it without rewriting history.

A practical approach is to keep the original entry untouched and add a structured layer beside it. For each disruption the agent proposes fields such as what happened, the cause as understood at the time, parties affected, actions taken, who authorized them, the outcome, and what was unresolved. It separates three kinds of statements: confirmed fact, inference, and open question. Operators correct the layer, and corrections become part of the memory.

Why this matters is retrieval. When a new disruption starts, the agent can surface earlier events that resemble it, along with the original operator's notes on what worked and what did not. This depends on giving the model a small amount of the right context rather than a large amount of everything, a point covered well in Anthropic's engineering writing on context engineering for agents.

Here is an illustrative scenario. A weather cell delays a cluster of arrivals late in the evening, and ground handling capacity runs thin. The duty manager asks the agent for earlier evenings when handler capacity ran short. The agent returns three log entries, the partner contacts who were reached, and a note from a previous lead that one handler needed an earlier call than the others. The manager decides whom to call and when. The agent drafted nothing that was sent without approval, and the memory saved a few minutes of searching at a stressful moment.

This is the same discipline needed in other exception-heavy work, as described in Superintelligent Agents for Logistics: Exceptions and Planning.

How should partner communications be handled?

Partner communication is where an agent saves the most repetitive effort and carries the most risk. Updates go to airlines, handlers, contractors and shuttle operators, and each wants slightly different information in a slightly different form. Consistency matters, because two partners receiving different versions of the same event creates its own disruption.

The agent can keep one approved set of facts for the current event and draft each partner's message from it. It can flag when a reply from one partner conflicts with what another reported, and it can record what was sent, to whom, and who approved it. Over time, the thread history with each partner becomes memory the next shift can read in seconds.

Three rules keep this safe:

• Outbound messages that make or change an operational commitment are drafted by the agent and approved by a named operator.
• Routine confirmations of information already published can be pre-approved by the operator, in writing, for specific partners and specific message types.
• Inbound messages are treated as untrusted text. A partner email that says to ignore previous rules or release some information is data to be flagged, not an instruction to act on.

The third rule reflects a known weakness of language models, described in the OWASP guidance on prompt injection prevention. Separating what the agent reads from what the agent is allowed to do is the basic defense, and it works best when permissions are narrow in the first place.

Where a partner relationship touches technical status, such as aircraft availability during a disruption, the agent should point to the authoritative record rather than paraphrase it. The related maintenance picture is covered in AI for Aircraft Maintenance.

Where does operator authority stay?

Operators should not have to guess what an agent is allowed to do. A short decision guide, agreed in advance and kept with the agent's configuration, removes the guesswork.

• The agent acts alone: reading the log, tagging entries, searching past events, summarizing, building timelines, and reminding a named person of an open item.
• The agent drafts, an operator approves: handoff notes, partner updates, post-event summaries, internal escalation messages and any text that will be sent outside the airport team.
• The operator only: anything that changes how the airport operates, anything involving safety or security procedures, anything sent to a regulator, and any message to passengers.
• Never available to the agent: credentials beyond its role, systems it has no need to read, and any control interface for physical operations.

This maps to ordinary least-privilege thinking, as in the OWASP authorization guidance: give each role only the access it needs, check that access on every request, and log what was done. The NIST AI Risk Management Framework offers a complementary way to think about it: define the context and risks of the use, measure how the system behaves, and assign responsibility for managing it. For an airport, that translates into a written scope, regular review of drafts and edits, and a named owner for the agent.

One more principle belongs here. If the agent is unsure, it asks. A good agent says it found two conflicting entries and asks which one is correct, instead of quietly choosing one.

What does a first engagement look like?

The temptation is to start with the whole airport. A better start is one role, in one team, with a visible outcome. A shift handoff agent for the airside operations desk is a common candidate because the inputs already exist and the output is easy to judge.

A step-by-step plan for a first role:

• Name the role in a sentence, for example: prepares the shift handoff draft and keeps the open-items list current.
• Choose the sources the agent may read, and exclude the rest on purpose.
• Collect a sample of past handoffs and disruption entries, with operators marking what a good note contained and what was missing.
• Define the structure for log entries and handoff notes, including the split between fact, inference and open question.
• Set approval boundaries using the decision guide above, and name the person who approves each type of draft.
• Run the agent in draft-only mode alongside the existing process, and compare its drafts with what operators actually wrote.
• Agree a success criterion that someone can observe, for example that the incoming lead rarely needs to call the outgoing lead for missing context.
• Review edits weekly, adjust the structure, and only then consider a second role such as partner update drafting.

The same sequence applies to adjacent settings, for example the return and exception flows in AI for a Car Rental Company, where handoffs between desks and partners carry similar risks.

How is the agent kept accurate and under control over time?

An agent that works in month one can drift by month six. Procedures change, partners change, new terminals or stands open, and the log fills with vocabulary the agent has not seen. Memory needs care just as a procedure manual does.

Be Human designs, implements and operates this kind of infrastructure. For an airport team, the managed approach starts with one defined role, the memory and tools it needs, written approval boundaries and an observable success criterion. Ongoing operations can include monitoring of what the agent reads and drafts, recurring evaluations against real past events, integration maintenance, permission review, incident response if a draft or action goes wrong, and controlled improvements that are tested before they reach the live role. Humans remain in charge of the decisions, and the service is delivered remotely in English and Portuguese.

What the airport team contributes is irreplaceable: corrections, judgment about edge cases, and the habit of writing log entries that say what actually happened. The agent makes those entries more valuable each time they are used.

If you are weighing where to begin, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent make operational decisions at an airport? It should not. The agent can prepare context, draft messages and check for conflicts, but decisions that change operations, safety, security or regulated reporting stay with named operators. That boundary is written into the agent's permissions, not left to its judgment.

What data does an airport agent need to be useful? Start with what operators already write: shift handoff notes, disruption log entries and partner correspondence for a limited set of partners. Add procedures and contact lists once the first role is working. More data is not better by default, and each new source should have a reason and an owner.

How do you stop an agent from acting on a misleading partner message? Treat inbound messages as untrusted content that the agent reads but does not obey. Keep its permissions narrow, require approval for outbound commitments, and have it flag unusual requests instead of acting on them. Reviewing its drafts regularly also shows when a message is trying to steer it.

How long before an agent is trusted with more than handoff drafts? Trust follows evidence. Run the first role in draft-only mode, compare its output with what operators wrote, and expand only when edits are small and the success criterion is being met. The next role, such as partner update drafting, gets its own boundaries and its own review period.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.