Building a local multi-turn chat loop that keeps history in memory and answers follow-up questions correctly.
This example is about building an interactive conversation loop, not just making one isolated model call. The program keeps asking the user for input, appends that input to a history list, sends the full history to the chat model, appends the AI response, and repeats. That repeated loop is what makes the application feel like ChatGPT running locally in your terminal.
Core flow:
chat_history list.SystemMessage so the assistant has a stable role.exit, break the loop.HumanMessage.AIMessage.Why follow-up questions work: because every new model call receives the previous conversation turns again. If the user asks, Do the same for 81 after asking about the square root of 49, the model can infer that the new question refers to square roots only because the prior turns are still inside chat_history.
Practical limitation: this design keeps state only in RAM. It is excellent for understanding how chat products work, but once the process stops the conversation vanishes. That leads directly to the next architecture pattern: durable cloud-backed history.
Source-backed reinforcement: these points add detail beyond short-duration UI hints and emphasize production tradeoffs.
First-time learner note: Build deterministic baseline chains first (prompt -> model -> parser), then add retrieval, memory, or tools only when the baseline is stable.
Production note: Keep contracts explicit at each boundary: input variables, output schema, retries, and logs. This is what keeps orchestration reliable at scale.
This topic is really about the chat application loop. The local terminal demo behaves like a tiny chat product: prompt the user, append the new human message, invoke the model with the full history, append the returned AI message, and repeat until the user exits. The reason follow-up questions work is not because the model is streaming hidden memory forward; it is because the loop keeps replaying the updated history list each time.
System-design interpretation: input listener -> session history mutation -> model call -> output render -> persistence or in-memory update. Even though the demo is local and simple, it already contains the same control structure that real chat interfaces use. The production version adds multiple sessions, cancellation, authentication, logging, and durable storage, but the core loop is unchanged.
Edge cases: if one shared list is reused across users, conversations leak. If the process restarts, in-memory history disappears. If the exit path is not handled cleanly, users cannot terminate the loop without killing the process. The lesson is that interactive LLM apps are not just prompts; they are long-lived control flows with state transitions at every turn.
Exhaustive coverage points to ensure complete topic understanding without missing core concepts.
Conversation loop walkthrough: 1) Terminal asks the user for a question. 2) User types "What is the square root of 49?" 3) The app appends that as a HumanMessage and invokes the model. 4) The AI replies "7" and the app stores that answer as an AIMessage. 5) The user then asks "Do the same for 81." 6) The model answers correctly because the earlier turns are still in history. This is the simplest working architecture for a local multi-turn chat experience.
Guided Starter Example
Conversation loop walkthrough: 1) Terminal asks the user for a question. 2) User types "What is the square root of 49?" 3) The app appends that as a HumanMessage and invokes the model. 4) The AI replies "7" and the app stores that answer as an AIMessage. 5) The user then asks "Do the same for 81." 6) The model answers correctly because the earlier turns are still in history. This is the simplest working architecture for a local multi-turn chat experience.
Source-grounded Practical Scenario
Building a local multi-turn chat loop that keeps history in memory and answers follow-up questions correctly.
Source-grounded Practical Scenario
If the user asks, Do the same for 81 after asking about the square root of 49, the model can infer that the new question refers to square roots only because the prior turns are still inside chat_history .
Real-time conversation loop from the course code.
content/github_code/langchain-course/1_chat_models/4_chat_model_conversation_with_user.py
Interactive user input loop for live chat.
Open highlighted code →Questions an interviewer is likely to ask about this topic. Think through your answer before reading the senior angle.
Test yourself before moving on. Flip each card to check your understanding — great for quick revision before an interview.
Drag to reorder the architecture flow for Chat Models — Real-time Conversation. This is designed as an interview rehearsal for explaining end-to-end execution.
Explore how LangChain chat applications move from a simple message list to a durable session architecture. Each view shows the state object the model actually sees.
LangChain conversations are explicit message arrays. The model only knows what you send in the current request.
session_id: user-42 storage: Firestore messages: - system: You are a helpful assistant. - human: Summarize the last release. - ai: The release added evaluation dashboards. - human: What changed for monitoring? - lifecycle: process-memory only
Chat Models use structured message lists instead of raw strings. Build a conversation below, choose your provider, and see the exact Python code. LangChain's abstraction means swapping providers requires changing one import line.
You are a concise ML tutor. Explain concepts clearly.
What is a vector embedding?
Start flipping cards to track your progress
What makes a terminal chat app feel conversational?
tap to reveal →Each turn appends a new HumanMessage and AIMessage to the same chat_history list, then sends the full history again on the next model call.