How an AI agent works: trace a travel suggestion back to its source
Start here
In this lesson
- Separate the task, the tool and the memory
- Find the destination list before reading the response
- Read the Sydney response as two outputs
- Use the second turn as a controlled comparison
Separate the task, the tool and the memory
In the toothbrushing example, the brush and toothpaste make the action possible. You know how far you have got in this particular routine. Your preference for a kind of toothpaste may still apply tomorrow. In the travel example the model interprets the task, a tool performs a particular operation and memory carries relevant information into a later step.
Where does the city come from? Separate two mechanisms
At 03:27 read the last two entries. Rio and Bali are possible return values. Membership does not establish a user preference. Below the list the function copies the choices and checks the last destination. That detail matters when designing the next test.
Rio and Bali in the destination list 03:27 · Microsoft Learn
Three steps at the screen
- Mark whether the traveller named a city.
- Identify which values the tool can return.
- Open the reply. Do its breakfast suggestions appear in the function result?
Find the destination list before reading the response
Locate the destination plugin in the Semantic Kernel notebook. Its list limits the cities the function can choose from. The function returns one at random. Write down what the traveller supplied and what remains open: one day is specified, the city is not. You can now explain what the tool contributes without seeing a single line of the itinerary.
The notebook defines the destination plugin. 03:10 · Microsoft Learn
Read the Sydney response as two outputs
Find the city name, then find where the recommendations for the day begin. The destination is the value supplied from the list. The itinerary is the model’s response built around it. Nothing in those recommendations establishes that a table was reserved or a ticket was bought. For that, you would need a booking operation and a successful result.
A request with no destination and the Sydney reply. 04:58 · Microsoft Learn
Two requests in one conversation 04:18 · Microsoft Learn
Record chat history separately from the plugin’s last-city state. One helps interpret a rejection; the other can keep the selector from immediately choosing the same city again.
Use the second turn as a controlled comparison
The traveller rejects the first city. The next plan in the recording is for Rio de Janeiro. The earlier message gives “somewhere else” its meaning. Imagine opening a fresh conversation with only those words. Without the first suggestion there is no city to rule out. The recorded turn demonstrates conversation context; it does not test a preference saved across sessions.
What changes with a different first request?
A day trip with no city and a day in Rio test different things. In the latter the traveller supplied the missing value. Predict whether each request needs a tool and inspect the actual call trace. Seeing Rio in the reply alone cannot establish that a tool ran.
Rio after the first city is rejected 05:22 · Microsoft Learn
Worked example · Read the run at three stops
Pause | Where to look | How to interpret it |
|---|---|---|
Task and plan | The request supplies the duration. Destination is open. Do not assign the traveller a preference they have not expressed. | |
Sydney suggestion | The list and function constrain the city choice; the itinerary is a separate model output. One run cannot reveal the distribution of random choices. | |
Rio alternative | Read this alongside the previous turn. Test retrieval of the preference in a new session before claiming durable personalisation. |
Try it yourself · Test memory with two conversations
Divide a sheet into request, information available and result. Enter the first request without a city and its Sydney result. In the next row write only “another trip”. Record which earlier fact must be available to explain an alternative. Now give a colleague that second row alone. If they cannot say which city to exclude, you have isolated the missing context.
Check your reasoning
Both recorded turns belong to one conversation. Success means tracing the link between the first city and the second request, even when another run returns a different pair of cities.
Troubleshooting
Observation | Check | Expected result |
|---|---|---|
Two successive cities differ | Inspect the last-city state as well as chat history. | Two outputs do not establish durable personal memory. |
City outside the list | Compare the return value and the city in the reply. | Did the discrepancy arise during selection or writing? |
Two review questions
- Does adding a city change the format of the itinerary?
- A second run did not pick Sydney. Is that a failure?
Check your reasoning
- It expands the possible function results. For a shorter plan around the same city, inspect the request or instructions given to the model.
- Random choice allows a different result. First check whether the returned city belongs to the list.
Short glossary
Tool: a callable operation. Plugin: exposes functions to an agent. Context: information available when interpreting this request.
Sources and version note
The written unit also discusses the environment and actions. This notebook’s destination task has a narrow scope; other services require their own integration. Microsoft