How AvioBook builds turnaround insights from operational data with Amazon Bedrock AgentCore

This post is co-written with Petra Lafond, Product Manager, and Maarten Cardinaels, Tech Lead at AvioBook, a Thales Group Company.

Airlines run on tight, cascading schedules, and accessing operational data holds the key to protecting them. During turnarounds, a few minutes of delay at one gate can ripple through an entire day of connections. It is here that airlines win or lose the fight: the time between an aircraft’s arrival and its next departure. Time lost at the gate alone costs an airline approximately $20 a minute. Fuel burn, crew costs, gate fees, missed connections, and the knock-on effect on the rest of the day’s schedule all add to that. For a mid-size carrier flying 200 flights a day, where turnaround is the binding constraint on departure, cutting average turnaround by 2 minutes is worth roughly $240,000 a month.

AvioBook, a Thales Group Company, builds software for flight and ground operations. Its communication platform, AvioBook Connect, has been in service with airlines since 2018, with its current API platform launched in 2025. It is where flight crew, cabin crew, dispatch, and station operations teams coordinate the turnaround. AvioBook Connect organizes work around flightrooms, one live chat per flight. In each room, the platform’s APIs notify participants of aircraft changes, delays, new flight plans, boarding progress, and whatever else an airline chooses to configure. AvioBook Connect keeps both the hard data behind those automated messages and the soft, conversational data around them. Crew messages are processed entirely within that airline’s own data environment, under the airline’s control.

Capturing that data is only half the job. A flightroom full of timestamped events and messages is still an archive: useful when someone requests it, but only as good as their patience for scrolling back through weeks of history and cross-referencing it against a delay code by hand. Turning that archive into something people use in the moment is a different challenge.

This was the starting point for AvioBook’s conception of Connected Analytics, which was then prototyped on Amazon Bedrock AgentCore, an agentic platform for building, deploying, and operating highly effective agents securely at scale using any framework and foundation model. Sitting on top of AvioBook Connect’s data, it is designed so airline managers and operations control center dispatchers can ask questions in plain language instead of digging through the archive themselves. Two agents, one built for each role, do the digging: pulling the relevant flight events, checking them against what was actually logged in the flightroom, and returning a direct answer with the evidence behind it.

In this post, we describe the operational problem AvioBook Connected Analytics is designed to address, give an overview of the multi-agent proof-of-concept architecture AvioBook validated on AWS using Amazon Bedrock AgentCore, and share the results AvioBook Connect customers are already seeing from putting turnaround data to work.

The challenge: Rich data that only answered when asked

AvioBook Connect organizes each flight into a flightroom. Every turnaround captured there leaves a durable, timestamped record covering automated events pushed through Connect’s APIs, such as aircraft changes, delays, new flight plans, and boarding progress, alongside the messages the operational teams exchange around them.

But collecting the data and using it are not the same thing, and the gap showed up in three recurring ways.

Operations were effectively a black box. Teams working the same turnaround rarely shared a consistent, real-time picture of it, and often described the same delay differently. When an audit followed, the record was word of mouth, with the crew having to recall the sequence of events on a flight they handled weeks earlier. Whether the crew accounts and paper procedures held up under scrutiny was a separate question airlines might struggle to answer.

Delay codes told half the story. Coding happens under time pressure, usually by one person, and mostly attributing the dominant delay. Even where multiple codes are permitted, the upstream event that caused the dominant delay frequently doesn’t get coded at all. A delay code can be filled in correctly by the rules and still mislead about what happened. Because delay codes feed both internal and external reporting, a system that flags one as wrong isn’t only an analytics footnote, it’s a compliance question for the airline.

Answers required a data team that airlines might not have. Historical data beyond a short window wasn’t readily accessible, with each question meaning a manual query or a data extraction request. On thin margins, few airlines can absorb the cost of a dedicated analytics team to do this work.

Within airlines, this analysis work usually falls to two specific roles who have different needs:

Airline managers, responsible for on-time performance (OTP), need to know why delays happen, whether ground procedures are being followed, and how to account for it when an audit asks. They work with historical data and patterns over time, asking questions like “What are the probable sources of delay for flight X?”, “What are the most common non-weather sources of delay?”, and “Are the procedures for process X being followed?”

