docs build fixes

docs/docs/cloud/how-tos/configuration_cloud.md

@@ -2,7 +2,7 @@
 
 In this guide we will show how to create, configure, and manage an [assistant](../../concepts/assistants.md).
 
-First, as a brief refresher on the concept of runtime context, consider the following simple `call_model` node and configuration schema. Observe that this node tries to read and use the `model_provider` as defined by the `Runtime` object's `context` property.
+First, as a brief refresher on the concept of runtime context, consider the following simple `call_model` node and context schema. Observe that this node tries to read and use the `model_provider` as defined by the `Runtime` object's `context` property.
 
 === "Python"
 
@@ -43,7 +43,7 @@ First, as a brief refresher on the concept of runtime context, consider the foll
     }
     ```
 
-For more information on configurations, [see here](../../concepts/low_level.md#configuration).
+For more information on runtime context, [see here](../../concepts/low_level.md#runtime-context).
 
 ## Create an assistant
 

docs/docs/concepts/assistants.md

@@ -1,6 +1,6 @@
 # Assistants
 
-**Assistants** allow you to manage configurations (like prompts, LLM selection, tools) separately from your graph's core logic, enabling rapid changes that don't alter the graph architecture. It is a way to create multiple specialized versions of the same graph architecture, each optimized for different use cases through configuration variations rather than structural changes.
+**Assistants** allow you to manage configurations (like prompts, LLM selection, tools) separately from your graph's core logic, enabling rapid changes that don't alter the graph architecture. It is a way to create multiple specialized versions of the same graph architecture, each optimized for different use cases through context/configuration variations rather than structural changes.
 
 For example, imagine a general-purpose writing agent built on a common graph architecture. While the structure remains the same, different writing styles—such as blog posts and tweets—require tailored configurations to optimize performance. To support these variations, you can create multiple assistants (e.g., one for blogs and another for tweets) that share the underlying graph but differ in model selection and system prompt.
 
@@ -14,8 +14,8 @@ The LangGraph Cloud API provides several endpoints for creating and managing ass
 
 ## Configuration
 
-Assistants build on the LangGraph open source concept of [configuration](low_level.md#configuration).
-While configuration is available in the open source LangGraph library, assistants are only present in [LangGraph Platform](langgraph_platform.md). This is due to the fact that assistants are tightly coupled to your deployed graph. Upon deployment, LangGraph Server will automatically create a default assistant for each graph using the graph's default configuration settings.
+Assistants build on the LangGraph open source concepts of configuration and [runtime context](low_level.md#runtime-context).
+While these features are available in the open source LangGraph library, assistants are only present in [LangGraph Platform](langgraph_platform.md). This is due to the fact that assistants are tightly coupled to your deployed graph. Upon deployment, LangGraph Server will automatically create a default assistant for each graph using the graph's default context and configuration settings.
 
 In practice, an assistant is just an _instance_ of a graph with a specific configuration. Therefore, multiple assistants can reference the same graph but can contain different configurations (e.g. prompts, models, tools). The LangGraph Server API provides several endpoints for creating and managing assistants. See the [API reference](../cloud/reference/api/api_ref.html) and [this how-to](../cloud/how-tos/configuration_cloud.md) for more details on how to create assistants.
 
@@ -26,6 +26,6 @@ Once you've created an assistant, subsequent edits to that assistant will create
 
 ## Execution
 
-A **run** is an invocation of an assistant. Each run may have its own input, configuration, and metadata, which may affect execution and output of the underlying graph. A run can optionally be executed on a [thread](./persistence.md#threads).
+A **run** is an invocation of an assistant. Each run may have its own input, configuration, context, and metadata, which may affect execution and output of the underlying graph. A run can optionally be executed on a [thread](./persistence.md#threads).
 
 The LangGraph Platform API provides several endpoints for creating and managing runs. See the [API reference](../cloud/reference/api/api_ref.html#tag/thread-runs/) for more details.

docs/docs/concepts/low_level.md

@@ -192,35 +192,48 @@ class State(MessagesState):
 
 ## Nodes
 
-In LangGraph, nodes are typically python functions (sync or async) where the **first** positional argument is the [state](#state), and (optionally), the **second** positional argument is a "config", containing optional [configurable parameters](#configuration) (such as a `thread_id`).
+In LangGraph, nodes are Python functions (either synchronous or asynchronous) that accept the following arguments:
+
+1. `state`: The [state](#state) of the graph
+2. `config`: A `RunnableConfig` object that contains configuration information like `thread_id` and tracing information like `tags`
+3. `runtime`: A `Runtime` object that contains [runtime `context`](#runtime-context) and other information like `store` and `stream_writer`
+    
 
 Similar to `NetworkX`, you add these nodes to a graph using the [add_node][langgraph.graph.StateGraph.add_node] method:
 
 ```python
+from dataclasses import dataclass
 from typing_extensions import TypedDict
 
 from langchain_core.runnables import RunnableConfig
 from langgraph.graph import StateGraph
+from langgraph.runtime import Runtime
 
 class State(TypedDict):
     input: str
     results: str
 
+@dataclass
+class Context:
+    user_id: str
+
 builder = StateGraph(State)
 
+def plain_node(state: State):
+    return state
 
-def my_node(state: State, config: RunnableConfig):
-    print("In node: ", config["configurable"]["user_id"])
+def node_with_runtime(state: State, runtime: Runtime[Context]):
+    print("In node: ", runtime.context.user_id)
+    return {"results": f"Hello, {state['input']}!"}
+
+def node_with_config(state: State, config: RunnableConfig):
+    print("In node with thread_id: ", config["configurable"]["thread_id"])
     return {"results": f"Hello, {state['input']}!"}
 
 
-# The second argument is optional
-def my_other_node(state: State):
-    return state
-
-
-builder.add_node("my_node", my_node)
-builder.add_node("other_node", my_other_node)
+builder.add_node("plain_node", plain_node)
+builder.add_node("node_with_runtime", node_with_runtime)
+builder.add_node("node_with_config", node_with_config)
 ...
 ```