Case Study
Exo Handling a fast-built AI workflow for business aviation ground handling
An experiment in building a complete operational application fast: multi-channel customer agents, a RAG-backed Ops Copilot, and a supervising-agent pattern for improving customer automation with human control.
~24h
of build time spread across a single intense week
3
customer channels: WhatsApp, voice, and email
2
AI layers: customer agents plus a supervising Ops Copilot
Overview
A complete application built as an AI-native workflow exercise
Exo Handling is an AI-powered operations workflow for non-scheduled aviation ground handling and flight-management teams. It was built as an experiment/exercise in how far a complete application could be pushed when OpenAI GPT-5.4 is used as the primary build partner instead of only as a chatbot or code assistant.
The result was not a mockup or a deck. It was a working system with customer-facing agents over WhatsApp, voice, and email, a shared case-management workspace, vendor confirmation workflows, and an internal Ops Copilot that can read case state, answer grounded questions, follow up with customers, and propose improvements to customer agents.
The Build Constraint
The question was not “can AI help,” but “how much useful product can one person build fast?”
The project was deliberately scoped as a speed-and-systems experiment: build most of a complete operational product in about 24 hours of actual build time, while still keeping the workflow grounded enough to feel credible in a business aviation context.
- multi-channel customer intake instead of a single demo chat
- database-backed case records instead of loose conversation state
- vendor coordination instead of only customer messaging
- retrieval-backed ops support instead of fluent but unsupported answers
- human approval and supervision instead of unconstrained automation
That constraint made the architecture more interesting than the speed alone. When implementation becomes faster, system boundaries and supervision patterns matter even more.
What Was Built
Four layers working together as one operations workflow
The customer-facing layer handles routine intake and status flow. The case-management layer centralizes context. Vendor workflows manage confirmations and alternative handler logic. The internal copilot acts as a second operational layer for questions, follow-up, monitoring, and supervision.
RAG and Grounded Ops Support
The internal copilot was designed to answer from retrieved knowledge, not guess
Retrieval First
Manuals and operational documents are chunked and indexed so the system can pull relevant material before answering.
Citations
Ops Copilot can return answers with source references, which makes the output more defensible and auditable in an aviation-adjacent workflow.
Case-Aware
The copilot can combine retrieved knowledge with live case and workflow data to answer practical operational questions.
Human-Usable
The goal is not a clever-sounding agent. The goal is an internal assistant that helps a human operator make better, faster decisions.
The Strongest Pattern
Ops Copilot was not just a chat assistant. It was a supervising agent.
The most interesting architectural move in Exo Handling was the supervising-agent pattern. Customer agents handle front-line intake and constrained tasks, but the internal Ops Copilot does more than wait for prompts.
- monitor workflow events, watches, and notification signals
- step in where customer automation reaches a safe boundary
- propose improvements to customer agents for human approval
- keep important writes confirmation-gated
That layered control model feels closer to how AI becomes useful in real operational businesses: not one super-agent doing everything, but bounded agents with supervision, retrieval, tooling, and a human still in control.
Why this matters
Many AI demos stop at a customer bot. Exo Handling pushes a step further: an internal copilot that can observe, guide, and improve customer agents over time. That makes the system more operationally interesting than a simple conversational layer.
Demo
Watch the workflow in action
The demo shows customer requests arriving across channels, cases being created and updated, vendor confirmations and fallback logic, live voice updates, and the internal copilot handling case questions, watches, and improvement proposals.
Why It Matters
The point of the project was speed, but the takeaway is architecture
Complete workflows can be built much faster than before.
GPT-5.4 was not only useful for snippets. It helped shape the backend, frontend, prompts, workflows, and iteration loops across the full product.
RAG matters more when the workflow is operational.
In domains where procedures and manuals matter, fluent answers are not enough. Retrieval and citations make the internal copilot more trustworthy.
Supervising agents are more interesting than single-agent demos.
The strongest pattern here is a supervisory layer that can monitor and improve customer automation instead of only generating answers on request.
Human approval remains essential for consequential work.
The system becomes more useful when it is allowed to help with action, but still bounded by confirmation-gated writes and clear escalation points.
Credits
Built as a focused exercise in AI-native product delivery
Project
Exo Handling
Product, Design, Build
Happy Path Solutions
Primary AI Build Partner
OpenAI GPT-5.4
Key Architectural Themes
RAG, supervising agents, confirmation-gated writes