agents / 05

More progress.

My last feature was a trip dashboard, with a worker that tracks prices over time. Instead of searching once, it watches routes and tells me when something better appears, or when a flight I’ve already picked changes meaningfully.

The interesting part was mixing conversation and interaction design. The experience starts in chat, then moves into a GUI where you can browse, compare and manage what the agent has gathered.

I got two main feedback points.

The first was local flights. A few people said existing tools fall apart on regional routes, and someone pointed me at an Amadeus CLI.

The second was simply: how can I use this?

Pilot and Captain

I’ve now split out my personal agent from the flight booking agent.

What used to be Captain is now Pilot. It keeps my memory, runs the daily loops and handles Concierge. Captain is a separate, public travel agent.

They both live in a monorepo now, with different apps, databases, Telegram bots, instructions and secrets. Pilot can create a Trip in Captain through a small signed bridge, but Captain has no access to Pilot’s private data.

Conversation quality

Captain works through Telegram. I can describe a trip in natural language, by text or voice, and it resolves the airports, dates and sensible defaults. It asks for whatever is missing, then presents the complete brief for confirmation.

If someone says “find me a flight from Lagos to JFK,” it should notice the dates are missing and ask only for that. If someone says “I want to fly the last week of August,” it should infer the year, pick a sensible range, figure out whether they care about cheapest or best, and confirm — instead of making them specify every parameter by hand.

This concierge layer needs more intelligence than I expected. I originally switched to an open-source model to reduce costs, then quickly realised I was paying for it in conversational quality.

Building this has become an iterative loop of forming theories, testing them, watching the agent say something obviously wrong, refining the prompts, and trying again. It’s surprisingly exhausting, but also fascinating. Every mistake teaches me something about how these systems work.

I also need a better testing setup. Right now I manually send messages and see what happens. Soon I’ll set up automated conversation tests that throw realistic requests at it and check that it responds sensibly. That feels essential if I want to improve behaviour without constantly introducing regressions.

Tracking

My original worker ran continuously until the free Supabase plan hit its limits. From 16 test trips over 24 hours, it created over 11k flight records.

Automation creates the temptation to keep everything, monitor everything and process everything. Designing agents that are intelligent while remaining computationally disciplined feels like an important constraint, not just a budgeting exercise. Cost is a proxy for efficiency.

So the first check now searches a broad set of combinations. Later checks focus on the strongest option and a couple of alternatives. Trips far in the future are checked less often, then more frequently as the departure gets closer.

Matching searches are also shared. If two Trips need the same flight data, Captain makes one provider request, stores the result once, then ranks it separately for each traveller’s budget and preferences.

Captain keeps a compact price history and sends an update when the first results arrive, a price drops meaningfully or a stronger itinerary appears. It doesn’t need to send a message every time it looks.

I’m still refining Captain until I trust it enough to recommend flights reliably. It should search across multiple providers, return strong recommendations quickly, and feel natural to use.

Next, I’m going to put it in the hands of a few people and see how well the recommendations hold up. After that comes booking.