https://youtu.be/9XXe20M15PE

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learnedInspiration

Flight disruptions create a difficult problem for both passengers and travel platforms. When a flight is cancelled, the cheapest replacement is not always the best one. A passenger may need to arrive before an important meeting, avoid an overnight departure, choose a window seat, or prefer a reliable nonstop route. Most recovery systems treat each disruption as a new search and do not remember what the passenger previously accepted or rejected. We built RouteRecall to explore a simple idea: What if a flight recovery agent could remember what matters to each passenger and use that memory when choosing the next action?

RouteRecall is designed as an API or plug-in for airlines, travel applications, and business travel platforms. It receives a disrupted trip, passenger context, and replacement flight offers, then returns a personal recovery recommendation with a clear explanation. What It Does RouteRecall demonstrates a complete flight recovery workflow: Receive a flight cancellation. Load the passenger's saved preferences and trip requirements. retrieve relevant past experiences using vector search. Compare available replacement flights. Recommend the option that best fits the passenger. Save the workflow state and approval boundary. Record the selected action safely. Learn from the result for future disruptions. For example, with memory enabled, RouteRecall recommends BA286 because it arrives before the passenger's meeting, avoids an overnight departure, and offers a window seat. When memory is disabled, the same system recommends UA930 because it has the lowest fare difference. This comparison shows that memory is not simply stored—it directly changes the agent's decision. How We Built It The application has three main parts. Recovery Agent The backend is written in Python with FastAPI. Its recovery workflow separates planning from actions and records every completed step. The agent evaluates factors such as: Arrival deadline Fare difference Flight reliability Number of stops Overnight departure Seat availability Passenger preferences Previous recovery outcomes The current MVP uses simulated flight offers so the demonstration remains stable and repeatable. The architecture includes an adapter boundary where a travel platform, airline, GDS, or live flight-search provider could supply real offers. Persistent Memory with CockroachDB Cloud CockroachDB Cloud is the system of record for: Passenger profiles Long-term agent memories Trip requirements Flight offers Recovery cases Workflow checkpoints Seat inventory Idempotent action records The project stores 1,024-dimensional embeddings beside structured passenger and workflow data. The vector search uses cosine distance: [

d_{\text{cosine}}(x,y)

1- \frac{x\cdot y}{|x||y|} ]A distributed vector index with passenger_id as a prefix retrieves memories related to the current passenger and disruption: SELECT id, memory_type, content FROM agent_memories WHERE passenger_id = $1 AND embedding IS NOT NULL ORDER BY embedding <=> $2::VECTOR LIMIT 3; Keeping vectors and transactional records in the same database avoids synchronization problems between a separate vector store and the operational database. CockroachDB Cloud Managed MCP Server We connected Claude Code to the real CockroachDB Cloud cluster through the Managed MCP Server. Using read-only MCP tools, we verified: Recovery cases Selected flights Saved workflow checkpoints Action-ledger records Table schemas The distributed vector index This gives developers and judges an independent way to confirm that the demonstrated memory and workflow data exists in CockroachDB Cloud. Reliability Demonstrations Crash and Resume Flight recovery is a multi-step task. The passenger may take time to approve a new flight, and the agent process may stop while waiting. RouteRecall saves a checkpoint after every completed step. If the worker stops, a new worker can read the latest checkpoint and continue from the next unfinished step instead of starting again. Duplicate Action Protection Each important action has a stable idempotency key. A uniqueness constraint in CockroachDB ensures that retrying the same action does not create a second logical reservation. Concurrent Seat Protection Two agents may attempt to reserve the same final seat at the same time. RouteRecall uses CockroachDB transactions to allow one action to commit while the other detects the conflict and replans. This keeps the result at: Oversold seats: 0 Duplicate actions: 0 Challenges We Faced Making Memory Meaningful Our first challenge was avoiding a demo where memory was stored but did not affect anything. We added a memory ON/OFF comparison using the same flight offers. With memory enabled, the system selects the flight that fits the passenger's needs. Without memory, it selects the cheapest option. This makes the value of persistent memory visible. Combining Vector and Transactional Data Agent memory is often stored separately from business data. That creates extra infrastructure and consistency problems. We learned how to store embeddings, workflow state, seat inventory, and action records together in CockroachDB while using a passenger-prefixed vector index. Secure Cloud Connectivity Connecting the application securely required full TLS certificate verification. We configured the Python client to use a trusted CA bundle while retaining sslmode=verify-full. We also experienced difficulties with the local OAuth callback for the MCP client. After completing the authorization flow, we verified that the Managed MCP connection could inspect the cluster through read-only operations. Explaining a Technical Prototype Clearly The early interface mixed the passenger experience with database reliability experiments. This made the product difficult to understand. We reorganized the demo around one clear product story: A disrupted trip enters the system, passenger memory changes the recommendation, the workflow survives a failure, and the result can be verified in the database.

What We Learned We learned that production agent memory includes more than conversation history. A useful agent must remember: What the user cares about What task it is currently completing Which steps have already finished Which actions have already happened What it learned from the result We also learned that model intelligence and database correctness solve different problems. The agent can recommend an action, but the database must ensure that the action is durable, consistent, and not repeated. CockroachDB allowed us to combine semantic memory, workflow persistence, and transaction safety in one system. Future Development RouteRecall can grow in two directions. First, it can become an API or plug-in for: Airlines Online travel applications Corporate travel platforms Travel-management systems Passenger support tools A platform could send RouteRecall a cancellation event, passenger identifier, trip requirements, and available replacement flights. RouteRecall would return a recommended option and explanation. Second, RouteRecall could become a complete passenger recovery platform where users manage disrupted trips, compare options, approve replacements, and save travel preferences. Future technical work could include: Live airline and GDS integrations Real ticket exchange and booking APIs Passenger notifications Explicit human approval Hotel and train recovery Multi-language support Privacy controls and memory expiration More regions and larger memory datasets Monitoring, evaluation, and recommendation feedback Current MVP Scope The current MVP uses fictional passenger details, flight offers, prices, and seat availability. The following components run on a real CockroachDB Cloud cluster: Persistent passenger memory 1,024-dimensional embeddings Distributed vector search Workflow checkpoints Recovery cases Action records Transactional seat protection Managed MCP verification RouteRecall does not currently issue or exchange real airline tickets. It demonstrates the personalized decision and durable workflow layer that a travel platform could integrate with its existing booking system.