Top-Natural-Language-Query
Raw Data JSON view of Cards
ExpansionOfOffersOntheBestFlight
OtherFlightsInfoInSearch

About the project

Inspiration

FareWise came from a simple frustration: flight prices are easy to compare at a surface level, but the real final price is often hidden behind platform-specific offers, coupons, and booking flow details. A fare that looks cheaper on one OTA is not always the best option once discounts and offers are applied.

The idea was to build a system that does not stop at listing fares. Instead, it should interact with real booking platforms, retrieve live results and available offers, and help users identify the true cheapest option.

This made the problem a strong fit for Amazon Nova. We needed:

a model to understand natural-language flight queries
an agentic system that could operate real websites
a reasoning layer that could compare extracted results and rank the final outcome

What it does

FareWise is a Chrome extension plus FastAPI backend that helps users compare live flight results across OTA platforms and identify the best final price.

In the current implemented flow:

the user enters a natural-language flight query
the backend turns that query into structured route filters
OTA agents run in parallel on real travel sites
the system extracts flight data and offer details
results are normalized into a common schema
the backend ranks the best final option and streams it back to the UI

The current supported OTA agents are:

Cleartrip
Ixigo

The current configuration evaluates the top 3 results per platform, and that depth is configurable.

How we built it

The project is built as a two-layer system.

Frontend

The frontend is a Chrome extension with a side panel interface for travel search. It is designed to stay lightweight and focus on user interaction, progress visibility, and result presentation.

The frontend:

accepts natural-language flight search input
opens a WebSocket connection to the backend
shows progress while each OTA agent runs
renders results as each platform completes

Backend

The backend is a FastAPI service that acts as the orchestration layer.

It is responsible for:

parsing user queries
selecting and running OTA agents
coordinating parallel execution
normalizing extracted flight data
ranking final results
streaming updates back to the extension

Amazon Nova usage

We used multiple Amazon Nova capabilities, with each one assigned a specific role:

Amazon Nova Lite for planning: It converts natural-language user queries into structured search parameters such as route, date, class, and filters.
Amazon Nova Act for real OTA interaction: It navigates live Cleartrip and Ixigo pages, extracts flight results, and retrieves offer and coupon data from real booking flows. This is the key differentiator in the project, because it lets FareWise estimate the true final price instead of only comparing listed base fares.
Amazon Nova Pro for reasoning: It operates on normalized extracted results and helps produce a ranked recommendation rather than returning raw data alone.

Challenges we ran into

One of the hardest parts of the project was that travel sites are not simple structured data sources. They are dynamic interfaces with filters, lazy rendering, changing layouts, and booking flows that reveal important details only after interaction.

Some of the major challenges were:

making extraction reliable across real OTA pages
normalizing different platform schemas into one common model
retrieving offer data beyond the initial search results
making the frontend show progress clearly while backend work was still running
keeping the final result aligned with what was actually shown to the user

A concrete example was Cleartrip stop filtering. A query parameter looked like it should enforce non-stop results, but in practice it did not behave as expected. We had to inspect the live flow carefully, verify what the site was actually returning, and adjust the implementation so the final comparison remained accurate.

Another challenge was making sure the UI count matched the final normalized results rather than the raw extracted count, so the user saw what the system actually ranked.

What we learned

This project reinforced a few key lessons:

real-world travel comparison is not just a search problem, it is an interaction and reasoning problem
browser automation becomes much more valuable when paired with a normalization and ranking layer
separating planning, extraction, and reasoning into different Nova model roles creates a cleaner and more reliable architecture
progressive streaming makes the product feel much faster, even when backend work is substantial

What’s next

The next steps for FareWise are expanding platform coverage, improving offer retrieval depth, and continuing to strengthen the “true final price” experience.

The architecture is designed so that more OTA agents can be added over time, while keeping the same core pipeline: