A collection conversation has one hard requirement — know when it is finished — and one hard failure — feeling like a form read aloud.
Both are solved in the same place: a slot state your code owns, sent into every turn, with completion defined as a condition over it.
The prompt Slot state lives in your code This is the architectural point and it is the one that decides whether the thing works at turn
20.
If the only record of what has been collected is the conversation transcript, then every turn the model must re-derive the state by re-reading the whole conversation.
That re-derivation is a task with an error rate, it is performed again on every turn, and its errors are sticky: a slot mistakenly re-derived as empty gets asked again, the person answers with irritation, and now the transcript contains an exchange that makes the next derivation harder.
Instead: your code keeps the slot dictionary.
Each turn you send it in , the model returns an updated one, and you merge with your own rules — never regressing a slot to , never overwriting a .
With this in place you can also truncate the history aggressively — the last six turns is usually plenty — because the state is not in it.
That keeps the prompt short and the cost flat as the conversation grows, instead of both climbing with every turn.
Filled, inferred, declined Status Description filled They stated it.
The source span is where.
Safe to use without confirmation. inferred You derived it. “We’re about thirty people” gives company_size = 10-49 — a correct inference and still an inference.
Requiring the source span makes it reviewable, and it is the status your code should confirm out loud rather than silently accept. declined Terminal, and terminal means terminal.
The most common way these conversations become unpleasant is a slot that is asked again in a new phrasing after a refusal.
One line in the prompt, one branch in the merge, and it never happens. empty Not yet established.
The only status the model may move away from freely.
Collapsing into is the tempting simplification and it costs you the ability to confirm selectively.
You cannot confirm everything — that is the interrogation failure — and you should not confirm nothing.
Confirming inferences only is the right amount, and it needs the distinction to exist.
Not an interrogation Four rules carry this, and the second is the one that matters most.
At most two slots per turn.
Three or more reads as a form.
Two that belong together — name and company, timeline and budget — reads as a conversation.
Their question outranks your slot.
The single difference between a conversation and an interrogation is whether questions can go the other way.
A model that acknowledges a question and continues collecting is worse than a form, because it is a form pretending.
Fill from passing mentions and confirm inline.
Asking for something the person has already told you is the failure they notice and remember.
The example phrasing in the prompt — state the inference, then move on — does this in one clause and gives them a chance to correct it without a question mark.
Never read the enumeration out. “Are you 1 to 9, 10 to 49, 50 to 249, or 250 plus?” is a database schema spoken aloud. “Roughly how many people are you?” gets the same information and lets the model do the bucketing.
Add a stall escape in your loop rather than the prompt: after three turns with no new slot reaching a terminal status, stop and hand over with what you have.
Without it, a conversation with someone who will not give an email continues indefinitely, and every turn costs money and goodwill.
The completion criterion “Complete when the conversation feels finished” is not a criterion, and a model asked to judge it will end early on a cooperative person and late on a chatty one.
The condition here is computable, and your code computes it — the model’s field is a hint you check rather than a decision you accept.
Two clauses, both load-bearing.
Every required slot must