The Gate C42 Problem
Picture this:
You’ve sprinted through security, coffee in hand, and you finally make it to Gate C42. Right as you arrive, the departure board flips from red to redder:
UA 214 — DELAYED — 4 HOURS
You walk up to the gate agent and ask the obvious question: Are we actually leaving tonight, and why are we delayed?
She glances at her screen, frowns, and says:
“All I see is Delayed. The system doesn’t show a reason.”
Now you’re stuck refreshing three different apps, wondering if you’ll get a hotel voucher, a rebooking, or just a $12 sandwich coupon.
Why couldn’t she answer you? Because the answer lives in two places that never talk to each other.
The Core Challenge Every App Faces: Facts vs. Context
Almost every frustrating customer experience comes down to this split:
1. The What = Structured Data in SQL. Hard facts, statuses, numbers. Rows and columns. Flight UA214, Status = DELAYED, Delay = 240 mins, Gate = C42.
2. The Why = Unstructured Context in Documents. Rules, reasons, policies, workarounds. Buried in PDFs, memos, and webpages. The FAA ground-stop advisory, the crew-timeout memo, and the 60-page Customer Care policy that says when you’re owed a hotel.
One system gives you precision with no explanation. The other gives you explanation with no precision.
SQL tells you what happened. Documents tell you why it happened and what to do next.
Until generative AI, we couldn’t bridge them at runtime. Now we can — with a digital librarian agent.
The Solution: A Digital Librarian Agent
Think of it not as a chatbot, but as a librarian who knows exactly which shelf to check.
It doesn’t guess. It reasons: do I need an exact lookup, or do I need meaning-based search? Most real questions need both — and then need them stitched together.
Take our airport question rewritten for AI:
Is UA 214 actually delayed and am I eligible for compensation?
A great agent instantly splits it:
- What part: Is UA 214 delayed? → This must come from the operations database. No hallucinating flight times.
- Why part: Why is it delayed and am I eligible? → This must come from advisories and policy docs. No making up compensation rules.
The 6 Steps Behind the Scenes
Every what + why question follows the same agentic workflow.
1. Read the Question
Parse intent in natural language. The user isn’t asking for keywords, they’re asking for a decision: should I book a hotel myself or wait?
2. Split What vs. Why
Route the task:
- What → SQL database
- Why → Vector database
The agent decides: flight status needs SQL, delay reason + compensation policy needs semantic search.
3. Build the Queries
Generate machine-ready queries for each system.
For SQL (Text-to-SQL):
SELECT status, delay_minutes, aircraft_id
FROM live_flights
WHERE flight_number = 'UA 214' AND flight_date = CURRENT_DATE;For Vector (Semantic Search):
"crew timeout delay compensation eligibility + FAA ground stop policy UA214"4. Execute the Queries
Run them with tools, not vibes. Hit the Postgres / BigQuery table. Hit the vector index containing ops memos and the Contract of Carriage PDF.
- Result A (SQL): DELAYED, 240 mins
- Result B (Vector): Chunk from Ops Memo #88: crew timeout due to inbound weather + Chunk from Policy p.22: delays >3hrs crew-related = hotel + meal
5. Compile
Merge both results into one grounded context packet. This is usually plain code — formatting, de-duplicating, and attaching citations.
6. Answer
Finally, let the LLM write the human answer from only that packet:
“Yes, UA 214 is delayed 4 hours due to a crew timeout linked to weather in Chicago. Because it’s crew-related and over 3 hours, you’re eligible for a hotel and meal voucher under Section 4.2. Here are the 2 rebooking options…”
No shrug. No “system just says no.” A complete answer.
Under the Hood: When to Use an LLM vs. a Tool
This pattern is what makes it agentic:
- Use an LLM for thinking: Steps 1, 2, 3, and 6 — understanding, decomposing, generating queries, and writing the final response. This needs reasoning and language.
- Use tools for doing: Steps 4 and 5 — actually running the SQL, performing vector retrieval, and joining the results. This needs to be deterministic and citable.
Rule of thumb: LLM thinks, tool acts, LLM explains.
From Data Retrieval to Decision Delivery
This isn’t just an airline problem. Once you see the pattern, you see it everywhere:
- E-commerce: What is my order status? (SQL) Why can’t I return it? (80-page return policy PDF)
- Banking: What is my loan decision? (Risk table) Why was I denied and what alternative do I qualify for? (Lending guidelines)
- Healthcare IT: What is this error code? (Logs) Why does this fix resolve it? (Runbooks in Confluence)
Anyone still building AI that only queries one side is building half an experience.
Don’t just retrieve data. Deliver reasoning. Turn your siloed SQL tables and scattered PDFs into a single reasoning engine that works at the speed of your customers.