The confirmation turn
Ending a conversation cleanly is as important as starting one. The confirmation turn tells the user exactly what was booked, logs enough detail to debug later, and leaves the state in a shape that a fresh request can build on.
How the confirmation turn closes the loop
The graph reaches an END node. State persists to thread memory. The next request starts fresh, with history as context.
Flashcards: Flashcards
Loading practice…
state["assistant_reply"] = (
f"Booked! Appointment #{appt['id']} with {appt['doctor_name']} on {chosen}. "
"You'll get a reminder by email."
)
_record_event(state, "confirm_booking", {"appointment_id": appt["id"]})
return state
# The next time the user says "I need to book another one", run_turn sees
# status != ready_to_confirm and enters intent_router normally. The old
# slot_options/doctor values are overwritten as the new turn fills them.No manual cleanup. The state stays in thread memory with its confirmed status. If the user starts a new booking, the router runs and the downstream nodes overwrite the relevant slots. If they ask "what did I just book?", the smalltalk node can read the history and answer.
First, you might want to answer follow-up questions like "remind me who I booked with" without needing a database query. Second, every slot is owned by exactly one node, so clearing them in confirm_booking would violate the single-writer rule. If you want to reset the conversation, you do it explicitly with a reset endpoint, not silently inside a node.
Quiz: Quiz
Loading practice…