Operations control center (OCC) dispatchers carry the network-wide version of the same problem: a delay building at one gate can spread through a full day of connections. They work with live data and need to see disruptions as they begin and understand fleet-wide impact. They ask questions like “What downstream effects will there be from the disruption at X airport?”, “Are there any flights with more than 250 passengers currently at risk?”, and “Which flights with the highest Value at Risk (VaR) index are flying today?”

What both roles need is a fast, human-readable, evidence-based answer, with room to dig deeper and a way to check whether a delay code holds up, not as an automatic verdict, but as decision support the airline manager can act on with confidence. That is the gap AvioBook Connected Analytics is designed to close.

The approach: A multi-agent architecture built on Amazon Bedrock AgentCore

AvioBook Connected Analytics is designed to deliver two capabilities: natural language conversations with operational data, and agentic delay code validation. Rather than one general assistant, it runs two role-specific agents. An airline manager-focused agent handles historical analysis and delay code validation. An OCC dispatcher-focused agent handles live operational queries and disruption impact. Each agent is scoped to its persona, so a user interacts only with the agent authorized for their role.

The following diagram shows the architecture of AvioBook Connected Analytics on AWS, and the flow starting from a user’s query to a grounded answer.

Figure 1: The AvioBook Connected Analytics architecture on AWS

Amazon Bedrock AgentCore provides the managed foundation to deploy and orchestrate these agents without building agent infrastructure from scratch. The agents run on AgentCore runtime, a capability of Amazon Bedrock AgentCore that provides a fully managed compute environment for deploying AI agents and Model Context Protocol (MCP) servers. They use AgentCore memory, a capability of Amazon Bedrock AgentCore that gives AI agents the ability to remember past interactions, and maintain conversational context across user sessions. Tool access is brokered through AgentCore Gateway, a capability of Amazon Bedrock AgentCore that provides a single, secure entry point for agentic traffic. AgentCore Gateway exposes MCP targets, which gives the agents a consistent, governed way to call the functions that reach AvioBook’s data.

AgentCore runtime is configured to use a JSON Web Token (JWT) for inbound authentication. On the AvioBook Connect front end, Amazon API Gateway is set up with an AWS Lambda function as its target. The Lambda function invokes the runtime with a valid JWT access token in the request header, which the runtime validates before the agent runs. The token carries the user’s identity, so each request is tied to a specific airline account and an AWS Region. That authentication and scoping is worth calling out on its own. Every question an agent answers is tied to one airline’s identity and one airline’s data, which is exactly what airline security and IT teams evaluating this kind of tool want to see.

The following numbered steps trace the path from a user’s question to an answer:

1. AvioBook Connect users (airline manager or OCC dispatcher) ask questions in natural language, entering through Amazon API Gateway WebSocket API.
2. A Lambda Authorizer function in WebSocket API verifies the request’s JWT against Amazon Cognito, which issues a JWT per request.
3. The authenticated request triggers an AWS Lambda target, which invokes the appropriate agent on AgentCore runtime.
4. The agent updates session context in AgentCore memory.
5. The agent calls tools through the AgentCore Gateway using MCP.
6. The gateway invokes the corresponding tool function, implemented as an AWS Lambda function.
7. The tool function issues relevant data queries to Amazon Athena.
8. Amazon Athena resolves table schema from the AWS Glue Data Catalog and scans Parquet data in an Amazon Simple Storage Service (Amazon S3) bucket, partitioned per airline.
9. In the background, an AWS Glue crawler and extract, transform, and load (ETL) job converts incoming JSON to Parquet in Amazon S3 and registers the schema in the Glue Data Catalog, keeping the data query ready.
10. The grounded answer returns along the same path back to the user, with the supporting evidence behind it.

Delay code validation reuses the same data access path. The agent compares the logged delay code against the sequence of underlying events and surfaces cases where the code looks inconsistent, or where more than one code should have been applied, framed as a second opinion for the airline manager to review, not an automatic correction. Because delay codes feed compliance reporting, the agent’s role is to support that judgment call, not to make it.

Design decisions and considerations

