LangChain Prompt Templates: Dynamic Prompts with Variables and Chat History

Every real LLM application sends the same prompt structure over and over — a system instruction, some context, maybe a few examples — with only the specifics changing each time. Hard-coding those prompts as f-[strings](/python/python-string-formatting/) works for a demo. It falls apart the moment you need to swap models, track history, or share prompt logic across a team. LangChain prompt templates fix this by turning prompts into composable, reusable objects.

A prompt template is a reusable blueprint for generating prompts. You define it once with placeholder variables, then fill in those variables at call time.

I spent a lot of time early on building LLM apps with raw f-strings. It worked until I had three endpoints using slightly different versions of the same prompt. A single wording change meant editing code in three places. Templates eliminate that problem entirely.

Here is the core idea — a hard-coded prompt vs. a template:

Both produce the same text. The difference shows up when your application grows. The template version validates its inputs, composes with other LangChain components via the pipe operator, and separates prompt structure from data.

LangChain scans the template strings and extracts every {variable_name} it finds. When you call .invoke(), it requires exactly those keys. Pass fewer and you get a KeyError; pass extra and they are silently ignored.

To produce the final messages, call .invoke() with a dictionary:

Each message carries a .type property ("system", "human", or "ai") and a .content string. This maps directly to the message format every LLM provider expects.

You have already seen "system" and "human". The third role — "ai" — unlocks few-shot examples by embedding previous model responses directly into the template.

The "ai" messages act as few-shot examples. The model sees a previous Q&A exchange and matches that style for the new question. This is one of the simplest ways to steer output format without writing elaborate system instructions.

Sometimes you know one variable at deploy time but another only at call time. You might fix the output language when you configure the app but let users provide the question. LangChain's .partial() method handles this cleanly.

After calling .partial(), the returned template no longer requires the bound variable. You get a new template object — the original stays unchanged. I use this constantly for multi-tenant apps where each tenant has different system instructions but the same prompt skeleton.

You can also bind a callable that runs at invoke time. A common pattern is injecting the current date:

The date updates automatically on every call. No need to thread it through your application code.

This is the feature that makes prompt templates genuinely powerful for conversational apps. A MessagesPlaceholder reserves a slot where a list of messages gets injected at runtime.

Without it, you would need to manually concatenate history strings and track role labels yourself. With MessagesPlaceholder, you pass typed message objects and LangChain inserts them in the right position.

The history messages slot in between the system message and the new user message. That is exactly where every LLM provider expects conversation context. The template stays the same whether the history has 0 or 50 messages.

A prompt template on its own just produces message objects. The real payoff comes when you pipe it into a model and an output parser using LCEL.

The | operator connects each step. Data flows left to right: the template produces messages, the model generates a response, and the parser extracts the text. The entire chain is itself a Runnable — you can invoke, stream, or batch it.

This is where templates earn their keep. Want to swap gpt-4o-mini for Claude or Gemini? The prompt template stays identical. You only change the model object. The template does not care which provider consumes the messages.

In any serious LLM project, you end up with dozens of prompts for different tasks. Scattering template definitions across your codebase makes them hard to find and easy to accidentally duplicate. A clean pattern is to centralize all templates in one module.

Every developer on the team imports from the same prompts.py. Changing a system instruction means editing one file, not hunting through endpoint handlers. I have seen teams with 40+ endpoints where each had its own inline prompt — maintaining that was a nightmare.

Here is a practical application combining templates, variables, history, and chains. We will build a code review assistant that accepts a programming language, a code snippet, and optional conversation history for follow-up questions.

The template uses {language} in both the system message and the code fence. The MessagesPlaceholder with optional=True means the first review works without history.

The model spots the division-by-zero risk and likely suggests a dictionary dispatch pattern.

For a follow-up, pass the previous exchange as history:

The model has the full context of the original review. It generates the refactored version without needing the code repeated. The template handles conversation continuity while your application code stays clean.

LangChain uses {variable} syntax for placeholders. If your prompt contains literal curly braces — JSON examples, dictionary literals — you must double them.

The MessagesPlaceholder variable expects a list of message objects. Passing a raw string gives a confusing type error.

If your template uses {user_question} but you pass {"question": "..."}, LangChain raises a KeyError. Always check template.input_variables to see the exact keys it expects.

History should go between the system message and the current human message. Placing it after the human message means the model sees the question before the context.

LangChain supports loading templates from files using load_prompt() from langchain_core.prompts. However, the YAML schema for ChatPromptTemplate can be brittle across versions. I prefer defining templates in Python modules — you get IDE autocompletion, type checking, and readable version control diffs.

Pass template_format="jinja2" when creating a PromptTemplate. This gives you {{ variable }} syntax plus conditionals and loops. Note that ChatPromptTemplate.from_messages() does not support Jinja2 directly — you need ChatPromptTemplate.from_template() for individual message strings.

LangChain itself has no hard limit. The constraint comes from the model's context window. A template with few-shot examples and a MessagesPlaceholder can easily produce hundreds of messages. The template will not complain, but the model will reject anything beyond its token limit.

Always pair your templates with a history-trimming strategy in production.

Yes. Prompt templates are model-agnostic. ChatPromptTemplate produces BaseMessage objects that every LangChain chat model accepts — ChatOpenAI, ChatAnthropic, ChatGoogleGenerativeAI, ChatOllama, and others. Write the prompt once, pipe it into any model.