Skip to content
Forward Deployed
Forward Deployed
Lessons and contents
LangChain Core: Models, Prompts & ParsersLesson 1 of 9
9 lessons
Learn

LangChain Core: Models, Prompts & Parsers: overview

Source
From the RAG & Agents Engineering course
By
Sourav Banerjee
Last updated
8 Nov 2026

Report an issue

Every LangChain program in this course has the same three parts: a prompt template that turns variables into messages, a chat model that turns messages into an AIMessage, and an output parser that turns the AIMessage into something your code can use. The T4.1 notebooks build on four ideas: chat models, messages, prompt templates and output parsers.

The running example is the Larkspur Cloud support assistant that T5.1 to T5.3 build, at the step after retrieval. It holds three handbook passages (refund-window, refund-timing and billing) for the question How long does a refund take? and must return a JSON answer with a list of the passages it cites. That is the module's lab brief, and the lab runs it.

In short

  • LangChain 1.x splits the old langchain package by how fast each part changes: base types in langchain-core, one partner package per provider, retired APIs in langchain-classic. A 0.x path such as langchain.chains raises ModuleNotFoundError with no deprecation warning first.
  • Every chat model takes a string, a message list or a PromptValue and returns an AIMessage with .content, .usage_metadata and .response_metadata. Changing provider changes one class or one "provider:model" string.
  • A chat model keeps no state. The conversation is the message list you send, so every earlier turn is paid for again on every call.
  • A prompt template turns variables into a PromptValue, which becomes a string or a message list for whichever model receives it. Its input_variables are recomputed from the template text, so a typo in the list you pass is replaced without an error.
  • A parser cannot make a reply good. It decides whether a bad reply raises. On the lab's eight replies, JsonOutputParser raises on 1 and returns 4 unusable results; PydanticOutputParser with the passage ids as a Literal raises on 5 and returns none. Both give the same 3 usable answers.

Mental model

One call through prompt, model and parser A dict with the refund question and three passages fills a prompt template, which produces system and human messages. A chat model returns an AIMessage holding JSON text and token counts. The output parser checks the JSON against the schema and returns an Answer citing refund-timing, or raises OutputParserException when a citation names no real passage. Into the model: what you send Out of the model: what your code gets Variables Prompt template Chat model question 3 passages system human same call for any provider AIMessage Output parser Answer content: JSON text usage_metadata find the JSON, then the schema citations: refund-timing or a raise
  1. The chain is invoked with a dict: the refund question and three handbook passages.
  2. The prompt template fills its slots and returns a PromptValue holding a system message and a human message.
  3. The chat model sends the messages to its provider. Every chat model class takes the same input.
  4. The reply comes back as an AIMessage: the text on .content, token counts on .usage_metadata.
  5. The parser finds the JSON in the text, then validates it against the schema.
  6. The lab’s clean reply becomes an Answer object that cites refund-timing.
  7. A reply that cites handbook-p4, an id no passage has, raises OutputParserException under the Literal schema instead.

The prompt template and the parser are where your code meets the model's text. The template decides what the model reads; the parser decides what reaches the rest of your program, and whether a malformed reply arrives as an exception or as a value that looks fine.

Interactive lab

The parser bench: open the file in a browser. Start on JsonOutputParser and read the four rows marked unusable: each one parsed without an error. Switch to PydanticOutputParser with Literal ids and watch them move to the raised column while the usable count stays at 3. Then pick Clean JSON in the inspector and drag the cut slider down, as a max_tokens limit would, to see JsonOutputParser repair almost every truncated reply into a dict.

How it connects

  • Before: T2.2 calls the provider SDKs that T4.1 wraps. T3.1 writes the prompt patterns that T4.1 turns into templates, and T3.2 sends images through the same message lists.
  • Next: T4.2 pipes templates, models and parsers into LCEL chains. T5.1 builds the first RAG pipeline from them, and T7.2 returns to structured output for agents. T9.1 grades retrieved passages with schema-bound model calls.

Key Takeaways

  • Import from langchain_core for prompts, messages and parsers, and from a partner package for the model. A ModuleNotFoundError on an old path means the module moved; an ImportError means the name did.
  • Send the conversation every time. The model remembers nothing between calls, and every resent turn costs input tokens.
  • Build prompts from templates with explicit slots, and check input_variables and the formatted messages before the first model call.
  • Pick the parser for which failures you want to see. Put every rule you can into the schema, so a bad reply raises instead of passing.

Rate your confidence and keep notes on the module page.