The decision to commit to building on Amazon Bedrock AgentCore followed a period of research: AvioBook evaluated its options for agent orchestration, session management, and tool access before committing to a direction. That research pointed to AgentCore runtime, AgentCore memory, and AgentCore Gateway as managed building blocks the team didn’t need to build itself. A focused week of co-development with AWS then let the team stand up a multi-agent proof of concept and confirm the approach: the architecture, the data access pattern, and the agent design. Proving out the concept this quickly is what gives AvioBook the confidence to move forward with productizing Connected Analytics for its airline customers, on a foundation it can extend with new agents and data sources without re-architecting.

A few design choices were worth calling out. Building distinct agents per persona kept each agent’s scope narrow and its tools relevant, which made behavior easier to reason about than a single catch-all assistant. Exposing data access as MCP tools through the AgentCore Gateway decoupled the agents from the data layer, so new tools and data sources can be added later without re-architecting the agents. Keeping the data in Amazon S3 with Athena and the Glue Data Catalog meant the proof of concept could build on the same AWS data services AvioBook already uses, rather than standing up a separate analytics stack.

Because the agents’ recommendations would inform operational decisions, responsible AI practices were built into the design from the start, as controls to carry into production. Every answer was grounded in the operational data the agents retrieved, with the evidence surfaced alongside the response, so users could trace a conclusion back to the underlying events rather than take it on trust. Agent outputs were treated as a starting point for the airline manager or OCC dispatcher, not an automated action: a person reviews the recommendation and stays responsible for the operational decision. Connected Analytics also sits outside the aircraft’s certified, airworthiness-bound systems: it is advisory software, designed to inform the person making the call, not to act on its own.

Results and business impact

AvioBook Connect’s operational results set the baseline Connected Analytics is designed to build on. Over a single summer season, a European mid-size carrier avoided more than 4,000 hours of delay, with 124 of those hours coming directly from reducing the phone calls and manual back-and-forth Connect replaces.

Connected Analytics is designed to extend that upside further. Providing dispatchers with a tool that supports the thinking process, not only faster answers, is what drives the additional savings: a rerouting decision around an air traffic capacity constraint takes situational awareness and a few uninterrupted minutes, both in short supply when someone is on the phone chasing status updates instead.

On a conservative, illustrative baseline, 200 flights a day and time lost at the gate priced at around $20 a minute, a two-minute cut in average turnaround is worth roughly $240,000 a month, consistent with the preceding estimate. As process compliance becomes more consistent, a further 2 to 4 minutes is recoverable, worth up to roughly $495,000 a month for that same carrier, on top of better handling of irregular operations.

What comes next

AvioBook Connected Analytics is designed to deliver two capabilities: answering natural language questions against Connect’s operational data, and validating delay codes against the underlying events. The same foundation opens a natural path forward.

One area AvioBook is investigating is proactive anomaly alerting. Rather than a user asking for insights, they would define the conditions they care about, such as a process running too long, a delay pattern forming at a station, or a flight profile that warrants attention, and an agent would watch incoming data and surface matches as they happen. This expands AvioBook Connected Analytics’ role from answering questions to raising the right ones before anyone thinks to ask. Since data is already accessible through modular tools in AgentCore Gateway, alerting can reuse the same data layer the query agents rely on, rather than requiring a separate pipeline.

The modular design also leaves room to add agents for new personas and connect new data sources as airlines push more of their turnaround activity into Connect, building on what runs today.

Conclusion

Turnaround has always decided an airline’s schedule integrity, and until now it was one of the most opaque, hidden parts of airline operations. AvioBook Connect brought the event data and the conversation around it into one place. Connected Analytics, prototyped on Amazon Bedrock AgentCore, is designed to turn that same data into something airline managers and dispatchers can question directly: what delayed a flight, whether a process actually held up, and what a disruption at one airport means for the rest of the network.

None of this replaces the judgment of the people running the turnaround. AvioBook built it to give them a faster, more reliable starting point, and a growing body of evidence for what that judgment is worth, on a foundation AvioBook is already extending toward catching the issues worth acting on before anyone has to ask.

If your airline wants to see what a single source of truth for turnaround data looks like, explore AvioBook Connect or get in touch with the AvioBook team to talk about Connected Analytics.

Amazon Bedrock AgentCore is available in multiple AWS Regions. For the current list, see Amazon Bedrock AgentCore supported Regions.

To learn more about building and deploying production-ready agents, visit the Amazon Bedrock AgentCore documentation and the Amazon Bedrock AgentCore service page.

For code examples and integration guides, check out the AgentCore samples GitHub repo.

About the authors