FareSentry

• 

  faresentry architecture

Inspiration

Checking airfare is repetitive and surprisingly difficult to automate well. A cheaper flight is not always a better flight: it may add extra stops, introduce a long layover, require an airport transfer, or save too little money to be worth the inconvenience.

I wanted to build something that could monitor airfare continuously, understand a traveler's preferences, and stay silent unless there was actually something worth acting on.

That became FareSentry: an autonomous airfare-monitoring agent that watches the market, filters out unacceptable itineraries, reasons about the remaining tradeoffs, and only alerts the traveler when a meaningful opportunity appears.

What it does

A traveler defines:

• origin and destination
• departure and return dates
• hard constraints such as maximum stops, trip duration, and connection time
• soft preferences such as shorter travel time or willingness to pay more for convenience
• an alert threshold
• a monitoring interval

FareSentry then runs monitoring cycles against current flight data.

The key design principle is:

AI chooses among acceptable options. Python decides whether the user should be interrupted.

Deterministic Python handles objective rules such as normalization, stop counts, durations, hard constraints, price calculations, historical comparisons, and alert thresholds.

Strands Agents with Amazon Bedrock handles the subjective part: choosing among currently eligible itineraries based on the traveler's preferences and explaining the tradeoff.

If the resulting opportunity crosses the user's configured threshold, FareSentry can send a notification through Amazon SES. Otherwise, it stays silent.

How I built it

FareSentry is written primarily in Python and separates external integrations from the core decision logic.

For live flight data, I integrated SerpApi's Google Flights API. Round-trip searches require multiple stages: FareSentry first retrieves outbound itineraries, preserves the provider's departure token, then retrieves compatible return options and normalizes them into complete round trips.

The monitoring pipeline then:

1. Retrieves the current flight market.
2. Normalizes provider responses into internal itinerary models.
3. Applies deterministic hard constraints.
4. Deduplicates and persists observations.
5. Sends only currently eligible candidates and computed facts to a Strands agent running on Amazon Bedrock.
6. Validates the model's structured recommendation.
7. Loads prior completed-run history from SQLite.
8. Deterministically evaluates the user's alert policy.
9. Stays silent or sends a notification through Amazon SES.

SQLite stores monitoring runs, fare observations, historical comparisons, and notification state.

I also built two Streamlit experiences:

• Local Live Mode, which uses real SerpApi and Amazon Bedrock integrations.
• A hosted deterministic demo, which uses reproducible synthetic fare changes so judges can reliably see both the silent and alerting paths.

The project currently has 636 automated tests, along with Ruff linting and formatting checks.

Challenges

One of the biggest challenges was deciding what the AI agent should and should not control.

It would have been easy to let the model decide everything, but airfare contains many objective constraints that should not depend on probabilistic reasoning. Prices, stop counts, connection lengths, and alert thresholds are better handled deterministically. I therefore designed the agent around a narrow responsibility: subjective preference tradeoffs among options that Python has already verified as acceptable.

Another challenge was handling history versus current availability. An itinerary observed yesterday should help FareSentry understand whether today's price is attractive, but historical data must never imply that an old itinerary is still bookable. This led to an important invariant:

Historical observations can influence valuation, but only itineraries returned in the current search can be acted on.

I also had to handle failed or incomplete monitoring runs carefully. For example, a provider search may succeed and persist observations even if a later model call fails. FareSentry therefore only uses observations from successfully completed runs when establishing alert history.

During live testing, I also encountered structured-output truncation from the Bedrock model on a complex international itinerary. Increasing the model's output budget and validating structured responses made the live pipeline reliable without weakening the deterministic safeguards.

Finally, I wanted the public demo to be reproducible. Real airfare can change between two runs, so relying on a live price drop would make the judging experience unpredictable. The hosted demo therefore uses fixed scenarios while the local Live Mode demonstrates the real external integrations.

What I learned

The biggest lesson was that an effective agent does not need to give an LLM control over every step.

FareSentry works better because responsibilities are divided according to their strengths:

• deterministic software handles facts, constraints, calculations, persistence, and alert policy
• the agent handles judgment and tradeoffs that are difficult to encode as fixed rules

I also learned how much engineering is required around an AI model to make an agent dependable: provider abstractions, structured outputs, validation, persistence, failure handling, historical semantics, deduplication, and reproducible testing are just as important as the model call itself.

What's next

The current prototype focuses on fixed-date round trips. Future versions could add flexible-date monitoring, route-discovery mode, smarter route-specific constraint suggestions, additional notification channels, richer historical pricing context, and durable hosted scheduling.

The long-term goal is simple: let travelers define what matters once, then let FareSentry watch the market for them.

Built With

• agents
• ai
• airfare
• alerts
• amazon-web-services
• automation
• autonomous
• bedrock
• deals
• flights
• monitoring
• notifications
• personalization
• python
• recommendations
• search
• serpapi
• ses
• sqlite
• strands
• streamlit
• tracking
• travel
• traveltech