Be the agent — a trip planning simulation

We always interact with LLMs as the user prompting it. What if it were the other way around? This game simulates an agentic app that plans a vacation. Try your hand at acting as the agent/model at key decision points.

Incoming request

"I want to go somewhere warm next weekend. Budget is ~$800 total."

There's the user's request. We'll show your completion output and then pause so you can make a decision about what the program should do next. Imagine the program is a box; you're sitting inside and get to decide which "button" to press. You can do each of the following things seen below. But before any button becomes pushable, certain data is required, which you can see below. For example, the "button" to check the weather requires a city to search for.

Check weather

cities — required

Search flights

destination — required
dates — optional, defaults to the dates in the request

Search hotels

destination — required
nights — required, depends on the flight's confirmed dates
max per night — optional, only used to narrow results after an over-budget result

Book and charge

flight — required
hotel — required
total — required

Send itinerary for approval

flight — required
hotel — required
total — required

First move

Look at the console: you/the model just produced that response to the user's initial input. You didn't get a specific destination — just "somewhere warm." Your completion text/reasoning produced some options: Cancun, Miami and San Diego.

Knowing which cities are generally warm is stable, general knowledge from training. Confirming the actual forecast for a specific weekend depends on the conditions at a particular time, which is why check_weather exists as a separate function — so it can go outside the program and talk to weather.com or a weather source to get the data.

Caught by the system

The function itself blocked this

Which one actually fits "warm"?

We received hard numbers from the external API call to weather.com! but what exactly was the user's intent when they said "warm"? Here's the power of a well-trained LLM, this one fine-tuned to vacations: it can make that judgement call more easily than other algorithms.

Mediocre result

Rain isn't really "warm and sunny"

This leads to a subpar output for the user.

Next move

Once again, you/the agent/the model doesn't have specific information about upcoming conditions in the future. In order to finish planning the vacation, you need to look at flights and hotels. Once again, you'll have to request information from outside the program — from an API, just like you did with weather. But which "button" is ready to be pressed?

Flight confirmed: $550 round trip

You got the $550 flight, now you reason that there's $250 dollars left. What do you need to do next?

Final move

Flight and hotel both fit under $800. Book and charge the credit card or send it off for a human's approval?

Money moved without asking

$790 was just charged

The function didn't require confirmation to charge the user's credit card, so nothing stopped this from you completing it. It might be exactly what the person wanted, but they find out after their card's already been charged! When designing agentic systems, we have to consider how much damage can be done when any of the buttons get pressed and functions execute. Some questions for consideration: How much damage could be done if the get_weather function got the wrong weather versus what's the size of the blast radius for charging someone's credit card?

Itinerary sent, nothing charged yet

You paused the loop to get the human to confirm the details before charging their card. The model/you/the agent didn't ask because it was unsure of the numbers, it asked because the action itself was the kind of action that probably should not be taken autonomously regardless of confidence.

Post mortem

Some things to notice

The plain-English reasoning logged before each function call wasn't just narration, it dictated the next action to choose, ie which button to press. Therefore, if you change how the model reasons, you change what it does.
Enumerating some cities that are typically warm or doing some basic math, came from general knowledge that was trained into the model: no external system was involved. On the other hand, confirming this weekend's actual forecast, the flights available, and the hotels were data obtained from outside the system.
Some functions couldn't run at certain times because a required parameter had no valid value. The functions/buttons themselves can enforce some of the expected sequencing to help contain the agent's actions.
Some mistakes get caught before they do anything, like the missing parameter. Meanwhile other mistakes succeed but still cause harm, like charging a person's credit card. The key is figuring out how to limit or contain what a single function can do.
Searching for a cheaper hotel worked out on the second try but wasn't guaranteed to work. How many times should the agent try the function before giving up or escalating back to the user? The agent's designer has to carefully consider these questions.

Roleplay: You're the Agent