In autumn 2026 it is hard to find an airport conference deck or trade article without “agentic AI” in it. The promise is roughly the same everywhere: agents in the operations centre watch the traffic, propose gate swaps, re-sequence stands and reschedule ground equipment, all in real time.
In mid-October, Thoughtworks made a more sober point in one of its articles: most airports do not have one coherent operational picture, and an agent acting on conflicting gate-status data could send a crew to an occupied gate. We agree, and it is worth going one step further.
An agent is only as good as its worst data source
Take an ordinary situation. The AODB says stand 14 is free. The turnaround tracking system says an aircraft is still there because pushback is late. The roster says the loading team is available; the card reader says two of its members have not clocked in yet.
An experienced dispatcher resolves this without noticing. They know the AODB updates late for remote stands, they know the card reader at gate 2 sometimes stops sending, and they know whom to call. None of that is written down.
The agent does not know any of it. If nothing says which source is authoritative for which field, and how many minutes old data can be before it counts as stale, the agent either believes the first source that answered or the one that best fits how the question was phrased. Neither is a rule.
So the first project is the data: the sources brought into one place, with shared definitions, and the data carrying its own meaning so a person and a model read it the same way. It is duller work than an agent demo, and everything after it depends on it. We wrote about this at more length in the post on operational data.
Where the decision should be made
Suppose the data is in order. The agent proposes a gate swap. Did it account for the crew’s rest time, their licences, the fact that the tug they need is in maintenance, and the walking time between the two stands?
A language model always returns an answer, and the answer will sound plausible. What it cannot guarantee is that the answer is feasible, because it has no notion of “there is no such solution”. We argued this in more detail in an earlier post.
The division of labour we think is right:
- the language model translates what happened into parameters the solver understands,
- the solver computes the plan within the constraints,
- the language model explains the result to whoever decides.
So the agent can perfectly well call the solver, and that is a good direction. It just should not be the solver.
What the language model is genuinely good for
What it is actually strong at: reading text. A ground handler’s operating procedures, the collective agreement, the rostering rules and the internal instructions are all documents. From them, a language model can draft the first version of the constraint model, which a domain expert then reviews and corrects. That saves real work, and its mistakes are visible because a person checks them.
The other area is the interface. The shift supervisor does not need to see an optimizer. They say what happened, change the plan in words, and get back why this is the new plan. The solver makes the decision in the meantime.
Five questions for the vendor
If a vendor offers an agent for operations control, ask for answers to these before anyone watches a demo:
- When two sources contradict each other, which one is authoritative, and where is that written down?
- Who checks that a proposal is feasible: the model itself, or a solver that knows the constraints?
- Does it give the same proposal twice in a row for the same input?
- Can you trace afterwards why it decided as it did, in a form a regulatory or contractual review will accept?
- What happens when the model provider updates the model and its behaviour changes?
The last question is the most uncomfortable one. Language models are improving fast, but their behaviour is hard to control. Before they are trusted with operational decisions, they will have to be certified, as everything else at an airport is. It is worth building now so that this is possible.
The order
First, one operational picture with shared definitions. Then a deterministic decision layer that knows the constraints. The language layer goes on top, and there it is very useful.
You can start in the reverse order. What you get then is a system that talks well and refers confidently to whichever data happened to be available.
Optimum Intelligence builds the operational data layer (Understand · OptiSight) and the erdosP-3 solver, callable by people and by software, with the language layer on top. Read more about it, or get in touch.