AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
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: AvioBook Connect users (airline manager or OCC dispatcher) ask questions in natural language, entering through Amazon API Gateway WebSocket API. A Lambda Authorizer function in WebSocket API verifies the request’s JWT against Amazon Cognito, which issues a JWT per request. The authenticated request triggers an AWS Lambda target, which invokes the appropriate agent on AgentCore runtime. The agent updates session context in AgentCore memory. The agent calls tools through the AgentCore Gateway using MCP. The gateway invokes the corresponding tool function, implemented as an AWS Lambda function. The tool function issues relevant data queries to Amazon Athena. 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. 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. 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 [truncated for AI cost control]