← Notes

Asking again is a state defect, not a conversation defect

There is a documented mechanism for data already in the session to fill the form on its own; when re-asking happens, what failed was state propagation, not sentence understanding.

Re-asking — the system requesting what the visitor already provided — is usually diagnosed as a comprehension failure. Most of the time it is a state failure.

The Dialogflow CX parameter documentation describes the expected propagation: "When a page initially becomes active, and during its active period, any form parameter with the same name as a session parameter is automatically set to the session parameter value". That is: what is already known in the session fills the matching field without anyone asking anything.

The distinction matters because it points to different places to fix. If it were comprehension, the work would be in message recognition — examples, extraction, the model. Being state, the work is elsewhere: making sure a value captured at any point in the conversation is written to the session under the same name the form expects, and that the collection step consults what already exists before asking.

There is a naming detail that decides the outcome and goes unnoticed: the match is by name. A value stored as email does not fill a field called e_mail. A good share of the re-asking that looks like insufficient intelligence is, underneath, one name written two ways.

None of this is visible to the visitor. They see a system that is not paying attention — and that is the only reading available from the outside.