Why do curly braces in user text break a LangChain f-string prompt template?

## What the default format actually does When you write `PromptTemplate.from_template("Summarize: {doc}")`, LangChain parses the string using Python's format-string grammar to discover variable names, and later substitutes values using that same grammar. The default `template_format` is `"f-string"`. Two consequences follow, and both surprise people. First, the parser has no idea which braces you meant as variables. Every `{` opens a field. A template containing a JSON example, a code snippet with a dict literal, a LaTeX expression or a regex quantifier such as `\d{3}` is full of accidental fields. Second, the format grammar is richer than "name in braces": a colon inside the braces starts a format spec. So `{"status": "ok"}` is read as a field named `"status"` with format spec ` "ok"`, which is why the resulting error message often names something that looks nothing like a variable you wrote. ## The three fixes **Pass it as a value.** This is the right answer almost always. Values substituted into a template are inserted literally; they are not scanned again for braces. So a document, a user question, a retrieved chunk, or a JSON blob handed in as `{context}` can contain any braces at all and nothing breaks. ``` prompt = ChatPromptTemplate.from_messages([("human", "Analyse this:\n{payload}")]) prompt.format_messages(payload='{"status": "ok"}') # fine ``` **Double the braces.** When the literal genuinely belongs in the template — you are showing the model the output schema you want — escape it: ``` ChatPromptTemplate.from_messages([ ("system", 'Reply as JSON: {{"status": "ok", "score": 0.0}}'), ("human", "{input}"), ]) ``` The rendered output contains single braces. This is correct but fragile in review: the doubling is easy to lose when someone reformats the string or copies the schema from elsewhere. **Change the template format.** Templates accept `template_format="mustache"`, where variables are `{{name}}` and single braces are ordinary characters — a good fit for prompts that are mostly JSON with a couple of slots. Jinja2 is also supported, but it is a full expression language, so never point it at a template string that any untrusted input helped construct. ## The production failure that matters The escaping puzzle is a nuisance; the dangerous version is building templates dynamically. Code that does ``` ChatPromptTemplate.from_messages([("human", f"Answer this: {user_question}")]) ``` has put user text into the *template*, not into a value. Now every brace the user types becomes a template field. At best you get an error whenever someone pastes JSON or code — an availability bug reachable by any user, and one that only shows up for a subset of inputs, so it survives testing. At worst, if the user writes a name that happens to match a real variable in scope, their text is replaced by that variable's value, which can be internal context they were never meant to see. The rule that prevents the whole class: **the template is code, the inputs are data.** Templates are written by developers, live in source, and are reviewed. Anything that arrives at runtime goes in as a variable value. If you find yourself f-stringing into a template argument, that is the bug. The same rule explains a related subtlety: a concrete message object placed into `from_messages` is inserted literally rather than templated, so its content is not scanned for braces. That can be a deliberate escape hatch for fixed text containing braces. ## Diagnosing it Symptoms: a missing-key error naming something that is not one of your variables; `prompt.input_variables` containing entries you never declared; a prompt that works in tests and fails on the one customer who pastes a stack trace. The first check is always `print(prompt.input_variables)` — if there is a stray name in there, an unescaped brace is the cause. The second is to confirm no template string was built with an f-string or `.format()` or concatenation at runtime. ## Guardrails worth having Keep prompts in a dedicated module as literals, so review sees them. Assert on `input_variables` in a unit test for each prompt — that single assertion catches an accidental brace, a renamed variable and a typo'd placeholder key in one line. Add a test that formats each prompt with adversarial values containing braces, quotes and newlines. And when a prompt must embed a schema, prefer describing the structure via a structured-output constraint over pasting a brace-heavy example into the template.