An airline morning starts hours before the first passenger boards. Flight plans, crew rosters, schedule changes, weather and slot data all have to land in the right systems before the first departure wave. When one of these feeds fails silently, the cost shows up as delay minutes, missed connections and compensation claims by the afternoon. This article explores unified orchestration in aviation: one control plane for the data pipelines, infrastructure automation, application workflows and business processes that keep an airline running.
Picture a realistic incident. A routine certificate rotation runs overnight on the integration infrastructure. The rotation succeeds, but a script still points to the old certificate. A flight data feed handler restarts with it. The restart reports green, yet no data arrives. The schedule reference data that operations control depends on goes stale, and by the time the morning wave ramps up, controllers work with outdated information.
Four teams own four pieces of this chain: the platform team, feed engineering, the ops data team and operations control support. Each team sees a green dashboard in its own tool, and nobody sees the chain. The failure is not exotic. Airlines run hundreds of certificate-authenticated interfaces, from schedule files over SFTP to partner and codeshare APIs, messaging gateways, and weather and slot feeds. Any of them can break the same way.
Disruption is expensive, and recovery takes longer than the failure itself. In September 2026, a fault in the UK air traffic control flight data system led to around 2,000 cancelled flights. The fault was fixed within hours. Airlines needed several days to rebuild schedules, reposition aircraft and crews, and rebook passengers. The recovery is a coordination problem across many systems, and it starts the moment the root cause is gone.
The failure does not even have to start inside the airline. In October 2026, a fault at a third-party technology provider hit Southwest Airlines. Gate agents processed passengers by hand for about two hours, and more than 900 flights were delayed. Check-in, boarding and baggage depend on a chain of vendors and cloud services, and the airline owns the recovery when one link breaks.
Regulation raises the stakes further. The EU passenger rights regulation EU261 was amended by Regulation (EU) 2026/2202, and most of the new provisions apply from 23 October 2027. The amendment turns passenger rights into hard deadlines inside airline processes:
These rules cut across customer service, operations, finance and digital channels. Every deadline needs a clock, an owner and a record.
The industry is investing heavily. According to SITA’s Air Transport IT Insights 2025, air transport spent a record 50.8 billion US dollars on technology in 2025. Sixty-three percent of airlines already use AI in operations control for disruption management, aircraft assignment and crew planning. Yet 49 percent of airlines name fragmented data as the biggest barrier to managing disruption early. Only 17 percent use AI to monitor turnaround activity in real time.
The airline IT landscape grew in silos over decades. The passenger service system (PSS) handles reservations and ticketing. The departure control system (DCS) handles check-in and boarding. Operations control, crew management, maintenance (MRO), baggage, loyalty and revenue accounting each run their own platforms, often from different vendors and different eras. AI in operations only works when the data and the actions between these systems are fresh, complete and traceable. A model that works on stale schedule data recommends the wrong recovery action.
Unified orchestration in aviation means one control plane for data, infrastructure, applications and business processes across the airline. AI agents are governed across all four. Instead of a separate scheduler, audit trail and permission model per silo, one engine coordinates what runs, when it runs, what happens when it fails and who approved it.
A single workflow in this model can rotate a certificate, restart a feed, rebuild reference data and open a case for operations control. The whole chain runs as one execution with one audit trail. The same architectural idea applies in other industries, as described for unified orchestration in manufacturing, unified orchestration in financial services and unified orchestration in telecom. Manufacturing draws the same hard boundary above the real-time control loop that aviation draws around avionics. The aviation version maps it to airline workloads.
Every airline already orchestrates, but each domain does it with its own tool, as the following picture shows.
The incident from the opening story crossed all four domains, and none of the four tools saw it end to end.
A unified orchestration platform puts one engine above the domains. Workflows are defined as code, versioned in Git, and triggered by schedules or by events such as a Kafka or IBM MQ message from the PSS. Access control, secrets, audit logging and human approval apply to every workflow the same way, whether it moves data or rotates a certificate. The PSS, DCS, ops control, crew, MRO and revenue accounting platforms remain the systems of record. Workflows call them as tasks.
Kestra makes this concrete. It is an open source orchestration platform under the Apache 2.0 license. Workflows are declarative YAML, triggers are event-driven, and existing Python, SQL or shell scripts run as tasks without rewriting. Enterprise security and governance features and a managed cloud service build on the same open source core. The following picture shows Kestra as the control plane above the four airline domains, while the systems of record stay where they are.
No airline adopts a platform because of an architecture diagram. Most teams start in one domain with one painful workflow. A data team wants replayable backfills for revenue accounting. An infrastructure team wants certificate rotation that runs on an event rather than a ticket. An operations IT team wants retries and an error path around a fragile rebooking script. The orchestrator has to win that first use case on its own merits, and teams often choose it for practical reasons such as lightweight deployment and a short path from an existing script to a production workflow. The second domain then reuses the audit trail, the identity integration and the lineage graph that already exist.
Other use cases cross all four domains from day one. Launching a new route loads the schedule into the data platform, provisions check-in and boarding at the new station, updates the PSS and crew systems, and waits for network planning to approve before the flights go on sale. No tool built for a single domain covers this chain, so the end-to-end coordination is the reason to bring in an orchestrator.
Aviation has hard boundaries, and the latency spectrum shows where a workflow engine belongs.
Avionics and flight controls are embedded, certified, critical real-time systems. They stay isolated from enterprise IT and never run in a workflow engine. Flight events, partner APIs and operational messaging move in milliseconds through data streaming platforms such as Apache Kafka and through request-response APIs. These systems move and reshape the data.
Workflow orchestration works in the range from seconds to hours. It coordinates feed rebuilds, certificate rotation, rebooking sequences and approvals. The orchestrator reacts to streaming events and calls the APIs. The payload stays in Kafka, in the PSS and in the operational systems built for it. The article on event-driven workflow orchestration on Apache Kafka with Kestra covers this pattern in technical depth.
Many airlines already run data streaming in operations, and that layer is the natural trigger for orchestrated recovery.
The public success stories show the pattern:
The streaming layer answers what is happening right now. The orchestration layer answers what has to happen next, across which systems, with which approvals. A detected disruption becomes a workflow that rebooks in the PSS, books meals and hotels, notifies crew and ops, opens the EU261 case and waits for approval above a cost limit. Each step reports its status back as an event. The broader overview of Apache Kafka in the airline, aviation and travel industry lists more examples on the streaming side.
Irregular operations (IROPS) show the value in one concrete flow, now with the deadlines of the amended EU261 built in.
A cancellation event arrives on a Kafka topic from the PSS. The workflow starts within seconds and branches. One path notifies crew scheduling and operations control. The other asks for the passenger’s choice. A refund runs automatically and has to complete within seven days. A rerouting request starts a three-hour timer and searches options across the airline, partner carriers and other transport modes. If the deadline passes without a comparable offer, the workflow switches to the self-rerouting path and prepares the reimbursement.
Compensation claims run as their own process in the same engine. A claim can arrive weeks later. The workflow checks it against the codified list of extraordinary circumstances. Disputed cases pause the execution and wait for a person with the right role. The 30-day decision timer runs across the whole case, so nobody has to track deadlines in a spreadsheet.
Every step, deadline and approval lands in one audit record. Operations control, customer care and compliance look at the same execution instead of three tools and an email thread. When a national enforcement body asks why a passenger waited more than three hours for a rerouting offer, the airline answers from the execution history in minutes.
The second large change in airline IT is commercial. Under IATA’s Modern Airline Retailing program, airlines move from tickets, PNRs and EMDs in the legacy PSS to a single order record based on the ONE Order standard. The transition takes years. During that time, the legacy PSS and the new order management system run side by side, often airport by airport and partner by partner. Interline partners that still run the old model extend the hybrid phase further. BCG estimates the full transformation at 50 to 100 million US dollars for a medium-sized airline.
A hybrid phase this long is an orchestration problem as much as a product decision. Each cutover step needs a sequence: switch a station, run both systems in parallel, reconcile orders against PNRs and tickets, route exceptions to people, and roll back when the numbers do not match. Revenue accounting and settlement have to follow every step. A control plane that already coordinates data pipelines, infrastructure changes and approvals can run these migration workflows with the same audit trail. The order management platform itself stays the system of record.
Agentic AI is arriving in airlines on two fronts, and both need the same governance.
On the passenger side, conversational agents handle rebooking requests during disruptions. The agent proposes options. A deterministic check inside the workflow verifies fare rules and policy before the rebooking runs in the PSS as a task with retries. Requests outside policy go to a human agent desk. A rebooking agent is only as good as its connection to the PSS, so the rebooking itself runs as a governed workflow task.
On the operations side, back to the opening incident. An AI agent running as a task inside the workflow engine starts from the stale schedule asset, walks the lineage back through the feed handler to the certificate rotation, and finds the hardcoded reference. It opens a case with the root cause and a proposed fix. It has no permission to apply anything. An engineer reviews the case, applies the fix through Git and reruns the chain.
Technically, both agents are workflow tasks. In Kestra, an AI agent task calls the LLM provider the airline chooses and reaches the PSS, the lineage graph or the case management system through tools such as Model Context Protocol (MCP) servers. The tools an agent may use are declared in the workflow YAML, so the scope of every agent goes through review in Git like any other change. MCP also works in the other direction. A conversational agent from another vendor can call the governed rebooking workflow as a tool, so every PSS change still runs through the same fare rule check and audit trail.
Both agents run under the same rules as every other task: access control, approval gates, a complete audit trail and the option to use self-hosted models where data must stay in your own data center or cloud account. Without this governance, an agent stays a pilot. The timing matters, because Amadeus and Microsoft expect most airlines to move AI agents from exploration to production within about 18 months. Voice rebooking and AI-supported turnaround management are among the first use cases. Both touch the PSS and the operational plan, so the governance has to be in place before the first agent goes live.
The orchestrator owns the sequence, the retries, the deadlines, the approvals and the record. It does not own the payload, and it does not replace the systems of record:
If a use case is pure high-throughput data movement or lives entirely inside one of these systems, a workflow engine adds little there. The value starts where a process crosses system and team boundaries.
According to SITA’s Air Transport IT Insights 2025, airlines spent 36 billion US dollars on IT in 2025, and much of the next wave goes into AI, offers and orders, and regulatory change. All three depend on coordination across systems that were never designed to work together. For the market, this means spend shifts from point integrations toward a coordination layer above the existing platforms.
Start with one workflow in one domain: a replayable revenue accounting pipeline, an event-triggered certificate rotation, or an EU261 refund flow with real timers and an error path. Pick an owner, define the business outcome and measure it. The October 2027 deadline of the amended EU261 is a practical anchor for the first business process workflow. Set up the first workflow the way all later ones should run, versioned in Git, started by events, and with approvals inside the flow where the audit trail records them. The second domain is where unified orchestration in aviation starts paying off, because the audit trail, the lineage and the governance already exist.
To follow this work across data integration, workflow orchestration, process intelligence, and trusted agentic AI, subscribe to the newsletter and connect on LinkedIn.
AI agents pile up debt when retries, approvals and audit land in the wrong layer.…
My Lufthansa HON Circle experience in 2026 as a frequent flyer with around 30 trips…
Humanoids get the headlines, but most physical AI value comes from what happens after a…
Within a month of Jev by TypeSafe AI, hyperscalers, AI labs, data platforms and open…
Kafka moves the events, but nothing coordinates what happens next. This post shows how Kestra…
The Industrial IoT Landscape Q4 2026 maps vendors and open source from edge to cloud…