Design a better AI agent by leaving the Bali decision to the traveller
Start here
In this lesson
- Space: what can someone discover on the first screen?
- Time: which earlier event changes the request?
- Core: where can a person intervene?
- Test the turn before Bali
Space: what can someone discover on the first screen?
A chat box gives the visitor a place to type, but no indication of the tasks it supports. Here a traveller can name a city, request a surprise or describe features such as mountains or beaches. The opening message makes those choices discoverable. Claiming the assistant can book a trip would require more evidence. Match the welcome message to actual capabilities.
Test the first screen with a newcomer
Show someone only the welcome message. Ask what they would type to pick Bali, request a surprise or reject a suggestion. The test measures whether a person can take the path they want unaided, rather than how many options the assistant recites.
Settings before creating the agent 03:25 · Microsoft Learn
Three steps at the screen
- Find the configuration in the notebook.
- Trace the welcome back to the instructions.
- Check whether a named destination warrants a follow-up question.
Time: which earlier event changes the request?
“Somewhere else” makes sense after a destination has been suggested. Showing earlier interactions lets someone inspect the history the agent may be drawing on. Compare the request in an empty chat with the same words after a suggestion. The Bali example does not establish that long-term storage was configured. That would require a test across sessions.
Core: where can a person intervene?
The presenter points to pause and speed controls on a video player. When a model makes plans under uncertainty, the user likewise needs a way to intervene or give feedback. This is a design principle. The change implemented in the notebook is narrower: clearer instructions and an opening message. The recording does not implement an entire control panel.
The agent instructions define the welcome and options. 03:42 · Microsoft Learn
The welcome and follow-up question 04:33 · Microsoft Learn
Keep a surprise request and a named destination as separate test inputs. The same attractive Bali itinerary does not automatically pass both.
Test the turn before Bali
Start with an open request for a day trip. Look for the intermediate result: the assistant asks whether the user has a destination in mind. Once the traveller supplies Bali, the itinerary reflects that choice. Starting directly with “plan a day in Bali” tests planning, but skips the question of whether a newcomer can discover how to choose.
The assistant asks for a destination preference. 04:58 · Microsoft Learn
Validate the choice before judging the itinerary
After Bali is chosen the reply suggests Mount Batur followed by breakfast. The destination influenced the plan. This does not establish that walking times or opening hours were checked. Score respect for the choice separately from the freshness of activity details.
Morning activities in the Bali response 05:08 · Microsoft Learn
Worked example · Read the run at three stops
Pause | Where to look | How to interpret it |
|---|---|---|
First screen | What can a newcomer not tell from a blank box? That naming a city and requesting a surprise are both possible. Turn those capabilities into concrete example requests. | |
Visible history | Compare identical words from a newcomer and someone who just rejected a city. Reading the history should explain which earlier message matters. | |
Who chose Bali? | Locate the user turn before the itinerary. The traveller supplied the city. Inspecting only the final plan would hide this design change. |
Try it yourself · Try two opening messages
Imagine entering “plan a day in Bali”, then starting over with “plan a trip for me”. For each, record which decision the user has already made and which is open. Suppose the system silently chooses Bali for the second request. What extra turn must the traveller now spend correcting that choice?
Check your reasoning
A useful welcome shows both how to pick a place and how to request a surprise. Asking for the city again is unnecessary in the first run. Offering a choice in the second may avoid a correction later.
Troubleshooting
Observation | Check | Expected result |
|---|---|---|
Asks again for a city already supplied | Inspect the preceding user turn. | Count avoidable clarification turns. |
User cannot discover the choice | Show the welcome without the tool list. | Can a newcomer explain how to choose their city? |
Two review questions
- Which two choices could a first-time visitor see?
- Did the plugin choose Bali?
Check your reasoning
- They can supply a city or request a random suggestion. Both appear in the demo’s capabilities.
- In this exchange the traveller supplied it. The source of the city is visible in the conversation.
Short glossary
Space: the interaction environment. Time: use of history. Core: control and feedback under uncertainty.
Sources and version note
The written unit connects principles to interface decisions. Here the observable test is whether the visitor can distinguish a random suggestion from choosing a city. Microsoft