Considering config['configurable'] vs context

Hello Everyone!

The concept of graph Context was introduced with the update of Langgraph to 0.6.0. I’ve been grappling with understanding the use of Context vs the use of config[“configurable”] since. My understanding is that Context is meant to be a complete replacement of config[“configurable”], but in my experience this hasn’t been the case. For example, when passing immutable state to a thread run, context does a great job with taking the place of config[“configurable”] and is accessed, per the documentation, via Runtime (runtime.context). The exception here being the thread_id. I’ve yet to figure out how to correctly handle thread_id. Conversely, I’ve found it better to store Assistant configurations in config[“configurable”] instead of Context. For me, it makes sense for there to be a deliniation between where immutable state and configuration of an Assistant lives; afterall these are two different responsibilities. Unfortunately, packages depend on context being pased as config. For example, for LangMem’s namespace templates to work, you must pass the parameter you’re templating in config['“configurable”]. Overall Context to replace config[“configurable”] seemed like a great update surface but has had unexpected consequences downstream.

As this concept is so new, I wanted to see if anyone else here thoughts on this, what they’re doing for best practices with the concepts, etc. Let me know your thoughts and lets discuss!

1 Like

You’re right, the idea behind LangGraph 0.6.0 was for Context to be the unified place for user defined data, effectively replacing config["configurable"]. In practice though, most developers are still using a hybrid approach because the ecosystem (and core features like thread_id) hasn’t fully caught up.

What’s emerging as best practice looks like this:

  • Use Context for immutable runtime state that’s tied to application logic and should be accessible across nodes.

  • Use config["configurable"] for system level configuration (e.g. thread_id, assistant settings) and for compatibility with packages like LangMem that haven’t fully transitioned to Context.

So your separation, Context for state, config for assistant config and package compatibility, is actually the cleanest approach for now. Until the core and ecosystem fully align on Context, treating them as complementary rather than mutually exclusive is the most practical path.