Lesson 21.721.7 Where the conversation lives

In everyday life. A patient's file can live in different places. The patient can carry their own folder to every visit. A cabinet at the clinic can hold it. The hospital's central records can hold it. Or nobody keeps it, and the patient explains everything again each time. If the patient loses the folder they carry, only the copies kept elsewhere are left. In this concept, these are the places a conversation can live, and losing the folder is your program restarting.

What you will learn. The places a conversation can live, from your own program to the provider's side, and what is left of it after your program restarts.

Why it matters. A conversation holds business data, so every copy of it is a copy someone must protect and delete.

One request, start to finish. Ana asks two questions in a row: "Which invoices are due this week?" then "Which of those has no purchase order?" The second needs the first's history. The first SDK, by default, wrote a session file: a file on disk, under the home folder, holding the whole conversation, including every invoice and amount from the tool. The second question was answered by reading that file back. With the lab's option, the first SDK wrote no session file. The second SDK kept nothing either: the lab's code held the history and passed it to the next run.

Where can a conversation live?

State is the conversation a run continues from. An SDK keeps it in one of five places, from yours to theirs:

Mixing two of these can send the same history twice, so keep to one.

Figure 21.9. Where a conversation can live, and the session file a harness writes unless you turn it off.

What is left after a restart, or the next day?

Follow one conversation through four moments: the first question, a follow-up, your program restarting, and the next day. With session files on, the file keeps it, and someone must protect that file. With session files off, it is gone after each run. With the history in your program, it lasts only as long as your code keeps or saves it.

Figure 21.10. One conversation through four moments, kept three ways.

An approval waiting for a decision (21.5) works like the third lane of Figure 21.10, history in your program: its run state is text your code saves, so it lives wherever you put it.

Can a session be picked up again?

With sessions, you can resume one by its id, continue the latest, or fork a copy. Each reads a file someone must protect and delete.

Can Python turn session files off too?

One language difference matters here. On the first SDK, the option that turns session files off exists in TypeScript only. In Python the lab passes the harness its own flag instead, extra_args={"no-session-persistence": None}, which you see in Task 11. Check that no file appears, in whichever language you use.

What else does a harness do with a conversation?

Compaction: when the conversation grows near the model's limit, the harness summarizes the older part and carries on. A subagent is a second agent started for part of a job, and only its final message comes back. This worker uses neither. Chapters 26 and 27 do.

At work. Lab 21, Task 11: find every copy of a conversation on both SDKs.

The operating rule: choose one place for each conversation before the first run, and keep it on your side unless you have a reason. Turn session files off unless you need to resume, and treat every file you keep as business data.