Operational Knowledge Assistant
Jetstar Airways · 2024 – Present
Amazon Bedrock-powered agentic system that automates staff traveller seat allocation, reducing per-flight processing from manual manifest review to a 1.6-second runtime.
The problem
The Airport Experience team was responsible for checking in and assigning seats to staff travellers across every flight. Jetstar's expectation was roughly 30 seconds per staff traveller — a target that was increasingly difficult to meet due to the manual nature of the process. Staff had to retrieve a flight manifest and manually work through seat allocation against complex, document-heavy policy and procedures. With an average of 4–5 staff travellers per flight, this created a consistent operational bottleneck at check-in.
Architecture
Approach
Conducted a comprehensive RFI across multiple LLM providers before selecting Amazon Bedrock, which was already an established Qantas Group partner — reducing procurement friction and satisfying data governance requirements. Designed a RAG architecture against a Bedrock Knowledge Base connected via Bedrock Data Automation to S3 buckets containing the full policy document set. A qualifier guardrail was implemented upfront to filter out-of-scope queries, ambiguous inputs, and hallucinated responses — enforcing a genuine answer or a clean 'no' when the correct information could not be retrieved. The core system uses a hybrid deterministic-agentic approach: a curated decision flowchart handles straightforward cases deterministically, failing over to a Claude Sonnet-powered multi-agent orchestration layer for any flight with more than 3 staff travellers or multiple staff on the same booking. The agent layer was built and deployed using Strands Agents in a supervisor pattern, consisting of five specialised agents — Disruption Handler, Priority Manager, Seating Optimisation, Business Rules, and Explanation — coordinated by an Orchestrator agent. The Business Rules agent queries the Bedrock Knowledge Base directly for policy retrieval. External system integration is handled via MCP and an AgentCore Gateway connected to Navitaire NewSkies. The Explanation agent generates a human-readable summary of the decision flow for Airport Experience staff.
Key decisions and trade-offs
Amazon Bedrock over alternative providers
A formal RFI process evaluated multiple LLM providers. Bedrock was selected primarily because AWS was already an established Qantas Group partner, which satisfied data governance requirements and removed the need for a lengthy new vendor procurement process. This was a deliberate risk reduction decision, not purely a technical one.
Hybrid deterministic-agentic architecture
A purely agentic approach would have been slower, more expensive, and harder to validate for the majority of straightforward cases. A deterministic flowchart handles simple allocations instantly, with the multi-agent layer invoked only when complexity thresholds are met — more than 3 staff travellers or multiple staff on the same booking. This kept the PoC cost-effective and reliable while still demonstrating genuine agentic capability.
Scoping down to a barebones PoC
The initial proposal involved a more expansive pilot that would have been expensive and slow to deliver. Given that leadership had never deployed anything agentic in the organisation, the priority was a fast, reliable, accurate, and cost-effective proof of concept. Cutting scope to the highest-ROI use case allowed the PoC to be delivered in partnership with AWS via a shadow build, reducing delivery risk significantly.
Challenges
Data Governance Council engagement
Applying learnings from earlier projects, the Data Governance Council was engaged from the earliest possible stage. Getting access to Kiro and non-sanctioned LLM models within the organisation required navigating this process carefully — early engagement prevented the blockers that had slowed prior initiatives.
Deploying agentic AI for the first time in the organisation
Leadership had no prior exposure to agentic systems, which created understandable hesitancy. The PoC had to simultaneously demonstrate reliability, accuracy, and cost-effectiveness while also building internal confidence in the approach. The shadow build model with AWS allowed the team to develop in-house capability while maintaining delivery momentum.
Policy complexity and test case design
The staff traveller on-boarding policy is genuinely complex — enough that thorough test case design was non-negotiable. Significant effort went into designing test cases that covered edge cases across the policy space, which was critical for validating both the deterministic and agentic paths.
Outcome
Reduced seat allocation runtime from a manual manifest review process targeting 30 seconds per staff traveller to approximately 1.6 seconds for an entire flight — covering an average of 4–5 staff travellers. Near-100% accuracy in seat allocation decisions. Currently in final pre-production validation.
My role
Scoped the PoC from a broader pilot proposal to a focused, high-ROI delivery. Managed the AWS relationship throughout the shadow build. Designed the test case suite and authored Secure By Design documents and NFRs for the PoC. Mentored a Senior Robotics Engineer through the build process. Supported Data Governance Council engagement from project initiation.
What I would do differently
This was the most carefully curated delivery of the three Jetstar AI projects, benefiting directly from the fail-fast learnings of earlier PoCs. If I were to repeat it, I would ensure the Data Governance and procurement pathway was documented from day one — much of the early phase involved waiting on responses from multiple stakeholders to understand the process. That documentation now exists and will accelerate future agentic initiatives in the organisation.