HOW to Make Conversational Form with LangChain | LangChain TUTORIAL
Based on Sam Witteveen's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Define a Pydantic schema for the exact fields the bot needs (first name, last name, full name, city, email, language) so free-form text can be extracted into a reliable structure.
Briefing
Conversational forms don’t have to feel like web-page data entry. By extracting structured fields from free-form chat and then asking only what’s still missing—one question at a time—a bot can build a user profile (name, city, email, language) without forcing rigid, form-like responses.
The approach uses LangChain plus OpenAI function-style extraction, but avoids calling extraction repeatedly on every turn. Instead, it sets up two chains: one chain performs information extraction into a predefined schema, and a second chain handles the conversational “ask” loop. The schema is defined with a Pydantic class that lists the target fields—first name, last name, full name, city, email, and language—and includes descriptions that guide the model toward the correct interpretation. In testing, a message like “Hi my name is David Jones and I live in Melbourne Australia” yields first name “David,” last name “Jones,” full name “David Jones,” city “Melbourne,” and language “English,” while leaving email blank when none appears. Another example that includes “You can email me at …” correctly populates the email field.
The method also handles messy real-world inputs. If a user mentions multiple email-like strings, the schema’s field descriptions help the model choose the email associated with the user (e.g., “my email is …” rather than a sibling’s). The result is a structured “user details” object that can be inspected programmatically.
From there, the bot maintains an instance of the Pydantic model as the user’s profile, initially empty. A helper function checks which fields are still missing by returning an “ask for” list—effectively the next set of questions the bot should request. Another helper function takes the latest user message, runs it through the extraction chain, and merges non-empty extracted values into the existing user record.
The conversational behavior is controlled by a dedicated “info gathering” prompt. It instructs the model to ask only one question at a time, never dump a list of fields in a single message, and avoid repetitive greetings that can happen when there’s no memory. If the “ask for” list is empty, the prompt tells the bot to thank the user and move on.
In a live loop, the bot starts with missing fields and asks for the next required item based on what’s still empty. If the user provides multiple fields in one message (like last name and full name together), the extraction chain fills them, and the bot immediately pivots to the remaining gaps—city, then email—regardless of the order the user supplies information. Once all required fields are populated, the loop ends and the conversation transitions to the next phase.
The payoff is practical: the bot collects profile data conversationally, stores it for later use (such as looking up weather by city or sending emails), and reduces token waste by limiting extraction work to the targeted information-gathering stage rather than calling heavy function logic continuously throughout the entire chat.
Cornell Notes
A conversational form can be built by combining structured extraction with a missing-field question loop. A Pydantic schema defines the fields to collect (first name, last name, full name, city, email, language), and an extraction chain parses free-form user messages into that structure. The system keeps an initially empty user record, checks which fields remain empty, and asks only one question at a time for the next missing item. Each user reply is re-extracted and merged into the profile until nothing is missing, at which point the bot thanks the user and moves on. This matters because it avoids rigid, web-form behavior while still producing reliable, database-ready user data.
How does the system turn natural chat into a structured “user profile” without forcing rigid form answers?
Why does the design use two chains (extraction vs. asking), and what problem does it prevent?
What ensures the bot asks conversationally rather than dumping a list of fields?
How does the bot decide what to ask next after each user reply?
How does the approach handle ambiguous inputs like multiple email addresses?
What triggers the transition out of the conversational form loop?
Review Questions
- What specific role does the Pydantic schema play in making conversational input usable as structured data?
- How does the “ask for” list mechanism guarantee one-question-at-a-time behavior and dynamic follow-ups?
- Why does separating extraction and asking into two chains help with cost (token usage) and conversation flow?
Key Points
- 1
Define a Pydantic schema for the exact fields the bot needs (first name, last name, full name, city, email, language) so free-form text can be extracted into a reliable structure.
- 2
Use an extraction chain to parse each user message into the schema, then merge non-empty results into an existing user record.
- 3
Maintain an initially empty user profile and compute an “ask for” list of fields still missing after each turn.
- 4
Generate the next bot question from the missing-field list, with a prompt that enforces one question at a time and avoids repetitive greetings.
- 5
Design the loop so it ends automatically when no fields remain empty, then transition to the next conversation stage.
- 6
Reduce token waste by limiting extraction work to the information-gathering phase rather than calling function-style extraction continuously throughout the entire chat.