Get AI summaries of any video or article — Sign up free
HOW to Make Conversational Form with LangChain | LangChain TUTORIAL thumbnail

HOW to Make Conversational Form with LangChain | LangChain TUTORIAL

Sam Witteveen·
5 min read

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.

TL;DR

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?

It defines a Pydantic class with explicit fields (first name, last name, full name, city, email, language) and uses a tagging/extraction chain to parse free-form text into that schema. For example, “Hi my name is David Jones and I live in Melbourne Australia” fills first name “David,” last name “Jones,” full name “David Jones,” city “Melbourne,” and language “English,” while leaving email blank when none is mentioned. When the message includes “You can email me at …,” the email field is populated accordingly.

Why does the design use two chains (extraction vs. asking), and what problem does it prevent?

The extraction chain is responsible for parsing user input into the schema, while the “info gathering” chain generates the next conversational question. Separating these roles prevents constant extraction calls on every turn, which would waste tokens. The bot runs extraction during the information-gathering phase, then transitions to the next conversation stage once the profile is complete.

What ensures the bot asks conversationally rather than dumping a list of fields?

The “info gathering” prompt explicitly instructs the model to ask only one question at a time and not to request multiple fields in a single message. It also avoids repetitive greetings by removing instructions that would cause the bot to start over each turn (since there’s no memory in this setup). The bot’s next question is driven by the current “ask for” list of missing fields.

How does the bot decide what to ask next after each user reply?

A helper function checks the user record for empty fields and returns an “ask for” list. After each message, another helper function runs the extraction chain and merges non-empty values into the existing user details object. The next question is generated based on whichever fields remain empty—so the order the user provides information doesn’t matter.

How does the approach handle ambiguous inputs like multiple email addresses?

The schema’s field descriptions guide extraction toward the correct email associated with the user. If a message contains two email-like strings (e.g., the user’s email and a sibling’s), the model can select the one tied to “my email” because the email field is described as the user’s email address.

What triggers the transition out of the conversational form loop?

When the “ask for” list becomes empty—meaning the user record has no remaining missing fields—the prompt tells the bot to thank the user and ask how it can help next. At that point, the system moves to another set of chains or the next conversation phase and can store the completed profile for later tasks.

Review Questions

  1. What specific role does the Pydantic schema play in making conversational input usable as structured data?
  2. How does the “ask for” list mechanism guarantee one-question-at-a-time behavior and dynamic follow-ups?
  3. Why does separating extraction and asking into two chains help with cost (token usage) and conversation flow?

Key Points

  1. 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. 2

    Use an extraction chain to parse each user message into the schema, then merge non-empty results into an existing user record.

  3. 3

    Maintain an initially empty user profile and compute an “ask for” list of fields still missing after each turn.

  4. 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. 5

    Design the loop so it ends automatically when no fields remain empty, then transition to the next conversation stage.

  6. 6

    Reduce token waste by limiting extraction work to the information-gathering phase rather than calling function-style extraction continuously throughout the entire chat.

Highlights

A conversational form can be driven by a missing-field loop: extract what’s provided, ask only what’s still empty, and stop when the profile is complete.
Field descriptions in the Pydantic schema help the model choose the correct email when multiple email-like strings appear in one message.
The “ask” prompt prevents non-conversational behavior by forbidding multi-field questions and repetitive greetings when memory isn’t used.
The approach is order-agnostic: users can supply fields in any sequence, and the bot still asks for the remaining gaps.

Topics

Mentioned