Passing config through nested chains
Why this matters
When you build complex chains with multiple levels of nesting, you need to pass runtime configuration (timeouts, callbacks, tags) to all layers without threading parameters through every intermediate function. RunnableConfig makes this clean and avoids leaky abstractions.
Explanation
RunnableConfig is a built-in langchain mechanism for passing execution metadata through nested chains without polluting function signatures. When you invoke a chain with chain.invoke(input, config={'tags': [...], 'callbacks': [...], ...}), that config automatically flows to all child Runnable objects in the chain, even across multiple levels of nesting. Mechanically, each Runnable in the chain receives the config in its invoke method: you access it via run_manager in custom Runnables, or the chain automatically forwards it to all child Runnables without you doing anything. This works because LCEL (Langchain Expression Language) chains are composable Runnable objects that understand config propagation natively. Use RunnableConfig when you have deeply nested chains, need to add callbacks at runtime, set tags for observability, or apply timeouts globally without modifying nested function signatures.
Analogy
Like passing a request context through middleware in a web framework: the config flows through your entire chain stack automatically, available at every layer without being explicitly passed as a function argument.
Code
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnableConfig, RunnableLambda
from langchain_core.callbacks import BaseCallbackHandler
class LoggingCallback(BaseCallbackHandler):
def on_llm_start(self, serialized, prompts, **kwargs):
print(f"[CALLBACK] LLM call starting with prompt: {prompts[0][:50]}...")
def nested_processor(text: str, config: RunnableConfig) -> str:
run_manager = config.get("run_manager")
tags = config.get("tags", [])
print(f"[NESTED] Processing '{text}' with tags: {tags}")
return f"Processed: {text}"
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
prompt = ChatPromptTemplate.from_template(
"Summarize this in one sentence: {input}"
)
parser = StrOutputParser()
process_step = RunnableLambda(nested_processor)
chain = prompt | llm | parser | process_step
callback = LoggingCallback()
result = chain.invoke(
{"input": "The quick brown fox jumps over the lazy dog."},
config={
"tags": ["production", "summarization"],
"callbacks": [callback],
"run_name": "nested_chain_example"
}
)
print(f"\n[FINAL] {result}")[CALLBACK] LLM call starting with prompt: Summarize this in one sentence: The quick brown fox jumps over the lazy dog...\n[NESTED] Processing 'A quick brown fox jumps over a lazy dog.' with tags: ['production', 'summarization']\n\n[FINAL] Processed: A quick brown fox jumps over a lazy dog.
What just happened?
The config dict (containing tags and callbacks) was passed into chain.invoke(). The ChatOpenAI model received the callbacks automatically and triggered the callback handler when the LLM started. The RunnableLambda at the end received that same config via the nested_processor function, which extracted the tags. At no point did we manually thread the config through intermediate steps: LCEL handled it.
Common gotcha
Developers often try to access config as a positional argument in RunnableLambda: you must accept it as the second parameter and it only appears if you explicitly add it. If you define `RunnableLambda(lambda text: ...)` with only one argument, the config is ignored silently. The RunnableLambda must be defined as `RunnableLambda(lambda text, config: ...)` or use a regular function with both parameters.
Error recovery
TypeError: nested_processor() missing 1 required positional argument: 'config'KeyError when accessing config['tags']Callbacks not firing in nested chainExperienced dev note
In older LangChain patterns (< 0.2.0), people would pass configuration through function closures or class state, making tests hard to write. RunnableConfig makes config explicit and testable: you can mock it in unit tests via the config parameter. Also: config propagation only works with LCEL chains (the pipe operator). If you're using legacy AgentExecutor or custom Runnable subclasses without implementing config forwarding, you'll break the chain. Always call `super().invoke(input, run_manager=run_manager.get_child())` in custom Runnable.invoke() to pass config downstream.
Check your understanding
You have a three-layer chain: (LLM prompt) → (custom parser) → (RunnableLambda). You want callbacks to fire at the LLM layer and custom parser tags to be visible in the Lambda. How would you pass both without modifying the parser's function signature?
Show answer hint
A correct answer shows understanding that (1) config is passed once at invoke() time, (2) it flows automatically to LLM and through LCEL composition, (3) the RunnableLambda must accept config as a second parameter to access tags, and (4) you don't modify the parser function itself.