The Opportunity Hiding in Everyday Problems

The problem was bigger than a search

I was planning a family vacation across several European cities, traveling with a toddler, less than a month before departure. It was the expensive end of the summer calendar, with a Labor Day weekend departure. I had delayed booking because the trip depended on a few external factors that were still unsettled. By the time I could plan in earnest, the prices were high and the practical choices had narrowed.

I wanted to use the long weekend rather than leave on a random weekday. That made the flight problem tighter. The right trip had to get a family of three to Europe at a reasonable points value without stretching the travel day into something the family could not realistically absorb.

One site could find flights. Another could search award availability. Hotel sites knew their own inventory. Maps could draw routes. Card portals could show a benefit. Each tool gave me an answer to a narrow question. None could answer the one I actually had: what is the best complete plan for my family?

That question was never just about price. It included luggage, meals, naps, connection risk, room occupancy eligibility, points that might not actually be available, and the difference between an elegant itinerary on a map and a day that would work in real life. Building a credible decision matrix by hand was becoming its own project.

The constraint hierarchy was the design

I hold several premium cards with transferable points, so I began with flights, then hotels, then the connections and activities that made the itinerary work. Each decision introduced a new program, transfer ratio, availability constraint, and occasionally a transfer bonus. The number of possible combinations grew quickly.

So I stopped treating the problem as travel search. I treated it as a decision-system problem.

In roughly ten hours on one concentrated day, I built and tested a small, human-supervised prototype with tools I already use: ChatGPT, Codex, Google Workspace, browser research, and a spreadsheet. Its role was deliberately narrow: keep the constraints together, compare complete outcomes, challenge my first assumptions, and tell me when the evidence was too incomplete to act.

Codex was the surprise. In this bounded, reviewed experiment, I did not encounter invented facts or false certainty in the work I accepted. This is not a general reliability claim. Its usefulness depended on clear constraints, source checks, and my review. Once the system knew that family feasibility and travel burden came before points value, it could make recommendations I could use.

What the system changed

The itinerary change was the clearest test. I had assumed that rail was the natural way to move between two European cities. It sounded sensible: scenic, direct in spirit, and exactly the kind of choice people describe as part of the trip.

The actual route was nearly eight hours and involved multiple connections.

For two adults traveling light, that might be a good day. For a family with a toddler, bags, meals, naps, and an arrival day that still had to work, it was a different proposition. The system compared the whole journey rather than treating the rail route as an isolated search result. It rejected the original assumption and recommended a short flight followed by a simple train connection.

That recommendation was not interesting because it found a flight. I could have found a flight. It was useful because it made the hidden decision criteria explicit and used them to challenge the framing I had brought to the problem.

This is a behavior I want from systems that assist with decisions. Confidence is cheap. A useful system should be able to say that the question was framed too narrowly, show the constraint that changes the outcome, and offer a more workable alternative.

Where it refused to proceed

The points analysis made the same point in a different way. One combination of awards had about $3,700 in potential savings against the best practical cash itinerary. On paper, that was the obvious winner.

The prototype did not stop at the arithmetic. It traced the option back to its dependencies and found an unresolved conflict around a required mileage balance. The award seats had been observed. The cash calculation was sound. But the needed miles were not verified as currently usable.

That meant the savings were real as a scenario, but not yet real as a recommendation.

The output kept the cash itinerary as the primary plan and labeled the award option as conditional. Before points could be transferred or tickets could be issued, the system required a direct account check and a fresh availability check. That is a small distinction in language, but it is the difference between a promising analysis and a plan someone can responsibly execute.

The hotel research exposed a related failure mode. Several award rooms appeared available when the search covered two adults. The availability disappeared when I added the child.

That was not a minor checkout detail. It was a hard constraint. A room that cannot be confirmed for the full family does not become an option because its points price is attractive. The prototype had to treat child-inclusive availability and occupancy eligibility as a feasibility rule, not a soft preference, and preserve the uncertainty until the exact room could be confirmed.

Human judgment needs a usable handoff

These examples gave me a better definition of the job. The system needed to evaluate complete family outcomes under real constraints, rather than optimize an isolated price, points value, or route. The handoff had to make the recommendation inspectable without asking me to repeat the research.

The prototype could research, compare, calculate, and recommend. It could not book travel or transfer points. I kept that boundary intentionally. Those actions are consequential and irreversible enough that they need clear authority and fresh verification.

But I also came away less interested in the simplistic version of human oversight: let the system do the work, then have a person approve the final click. That only works when the person can meaningfully inspect the recommendation. If approval requires reopening every website and recreating every calculation, the system has not reduced the decision burden. It has either created a rubber stamp or pushed the human into redoing the work.

The more useful handoff was a compact decision package:

What comes next

The experiment also made its own limitations obvious. Prices and inventory move. Some evidence sits behind logged-in sessions. Providers describe the same thing differently. A spreadsheet can record a conclusion, but it does not automatically know when an input has gone stale. Browser research can find a result, but it cannot always establish a durable source of truth.

The next version needs:

• Persistent state across research sessions.
• Provenance attached to individual claims.
• Fresh verification before any irreversible step.
• Reliable integrations where they exist, rather than treating every browser page as the same kind of source.
• Evaluators that test a recommendation against the original constraints.
• Permission boundaries that separate research, recommendation, and execution.
• Explicit escalation when the evidence is incomplete.

Those are not implementation details to add after the system becomes capable. They are how a capable system earns the right to be trusted.

I am building the next version as a personal experiment and plan to make it available for others to explore. I will share the architecture, the connected tools, the evaluation approach, and the reliability lessons as the work develops.

This began with a family trip. The broader question applies anywhere an important decision is scattered across specialized systems: Which decisions in an organization still depend on ten tools that each understand only one piece of the problem?

The working record

I have shared redacted public copies of the actual documents that drove this experiment: the prompt that established the constraints and the live report that captured options, evidence, decisions, and unresolved dependencies. They are included as a working record, not as travel advice or a booking plan. Account, booking, timing, property, and child-specific details are withheld.

• Read the full agent prompt (redacted)
• Read the live research report (redacted)