x

.github/workflows/deploy_docs.yml

@@ -4,9 +4,11 @@ on:
   push:
     branches:
       - main
+      - v0
   pull_request:
     branches:
       - main
+      - v0
   workflow_dispatch:
 
 permissions:
@@ -82,9 +84,9 @@ jobs:
         run: make llms-text
       - name: Build site
         run: |
-          # If this is main branch, then we want to download stats. we do this 
+          # If this is v0 branch, then we want to download stats. we do this 
           # with the env variable DOWNLOAD_STATS=true
-          if [ "${{ github.ref }}" == "refs/heads/main" ]; then
+          if [ "${{ github.ref }}" == "refs/heads/v0" ]; then
             DOWNLOAD_STATS=true make build-docs
           else
             make build-docs
@@ -144,7 +146,7 @@ jobs:
           fi
 
       - name: Configure GitHub Pages
-        if: github.ref == 'refs/heads/main'
+        if: github.ref == 'refs/heads/v0'
         uses: actions/configure-pages@v5
 
       - name: Upload Pages Artifact
@@ -154,6 +156,6 @@ jobs:
           path: ./docs/site/
 
       - name: Deploy to GitHub Pages
-        if: github.ref == 'refs/heads/main'
+        if: github.ref == 'refs/heads/v0'
         id: deployment
         uses: actions/deploy-pages@v4

docs/_scripts/notebook_hooks.py

@@ -15,8 +15,8 @@ from mkdocs.structure.files import Files, File
 from mkdocs.structure.pages import Page
 
 from _scripts.generate_api_reference_links import update_markdown_with_imports
-from _scripts.notebook_convert import convert_notebook
 from _scripts.link_map import JS_LINK_MAP
+from _scripts.notebook_convert import convert_notebook
 
 logger = logging.getLogger(__name__)
 logging.basicConfig()
@@ -49,24 +49,19 @@ REDIRECT_MAP = {
     "how-tos/return-when-recursion-limit-hits.ipynb": "how-tos/graph-api/#impose-a-recursion-limit",
     "how-tos/async.ipynb": "how-tos/graph-api/#async",
     # memory how-tos
-    "how-tos/memory/manage-conversation-history.ipynb": "how-tos/memory/add-memory.md",
-    "how-tos/memory/delete-messages.ipynb": "how-tos/memory/add-memory.md#delete-messages",
-    "how-tos/memory/add-summary-conversation-history.ipynb": "how-tos/memory/add-memory.md#summarize-messages",
-    "how-tos/memory.ipynb": "how-tos/memory/add-memory.md",
-    "agents/memory.ipynb": "how-tos/memory/add-memory.md",
+    "how-tos/memory/manage-conversation-history.ipynb": "how-tos/memory.ipynb",
+    "how-tos/memory/delete-messages.ipynb": "how-tos/memory.ipynb#delete-messages",
+    "how-tos/memory/add-summary-conversation-history.ipynb": "how-tos/memory.ipynb#summarize-messages",
     # subgraph how-tos
     "how-tos/subgraph-transform-state.ipynb": "how-tos/subgraph.ipynb#different-state-schemas",
     "how-tos/subgraphs-manage-state.ipynb": "how-tos/subgraph.ipynb#add-persistence",
     # persistence how-tos
-    "how-tos/persistence_postgres.ipynb": "how-tos/memory/add-memory.md#use-in-production",
-    "how-tos/persistence_mongodb.ipynb": "how-tos/memory/add-memory.md#use-in-production",
-    "how-tos/persistence_redis.ipynb": "how-tos/memory/add-memory.md#use-in-production",
-    "how-tos/subgraph-persistence.ipynb": "how-tos/memory/add-memory.md#use-with-subgraphs",
-    "how-tos/cross-thread-persistence.ipynb": "how-tos/memory/add-memory.md#add-long-term-memory",
+    "how-tos/persistence_postgres.ipynb": "how-tos/persistence.ipynb#use-in-production",
+    "how-tos/persistence_mongodb.ipynb": "how-tos/persistence.ipynb#use-in-production",
+    "how-tos/persistence_redis.ipynb": "how-tos/persistence.ipynb#use-in-production",
+    "how-tos/subgraph-persistence.ipynb": "how-tos/persistence.ipynb#use-with-subgraphs",
+    "how-tos/cross-thread-persistence.ipynb": "how-tos/persistence.ipynb#add-long-term-memory",
     "cloud/how-tos/copy_threads": "cloud/how-tos/use_threads",
-    "cloud/how-tos/check-thread-status": "cloud/how-tos/use_threads",
-    "cloud/concepts/threads.md": "concepts/persistence.md#threads",
-    "how-tos/persistence.ipynb": "how-tos/memory/add-memory.md",
     # tool calling how-tos
     "how-tos/tool-calling-errors.ipynb": "how-tos/tool-calling.ipynb#handle-errors",
     "how-tos/pass-config-to-tools.ipynb": "how-tos/tool-calling.ipynb#access-config",
@@ -92,17 +87,16 @@ REDIRECT_MAP = {
     "cloud/how-tos/stream_events.md": "cloud/how-tos/streaming.md#stream-events",
     "cloud/how-tos/stream_debug.md": "cloud/how-tos/streaming.md#debug",
     "cloud/how-tos/stream_multiple.md": "cloud/how-tos/streaming.md#stream-multiple-modes",
-    "cloud/concepts/streaming.md": "concepts/streaming.md",
-    "agents/streaming.md": "how-tos/streaming.md",
-    # prebuilt redirects
+    # prebuit redirects
     "how-tos/create-react-agent.ipynb": "agents/agents.md#basic-configuration",
     "how-tos/create-react-agent-memory.ipynb": "agents/memory.md",
     "how-tos/create-react-agent-system-prompt.ipynb": "agents/context.md#prompts",
+    "how-tos/create-react-agent-hitl.ipynb": "agents/human-in-the-loop.md",
     "how-tos/create-react-agent-structured-output.ipynb": "agents/agents.md#structured-output",
     # Time-travel
-    "how-tos/human_in_the_loop/edit-graph-state.ipynb": "how-tos/human_in_the_loop/time-travel.md",
+    "how-tos/human_in_the_loop/edit-graph-state.ipynb": "how-tos/human_in_the_loop/time-travel.ipynb",
     # breakpoints
-    "how-tos/human_in_the_loop/dynamic_breakpoints.ipynb": "how-tos/human_in_the_loop/breakpoints.md",
+    "how-tos/human_in_the_loop/dynamic_breakpoints.ipynb": "how-tos/human_in_the_loop/breakpoints.ipynb",
     # misc
     "prebuilt.md": "agents/prebuilt.md",
     "reference/prebuilt.md": "reference/agents.md",
@@ -111,19 +105,11 @@ REDIRECT_MAP = {
     "concepts/v0-human-in-the-loop.md": "concepts/human-in-the-loop.md",
     "how-tos/index.md": "index.md",
     "tutorials/introduction.ipynb": "concepts/why-langgraph.md",
-    "agents/deployment.md": "tutorials/langgraph-platform/local-server.md",
     # deployment redirects
     "how-tos/deploy-self-hosted.md": "cloud/deployment/self_hosted_data_plane.md",
     "concepts/self_hosted.md": "concepts/langgraph_self_hosted_data_plane.md",
-    "tutorials/deployment.md": "concepts/deployment_options.md",
     # assistant redirects
     "cloud/how-tos/assistant_versioning.md": "cloud/how-tos/configuration_cloud.md",
-    "cloud/concepts/runs.md": "concepts/assistants.md#execution",
-    # hitl redirects
-    "how-tos/wait-user-input-functional.ipynb": "how-tos/use-functional-api.md",
-    "how-tos/review-tool-calls-functional.ipynb": "how-tos/use-functional-api.md",
-    "how-tos/create-react-agent-hitl.ipynb": "how-tos/human_in_the_loop/add-human-in-the-loop.md",
-    "agents/human-in-the-loop.md": "how-tos/human_in_the_loop/add-human-in-the-loop.md",
 }
 
 
@@ -201,7 +187,7 @@ def _resolve_cross_references(md_text: str, link_map: dict[str, str]) -> str:
 
 
 def _apply_conditional_rendering(md_text: str, target_language: str) -> str:
-    if target_language not in {"python", "js"}:
+    if target_language not in {"python", "js", "switcher"}:
         raise ValueError("target_language must be 'python' or 'js'")
 
     pattern = re.compile(
@@ -215,10 +201,16 @@ def _apply_conditional_rendering(md_text: str, target_language: str) -> str:
         language = match.group("language")
         content = match.group("content")
 
-        if language not in {"python", "js"}:
+        if language not in {"python", "js", "switcher"}:
             # If the language is not supported, return the original block
             return match.group(0)
 
+        if target_language == "switcher":
+            # Both Python and JavaScript blocks are wrapped in a tag that
+            # allows the user to switch between them.
+            standardized_language = "javascript" if language == "js" else "python"
+            return f'<div class="lang-{standardized_language}">\n' + content + "\n</div>"
+
         if language == target_language:
             return content
 
@@ -329,8 +321,8 @@ def _on_page_markdown_with_config(
     markdown = _highlight_code_blocks(markdown)
 
     # Apply conditional rendering for code blocks
-    target_language = kwargs.get("target_language", "python")
-    markdown = _apply_conditional_rendering(markdown, target_language)
+    target_language = kwargs.get("target_language", "js")
+    markdown = _apply_conditional_rendering(markdown, "switcher")
     if target_language == "js":
         markdown = _resolve_cross_references(markdown, JS_LINK_MAP)
     elif target_language == "python":

docs/docs/agents/agents.md

@@ -180,14 +180,14 @@ ny_response = agent.invoke(
 )
 ```
 
-1. `checkpointer` allows the agent to store its state at every step in the tool calling loop. This enables [short-term memory](../how-tos/memory/add-memory.md#add-short-term-memory) and [human-in-the-loop](../concepts/human_in_the_loop.md) capabilities.
+1. `checkpointer` allows the agent to store its state at every step in the tool calling loop. This enables [short-term memory](./memory.md#short-term-memory) and [human-in-the-loop](./human-in-the-loop.md) capabilities.
 2. Pass configuration with `thread_id` to be able to resume the same conversation on future agent invocations.
 
 When you enable the checkpointer, it stores agent state at every step in the provided checkpointer database (or in memory, if using `InMemorySaver`).
 
 Note that in the above example, when the agent is invoked the second time with the same `thread_id`, the original message history from the first conversation is automatically included, together with the new user input.
 
-For more information, see [Memory](../how-tos/memory/add-memory.md).
+For more information, see [Memory](./memory.md).
 
 ## 6. Configure structured output
 

docs/docs/agents/context.md

@@ -1,8 +1,17 @@
+---
+search:
+  boost: 2
+tags:
+  - agent
+hide:
+  - tags
+---
+
 # Context
 
-**Context engineering** is the practice of building dynamic systems that provide the right information and tools, in the right format, so that a language model can plausibly accomplish a task.
+Agents often require more than a list of messages to function effectively. They need **context**.
 
-Context includes *any* data outside the message list that can shape behavior. This can be:
+Context includes *any* data outside the message list that can shape agent behavior or tool execution. This can be:
 
 - Information passed at runtime, like a `user_id` or API credentials.
 - Internal state updated during a multi-step reasoning process.
@@ -13,10 +22,18 @@ LangGraph provides **three** primary ways to supply context:
 | Type                                                                         | Description                                   | Mutable? | Lifetime                |
 |------------------------------------------------------------------------------|-----------------------------------------------|----------|-------------------------|
 | [**Config**](#config-static-context)                                         | data passed at the start of a run             | ❌        | per run                 |
-| [**Short-term memory (State)**](#short-term-memory-mutable-context)          | dynamic data that can change during execution | ✅        | per run or conversation |
-| [**Long-term memory (Store)**](#long-term-memory-cross-conversation-context) | data that can be shared between conversations | ✅        | across conversations    |
+| [**State**](#state-mutable-context)                                          | dynamic data that can change during execution | ✅        | per run or conversation |
+| [**Long-term Memory (Store)**](#long-term-memory-cross-conversation-context) | data that can be shared between conversations | ✅        | across conversations    |
 
-## Provide runtime context
+You can use context to:
+
+- Adjust the system prompt the model sees
+- Feed tools with necessary inputs
+- Track facts during an ongoing conversation
+
+## Providing Runtime Context
+
+Use this when you need to inject data into an agent at runtime.
 
 ### Config (static context)
 
@@ -27,83 +44,88 @@ Specify configuration using a key called **"configurable"** which is reserved
 for this purpose:
 
 ```python
-graph.invoke( # (1)!
-    {"messages": [{"role": "user", "content": "hi!"}]}, # (2)!
+agent.invoke(
+    {"messages": [{"role": "user", "content": "hi!"}]},
     # highlight-next-line
-    config={"configurable": {"user_id": "user_123"}} # (3)!
+    config={"configurable": {"user_id": "user_123"}}
 )
 ```
 
-1. This is the invocation of the agent or graph. The `invoke` method runs the underlying graph with the provided input.
-2. This example uses messages as an input, which is common, but your application may use different input structures.
-3. This is where you pass the configuration data. The `config` parameter allows you to provide additional context that the agent can use during its execution.
+### State (mutable context)
 
-=== "Agent prompt"
+State acts as short-term memory during a run. It holds dynamic data that can evolve during execution, such as values derived from tools or LLM outputs.
+
+```python
+class CustomState(AgentState):
+    # highlight-next-line
+    user_name: str
+
+agent = create_react_agent(
+    # Other agent parameters...
+    # highlight-next-line
+    state_schema=CustomState,
+)
+
+agent.invoke({
+    "messages": "hi!",
+    "user_name": "Jane"
+})
+```
+
+!!! tip "Turning on memory"
+
+    Please see the [memory guide](./memory.md) for more details on how to enable memory. This is a powerful feature that allows you to persist the agent's state across multiple invocations.
+    Otherwise, the state is scoped only to a single agent run.
+
+
+
+### Long-Term Memory (cross-conversation context)
+
+For context that spans *across* conversations or sessions, LangGraph allows access to **long-term memory** via a `store`. This can be used to read or update persistent facts (e.g., user profiles, preferences, prior interactions). For more, see the [Memory guide](./memory.md).
+
+## Customizing Prompts with Context { #prompts }
+
+Prompts define how the agent behaves. To incorporate runtime context, you can dynamically generate prompts based on the agent's state or config.
+
+Common use cases:
+
+- Personalization
+- Role or goal customization
+- Conditional behavior (e.g., user is admin)
+
+=== "Using config"
 
     ```python
     from langchain_core.messages import AnyMessage
     from langchain_core.runnables import RunnableConfig
-    from langgraph.prebuilt.chat_agent_executor import AgentState
     from langgraph.prebuilt import create_react_agent
+    from langgraph.prebuilt.chat_agent_executor import AgentState
 
-    # highlight-next-line
-    def prompt(state: AgentState, config: RunnableConfig) -> list[AnyMessage]:
+    def prompt(
+        state: AgentState,
+        # highlight-next-line
+        config: RunnableConfig,
+    ) -> list[AnyMessage]:
+        # highlight-next-line
         user_name = config["configurable"].get("user_name")
-        system_msg = f"You are a helpful assistant. Address the user as {user_name}."
+        system_msg = f"You are a helpful assistant. User's name is {user_name}"
         return [{"role": "system", "content": system_msg}] + state["messages"]
 
     agent = create_react_agent(
         model="anthropic:claude-3-7-sonnet-latest",
         tools=[get_weather],
+        # highlight-next-line
         prompt=prompt
     )
 
     agent.invoke(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        ...,
         # highlight-next-line
         config={"configurable": {"user_name": "John Smith"}}
     )
     ```
 
-    * See [Agents](../agents/agents.md) for details.
-
-=== "Workflow node"
-
-    ```python
-    from langchain_core.runnables import RunnableConfig
-
-    # highlight-next-line
-    def node(state: State, config: RunnableConfig):
-        user_name = config["configurable"].get("user_name")
-        ...
-    ```
-
-    * See [the Graph API](https://langchain-ai.github.io/langgraph/how-tos/graph-api/#add-runtime-configuration) for details.
-
-=== "In a tool"
-
-    ```python
-    from langchain_core.runnables import RunnableConfig
-
-    @tool
-    # highlight-next-line
-    def get_user_info(config: RunnableConfig) -> str:
-        """Retrieve user information based on user ID."""
-        user_id = config["configurable"].get("user_id")
-        return "User is John Smith" if user_id == "user_123" else "Unknown user"
-    ```
-
-    See the [tool calling guide](../how-tos/tool-calling.md#configuration) for details.
-
-### Short-term memory (mutable context)
-
-State acts as [short-term memory](../concepts/memory.md) during a run. It holds dynamic data that can evolve during execution, such as values derived from tools or LLM outputs.
-
-=== "In an agent"
-
-    Example shows how to incorporate state into an agent **prompt**.
-
-    State can also be accessed by the agent's **tools**, which can read or update the state as needed. See [tool calling guide](../how-tos/tool-calling.md#short-term-memory) for details.
+=== "Using state"
 
     ```python
     from langchain_core.messages import AnyMessage
@@ -111,14 +133,15 @@ State acts as [short-term memory](../concepts/memory.md) during a run. It holds
     from langgraph.prebuilt import create_react_agent
     from langgraph.prebuilt.chat_agent_executor import AgentState
 
-    # highlight-next-line
-    class CustomState(AgentState): # (1)!
+    class CustomState(AgentState):
+        # highlight-next-line
         user_name: str
 
     def prompt(
         # highlight-next-line
         state: CustomState
     ) -> list[AnyMessage]:
+        # highlight-next-line
         user_name = state["user_name"]
         system_msg = f"You are a helpful assistant. User's name is {user_name}"
         return [{"role": "system", "content": system_msg}] + state["messages"]
@@ -127,58 +150,87 @@ State acts as [short-term memory](../concepts/memory.md) during a run. It holds
         model="anthropic:claude-3-7-sonnet-latest",
         tools=[...],
         # highlight-next-line
-        state_schema=CustomState, # (2)!
+        state_schema=CustomState,
+        # highlight-next-line
         prompt=prompt
     )
 
     agent.invoke({
         "messages": "hi!",
+        # highlight-next-line
         "user_name": "John Smith"
     })
     ```
 
-    1. Define a custom state schema that extends `AgentState` or `MessagesState`.
-    2. Pass the custom state schema to the agent. This allows the agent to access and modify the state during execution.
+## Accessing Context in Tools { #tools }
+
+Tools can access context through special parameter **annotations**.
+
+* Use `RunnableConfig` for config access
+* Use `Annotated[StateSchema, InjectedState]` for agent state
 
 
-=== "In a workflow"
+!!! tip 
+
+    These annotations prevent LLMs from attempting to fill in the values. These parameters will be **hidden** from the LLM.
+
+=== "Using config"
 
     ```python
-    from typing_extensions import TypedDict
-    from langchain_core.messages import AnyMessage
-    from langgraph.graph import StateGraph
+    def get_user_info(
+        # highlight-next-line
+        config: RunnableConfig,
+    ) -> str:
+        """Look up user info."""
+        # highlight-next-line
+        user_id = config["configurable"].get("user_id")
+        return "User is John Smith" if user_id == "user_123" else "Unknown user"
 
-    # highlight-next-line
-    class CustomState(TypedDict): # (1)!
-        messages: list[AnyMessage]
-        extra_field: int
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_user_info],
+    )
 
-    # highlight-next-line
-    def node(state: CustomState): # (2)!
-        messages = state["messages"]
-        ...
-        return { # (3)!
-            # highlight-next-line
-            "extra_field": state["extra_field"] + 1
-        }
-
-    builder = StateGraph(State)
-    builder.add_node(node)
-    builder.set_entry_point("node")
-    graph = builder.compile()
+    agent.invoke(
+        {"messages": [{"role": "user", "content": "look up user information"}]},
+        # highlight-next-line
+        config={"configurable": {"user_id": "user_123"}}
+    )
     ```
-    
-    1. Define a custom state
-    2. Access the state in any node or tool
-    3. The Graph API is designed to work as easily as possible with state. The return value of a node represents a requested update to the state.
 
+=== "Using State"
 
-!!! tip "Turning on memory"
+    ```python
+    from typing import Annotated
+    from langgraph.prebuilt import InjectedState
 
-    Please see the [memory guide](../how-tos/memory/add-memory.md) for more details on how to enable memory. This is a powerful feature that allows you to persist the agent's state across multiple invocations. Otherwise, the state is scoped only to a single run.
+    class CustomState(AgentState):
+        # highlight-next-line
+        user_id: str
 
-### Long-term memory (cross-conversation context)
+    def get_user_info(
+        # highlight-next-line
+        state: Annotated[CustomState, InjectedState]
+    ) -> str:
+        """Look up user info."""
+        # highlight-next-line
+        user_id = state["user_id"]
+        return "User is John Smith" if user_id == "user_123" else "Unknown user"
 
-For context that spans *across* conversations or sessions, LangGraph allows access to **long-term memory** via a `store`. This can be used to read or update persistent facts (e.g., user profiles, preferences, prior interactions). 
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_user_info],
+        # highlight-next-line
+        state_schema=CustomState,
+    )
 
-For more information, see the [Memory guide](../how-tos/memory/add-memory.md).
+    agent.invoke({
+        "messages": "look up user information",
+        # highlight-next-line
+        "user_id": "user_123"
+    })
+    ```
+
+### Update Context from Tools
+
+Tools can update agent's context (state and long-term memory) during execution. This is useful for persisting intermediate results or making information accessible to subsequent tools or prompts. See [Memory](./memory.md#read-short-term) guide for more information.

docs/docs/agents/deployment.md

@@ -0,0 +1,92 @@
+---
+search:
+  boost: 2
+tags:
+  - agent
+hide:
+  - tags
+---
+
+# Deployment
+
+To deploy your LangGraph agent, create and configure a LangGraph app. This setup supports both local development and production deployments.
+
+Features: 
+
+* 🖥️ Local server for development
+* 🧩 Studio Web UI for visual debugging
+* ☁️ Cloud and 🔧 self-hosted deployment options
+* 📊 LangSmith integration for tracing and observability
+
+!!! info "Requirements" 
+
+    - ✅ You **must** have a [LangSmith account](https://www.langchain.com/langsmith). You can sign up for **free** and get started with the free tier.
+
+## Create a LangGraph app
+
+```bash
+pip install -U "langgraph-cli[inmem]"
+langgraph new path/to/your/app --template new-langgraph-project-python
+```
+
+This will create an empty LangGraph project. You can modify it by replacing the code in `src/agent/graph.py` with your agent code. For example:
+
+```python
+from langgraph.prebuilt import create_react_agent
+
+def get_weather(city: str) -> str:
+    """Get weather for a given city."""
+    return f"It's always sunny in {city}!"
+
+graph = create_react_agent(
+    model="anthropic:claude-3-7-sonnet-latest",
+    tools=[get_weather],
+    prompt="You are a helpful assistant"
+)
+```
+
+### Install dependencies
+
+In the root of your new LangGraph app, install the dependencies in `edit` mode so your local changes are used by the server:
+
+```shell
+pip install -e .
+```
+
+### Create an `.env` file
+
+You will find a `.env.example` in the root of your new LangGraph app. Create
+a `.env` file in the root of your new LangGraph app and copy the contents of the `.env.example` file into it, filling in the necessary API keys:
+
+```bash
+LANGSMITH_API_KEY=lsv2...
+ANTHROPIC_API_KEY=sk-
+```
+
+## Launch LangGraph server locally
+
+```shell
+langgraph dev
+```
+
+This will start up the LangGraph API server locally. If this runs successfully, you should see something like:
+
+>    Ready!
+> 
+>    - API: [http://localhost:2024](http://localhost:2024/)
+>     
+>    - Docs: http://localhost:2024/docs
+>     
+>    - LangGraph Studio Web UI: https://smith.langchain.com/studio/?baseUrl=http://127.0.0.1:2024
+
+See this [tutorial](https://langchain-ai.github.io/langgraph/tutorials/langgraph-platform/local-server/) to learn more about running LangGraph app locally.
+
+## LangGraph Studio Web UI
+
+LangGraph Studio Web is a specialized UI that you can connect to LangGraph API server to enable visualization, interaction, and debugging of your application locally. Test your graph in the LangGraph Studio Web UI by visiting the URL provided in the output of the `langgraph dev` command.
+
+>    - LangGraph Studio Web UI: https://smith.langchain.com/studio/?baseUrl=http://127.0.0.1:2024
+
+## Deployment
+
+Once your LangGraph app is running locally, you can deploy it using LangGraph Platform. Refer to the [deployment options guide](../tutorials/deployment.md) for detailed instructions on all supported deployment models.

docs/docs/agents/human-in-the-loop.md

@@ -0,0 +1,238 @@
+---
+search:
+  boost: 2
+tags:
+  - human-in-the-loop
+  - hil
+  - agent
+hide:
+  - tags
+---
+
+# Human-in-the-loop
+
+To review, edit and approve tool calls in an agent you can use LangGraph's built-in [Human-In-the-Loop (HIL)](../concepts/human_in_the_loop.md) features, specifically the [`interrupt()`][langgraph.types.interrupt] primitive.
+
+LangGraph allows you to pause execution **indefinitely** — for minutes, hours, or even days—until human input is received.
+
+This is possible because the agent state is **checkpointed into a database**, which allows the system to persist execution context and later resume the workflow, continuing from where it left off.
+
+For a deeper dive into the **human-in-the-loop** concept, see the [concept guide](../concepts/human_in_the_loop.md).
+
+<figure markdown="1">
+![image](../concepts/img/human_in_the_loop/tool-call-review.png){: style="max-height:400px"}
+<figcaption>
+A human can review and edit the output from the agent before proceeding. This is particularly critical in applications where the tool calls requested may be sensitive or require human oversight.
+</figcaption>
+</figure>
+
+
+## Review tool calls
+
+To add a human approval step to a tool:
+
+1. Use `interrupt()` in the tool to pause execution.
+2. Resume with a `Command(resume=...)` to continue based on human input.
+
+```python
+from langgraph.checkpoint.memory import InMemorySaver
+from langgraph.types import interrupt
+from langgraph.prebuilt import create_react_agent
+
+# An example of a sensitive tool that requires human review / approval
+def book_hotel(hotel_name: str):
+    """Book a hotel"""
+    # highlight-next-line
+    response = interrupt(  # (1)!
+        f"Trying to call `book_hotel` with args {{'hotel_name': {hotel_name}}}. "
+        "Please approve or suggest edits."
+    )
+    if response["type"] == "accept":
+        pass
+    elif response["type"] == "edit":
+        hotel_name = response["args"]["hotel_name"]
+    else:
+        raise ValueError(f"Unknown response type: {response['type']}")
+    return f"Successfully booked a stay at {hotel_name}."
+
+# highlight-next-line
+checkpointer = InMemorySaver() # (2)!
+
+agent = create_react_agent(
+    model="anthropic:claude-3-5-sonnet-latest",
+    tools=[book_hotel],
+    # highlight-next-line
+    checkpointer=checkpointer, # (3)!
+)
+```
+
+1. The [`interrupt` function][langgraph.types.interrupt] pauses the agent graph at a specific node. In this case, we call `interrupt()` at the beginning of the tool function, which pauses the graph at the node that executes the tool. The information inside `interrupt()` (e.g., tool calls) can be presented to a human, and the graph can be resumed with the user input (tool call approval, edit or feedback).
+2. The `InMemorySaver` is used to store the agent state at every step in the tool calling loop. This enables [short-term memory](./memory.md#short-term-memory) and [human-in-the-loop](./human-in-the-loop.md) capabilities. In this example, we use `InMemorySaver` to store the agent state in memory. In a production application, the agent state will be stored in a database.
+3. Initialize the agent with the `checkpointer`.
+
+Run the agent with the `stream()` method, passing the `config` object to specify the thread ID. This allows the agent to resume the same conversation on future invocations.
+
+```python
+config = {
+   "configurable": {
+      # highlight-next-line
+      "thread_id": "1"
+   }
+}
+
+for chunk in agent.stream(
+    {"messages": [{"role": "user", "content": "book a stay at McKittrick hotel"}]},
+    # highlight-next-line
+    config
+):
+    print(chunk)
+    print("\n")
+```
+
+> You should see that the agent runs until it reaches the `interrupt()` call, at which point it pauses and waits for human input.
+
+Resume the agent with a `Command(resume=...)` to continue based on human input.
+
+```python
+from langgraph.types import Command
+
+for chunk in agent.stream(
+    # highlight-next-line
+    Command(resume={"type": "accept"}),  # (1)!
+    # Command(resume={"type": "edit", "args": {"hotel_name": "McKittrick Hotel"}}),
+    config
+):
+    print(chunk)
+    print("\n")
+```
+
+1. The [`interrupt` function][langgraph.types.interrupt] is used in conjunction with the [`Command`][langgraph.types.Command] object to resume the graph with a value provided by the human.
+
+## Using with Agent Inbox
+
+You can create a wrapper to add interrupts to *any* tool. 
+
+The example below provides a reference implementation compatible with [Agent Inbox UI](https://github.com/langchain-ai/agent-inbox) and [Agent Chat UI](https://github.com/langchain-ai/agent-chat-ui).
+
+```python title="Wrapper that adds human-in-the-loop to any tool"
+from typing import Callable
+from langchain_core.tools import BaseTool, tool as create_tool
+from langchain_core.runnables import RunnableConfig
+from langgraph.types import interrupt 
+from langgraph.prebuilt.interrupt import HumanInterruptConfig, HumanInterrupt
+
+def add_human_in_the_loop(
+    tool: Callable | BaseTool,
+    *,
+    interrupt_config: HumanInterruptConfig = None,
+) -> BaseTool:
+    """Wrap a tool to support human-in-the-loop review.""" 
+    if not isinstance(tool, BaseTool):
+        tool = create_tool(tool)
+
+    if interrupt_config is None:
+        interrupt_config = {
+            "allow_accept": True,
+            "allow_edit": True,
+            "allow_respond": True,
+        }
+
+    @create_tool(  # (1)!
+        tool.name,
+        description=tool.description,
+        args_schema=tool.args_schema
+    )
+    def call_tool_with_interrupt(config: RunnableConfig, **tool_input):
+        request: HumanInterrupt = {
+            "action_request": {
+                "action": tool.name,
+                "args": tool_input
+            },
+            "config": interrupt_config,
+            "description": "Please review the tool call"
+        }
+        # highlight-next-line
+        response = interrupt([request])[0]  # (2)!
+        # approve the tool call
+        if response["type"] == "accept":
+            tool_response = tool.invoke(tool_input, config)
+        # update tool call args
+        elif response["type"] == "edit":
+            tool_input = response["args"]["args"]
+            tool_response = tool.invoke(tool_input, config)
+        # respond to the LLM with user feedback
+        elif response["type"] == "response":
+            user_feedback = response["args"]
+            tool_response = user_feedback
+        else:
+            raise ValueError(f"Unsupported interrupt response type: {response['type']}")
+
+        return tool_response
+
+    return call_tool_with_interrupt
+```
+
+1. This wrapper creates a new tool that calls `interrupt()` **before** executing the wrapped tool.
+2. `interrupt()` is using special input and output format that's expected by [Agent Inbox UI](https://github.com/langchain-ai/agent-inbox):
+    - a list of [`HumanInterrupt`][langgraph.prebuilt.interrupt.HumanInterrupt] objects is sent to `AgentInbox` render interrupt information to the end user
+    - resume value is provided by `AgentInbox` as a list (i.e., `Command(resume=[...])`)
+
+You can use the `add_human_in_the_loop` wrapper to add `interrupt()` to any tool without having to add it *inside* the tool:
+
+```python
+from langgraph.checkpoint.memory import InMemorySaver
+from langgraph.prebuilt import create_react_agent
+
+# highlight-next-line
+checkpointer = InMemorySaver()
+
+def book_hotel(hotel_name: str):
+   """Book a hotel"""
+   return f"Successfully booked a stay at {hotel_name}."
+
+
+agent = create_react_agent(
+    model="anthropic:claude-3-5-sonnet-latest",
+    tools=[
+        # highlight-next-line
+        add_human_in_the_loop(book_hotel), # (1)!
+    ],
+    # highlight-next-line
+    checkpointer=checkpointer,
+)
+
+config = {"configurable": {"thread_id": "1"}}
+
+# Run the agent
+for chunk in agent.stream(
+    {"messages": [{"role": "user", "content": "book a stay at McKittrick hotel"}]},
+    # highlight-next-line
+    config
+):
+    print(chunk)
+    print("\n")
+```
+
+1. The `add_human_in_the_loop` wrapper is used to add `interrupt()` to the tool. This allows the agent to pause execution and wait for human input before proceeding with the tool call.
+
+> You should see that the agent runs until it reaches the `interrupt()` call, 
+>  at which point it pauses and waits for human input.
+
+Resume the agent with a `Command(resume=...)`  to continue based on human input.
+
+```python
+from langgraph.types import Command 
+
+for chunk in agent.stream(
+    # highlight-next-line
+    Command(resume=[{"type": "accept"}]),
+    # Command(resume=[{"type": "edit", "args": {"args": {"hotel_name": "McKittrick Hotel"}}}]),
+    config
+):
+    print(chunk)
+    print("\n")
+```
+
+## Additional resources
+
+* [Human-in-the-loop in LangGraph](../concepts/human_in_the_loop.md)

docs/docs/agents/mcp.md

@@ -7,7 +7,7 @@ hide:
   - tags
 ---
 
-# Use MCP
+# MCP Integration
 
 [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) is an open protocol that standardizes how applications provide tools and context to language models. LangGraph agents can use tools defined on MCP servers through the `langchain-mcp-adapters` library.
 
@@ -23,91 +23,41 @@ pip install langchain-mcp-adapters
 
 The `langchain-mcp-adapters` package enables agents to use tools defined across one or more MCP servers.
 
+```python title="Agent using tools defined on MCP servers"
+# highlight-next-line
+from langchain_mcp_adapters.client import MultiServerMCPClient
+from langgraph.prebuilt import create_react_agent
 
-=== "In an agent"
-
-    ```python title="Agent using tools defined on MCP servers"
-    # highlight-next-line
-    from langchain_mcp_adapters.client import MultiServerMCPClient
-    from langgraph.prebuilt import create_react_agent
-
-    # highlight-next-line
-    client = MultiServerMCPClient(
-        {
-            "math": {
-                "command": "python",
-                # Replace with absolute path to your math_server.py file
-                "args": ["/path/to/math_server.py"],
-                "transport": "stdio",
-            },
-            "weather": {
-                # Ensure you start your weather server on port 8000
-                "url": "http://localhost:8000/mcp",
-                "transport": "streamable_http",
-            }
+# highlight-next-line
+client = MultiServerMCPClient(
+    {
+        "math": {
+            "command": "python",
+            # Replace with absolute path to your math_server.py file
+            "args": ["/path/to/math_server.py"],
+            "transport": "stdio",
+        },
+        "weather": {
+            # Ensure you start your weather server on port 8000
+            "url": "http://localhost:8000/mcp",
+            "transport": "streamable_http",
         }
-    )
+    }
+)
+# highlight-next-line
+tools = await client.get_tools()
+agent = create_react_agent(
+    "anthropic:claude-3-7-sonnet-latest",
     # highlight-next-line
-    tools = await client.get_tools()
-    agent = create_react_agent(
-        "anthropic:claude-3-7-sonnet-latest",
-        # highlight-next-line
-        tools
-    )
-    math_response = await agent.ainvoke(
-        {"messages": [{"role": "user", "content": "what's (3 + 5) x 12?"}]}
-    )
-    weather_response = await agent.ainvoke(
-        {"messages": [{"role": "user", "content": "what is the weather in nyc?"}]}
-    )
-    ```
-
-=== "In a workflow"
-
-    ```python
-    from langchain_mcp_adapters.client import MultiServerMCPClient
-    from langgraph.graph import StateGraph, MessagesState, START
-    from langgraph.prebuilt import ToolNode, tools_condition
-
-    from langchain.chat_models import init_chat_model
-    model = init_chat_model("openai:gpt-4.1")
-
-    client = MultiServerMCPClient(
-        {
-            "math": {
-                "command": "python",
-                # Make sure to update to the full absolute path to your math_server.py file
-                "args": ["./examples/math_server.py"],
-                "transport": "stdio",
-            },
-            "weather": {
-                # make sure you start your weather server on port 8000
-                "url": "http://localhost:8000/mcp/",
-                "transport": "streamable_http",
-            }
-        }
-    )
-    tools = await client.get_tools()
-
-    def call_model(state: MessagesState):
-        response = model.bind_tools(tools).invoke(state["messages"])
-        return {"messages": response}
-
-    builder = StateGraph(MessagesState)
-    builder.add_node(call_model)
-    builder.add_node(ToolNode(tools))
-    builder.add_edge(START, "call_model")
-    builder.add_conditional_edges(
-        "call_model",
-        tools_condition,
-    )
-    builder.add_edge("tools", "call_model")
-    graph = builder.compile()
-    math_response = await graph.ainvoke({"messages": "what's (3 + 5) x 12?"})
-    weather_response = await graph.ainvoke({"messages": "what is the weather in nyc?"})
-    ```
-
-
+    tools
+)
+math_response = await agent.ainvoke(
+    {"messages": [{"role": "user", "content": "what's (3 + 5) x 12?"}]}
+)
+weather_response = await agent.ainvoke(
+    {"messages": [{"role": "user", "content": "what is the weather in nyc?"}]}
+)
+```
 
 ## Custom MCP servers
 
@@ -157,4 +107,3 @@ if __name__ == "__main__":
 
 - [MCP documentation](https://modelcontextprotocol.io/introduction)
 - [MCP Transport documentation](https://modelcontextprotocol.io/docs/concepts/transports)
-- [langchain_mcp_adapters](https://github.com/langchain-ai/langchain-mcp-adapters)

docs/docs/agents/memory.md

@@ -0,0 +1,423 @@
+---
+search:
+  boost: 2
+tags:
+  - agent
+hide:
+  - tags
+---
+
+# Memory
+
+LangGraph supports two types of memory essential for building conversational agents:
+
+- **[Short-term memory](#short-term-memory)**: Tracks the ongoing conversation by maintaining message history within a session.
+- **[Long-term memory](#long-term-memory)**: Stores user-specific or application-level data across sessions.
+
+This guide demonstrates how to use both memory types with agents in LangGraph. For a deeper
+understanding of memory concepts, refer to the [LangGraph memory documentation](../concepts/memory.md).
+
+<figure markdown="1">
+![image](./assets/memory.png){: style="max-height:400px"}
+<figcaption>Both <strong>short-term</strong> and <strong>long-term</strong> memory require persistent storage to maintain continuity across LLM interactions. In production environments, this data is typically stored in a database.</figcaption>
+</figure>
+
+!!! note "Terminology"
+
+    In LangGraph:
+
+    - *Short-term memory* is also referred to as **thread-level memory**.
+    - *Long-term memory* is also called **cross-thread memory**.
+
+    A [thread](../concepts/persistence.md#threads) represents a sequence of related runs
+    grouped by the same `thread_id`.
+
+## Short-term memory
+
+Short-term memory enables agents to track multi-turn conversations. To use it, you must:
+
+1. Provide a `checkpointer` when creating the agent. The `checkpointer` enables [persistence](../concepts/persistence.md) of the agent's state.
+2. Supply a `thread_id` in the config when running the agent. The `thread_id` is a unique identifier for the conversation session.
+
+```python
+from langgraph.prebuilt import create_react_agent
+from langgraph.checkpoint.memory import InMemorySaver
+
+# highlight-next-line
+checkpointer = InMemorySaver() # (1)!
+
+
+def get_weather(city: str) -> str:
+    """Get weather for a given city."""
+    return f"It's always sunny in {city}!"
+
+
+agent = create_react_agent(
+    model="anthropic:claude-3-7-sonnet-latest",
+    tools=[get_weather],
+    # highlight-next-line
+    checkpointer=checkpointer # (2)!
+)
+
+# Run the agent
+config = {
+    "configurable": {
+        # highlight-next-line
+        "thread_id": "1"  # (3)!
+    }
+}
+
+sf_response = agent.invoke(
+    {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+    # highlight-next-line
+    config
+)
+
+# Continue the conversation using the same thread_id
+ny_response = agent.invoke(
+    {"messages": [{"role": "user", "content": "what about new york?"}]},
+    # highlight-next-line
+    config # (4)!
+)
+```
+
+1. The `InMemorySaver` is a checkpointer that stores the agent's state in memory. In a production setting, you would typically use a database or other persistent storage. Please review the [checkpointer documentation](../reference/checkpoints.md) for more options. If you're deploying with **LangGraph Platform**, the platform will provide a production-ready checkpointer for you.
+2. The `checkpointer` is passed to the agent. This enables the agent to persist its state across invocations.
+3. A unique `thread_id` is provided in the config. This ID is used to identify the conversation session. The value is controlled by the user and can be any string.
+4. The agent will continue the conversation using the same `thread_id`. This will allow the agent to infer that the user is asking specifically about the **weather** in New York. 
+
+When the agent is invoked the second time with the same `thread_id`, the original message history from the first conversation is automatically included, allowing the agent to infer that the user is asking specifically about the **weather** in New York.
+
+!!! Note "LangGraph Platform provides a production-ready checkpointer"
+
+    If you're using [LangGraph Platform](./deployment.md), during deployment your checkpointer will be automatically configured to use a production-ready database.
+
+### Manage message history
+
+Long conversations can exceed the LLM's context window. Common solutions are:
+
+* [Summarization](#summarize-message-history): Maintain a running summary of the conversation
+* [Trimming](#trim-message-history): Remove first or last N messages in the history
+
+This allows the agent to keep track of the conversation without exceeding the LLM's context window.
+
+To manage message history, specify `pre_model_hook` — a function ([node](../concepts/low_level.md#nodes)) that will always run before calling the language model.
+
+#### Summarize message history
+
+<figure markdown="1">
+![image](./assets/summary.png){: style="max-height:400px"}
+<figcaption>Long conversations can exceed the LLM's context window. A common solution is to maintain a running summary of the conversation. This allows the agent to keep track of the conversation without exceeding the LLM's context window.
+</figcaption>
+</figure>
+
+To summarize message history, you can use [`pre_model_hook`][langgraph.prebuilt.chat_agent_executor.create_react_agent] with a prebuilt [`SummarizationNode`](https://langchain-ai.github.io/langmem/reference/short_term/#langmem.short_term.SummarizationNode):
+
+```python
+from langchain_anthropic import ChatAnthropic
+from langmem.short_term import SummarizationNode
+from langchain_core.messages.utils import count_tokens_approximately
+from langgraph.prebuilt import create_react_agent
+from langgraph.prebuilt.chat_agent_executor import AgentState
+from langgraph.checkpoint.memory import InMemorySaver
+from typing import Any
+
+model = ChatAnthropic(model="claude-3-7-sonnet-latest")
+
+summarization_node = SummarizationNode( # (1)!
+    token_counter=count_tokens_approximately,
+    model=model,
+    max_tokens=384,
+    max_summary_tokens=128,
+    output_messages_key="llm_input_messages",
+)
+
+class State(AgentState):
+    # NOTE: we're adding this key to keep track of previous summary information
+    # to make sure we're not summarizing on every LLM call
+    # highlight-next-line
+    context: dict[str, Any]  # (2)!
+
+
+checkpointer = InMemorySaver() # (3)!
+
+agent = create_react_agent(
+    model=model,
+    tools=tools,
+    # highlight-next-line
+    pre_model_hook=summarization_node, # (4)!
+    # highlight-next-line
+    state_schema=State, # (5)!
+    checkpointer=checkpointer,
+)
+```
+
+1. The `InMemorySaver` is a checkpointer that stores the agent's state in memory. In a production setting, you would typically use a database or other persistent storage. Please review the [checkpointer documentation](../reference/checkpoints.md) for more options. If you're deploying with **LangGraph Platform**, the platform will provide a production-ready checkpointer for you.
+2. The `context` key is added to the agent's state. The key contains book-keeping information for the summarization node. It is used to keep track of the last summary information and ensure that the agent doesn't summarize on every LLM call, which can be inefficient.
+3. The `checkpointer` is passed to the agent. This enables the agent to persist its state across invocations.
+4. The `pre_model_hook` is set to the `SummarizationNode`. This node will summarize the message history before sending it to the LLM. The summarization node will automatically handle the summarization process and update the agent's state with the new summary. You can replace this with a custom implementation if you prefer. Please see the [create_react_agent][langgraph.prebuilt.chat_agent_executor.create_react_agent] API reference for more details.
+5. The `state_schema` is set to the `State` class, which is the custom state that contains an extra `context` key.
+
+#### Trim message history
+
+To trim message history, you can use [`pre_model_hook`][langgraph.prebuilt.chat_agent_executor.create_react_agent] with [`trim_messages`](https://python.langchain.com/api_reference/core/messages/langchain_core.messages.utils.trim_messages.html) function:
+
+```python
+# highlight-next-line
+from langchain_core.messages.utils import (
+    # highlight-next-line
+    trim_messages,
+    # highlight-next-line
+    count_tokens_approximately
+# highlight-next-line
+)
+from langgraph.prebuilt import create_react_agent
+
+# This function will be called every time before the node that calls LLM
+def pre_model_hook(state):
+    trimmed_messages = trim_messages(
+        state["messages"],
+        strategy="last",
+        token_counter=count_tokens_approximately,
+        max_tokens=384,
+        start_on="human",
+        end_on=("human", "tool"),
+    )
+    # highlight-next-line
+    return {"llm_input_messages": trimmed_messages}
+
+checkpointer = InMemorySaver()
+agent = create_react_agent(
+    model,
+    tools,
+    # highlight-next-line
+    pre_model_hook=pre_model_hook,
+    checkpointer=checkpointer,
+)
+```
+
+To learn more about using `pre_model_hook` for managing message history, see this [how-to guide](../how-tos/create-react-agent-manage-message-history.ipynb)
+
+### Read in tools { #read-short-term }
+
+LangGraph allows agent to access its short-term memory (state) inside the tools.
+
+```python
+from typing import Annotated
+from langgraph.prebuilt import InjectedState, create_react_agent
+
+class CustomState(AgentState):
+    # highlight-next-line
+    user_id: str
+
+def get_user_info(
+    # highlight-next-line
+    state: Annotated[CustomState, InjectedState]
+) -> str:
+    """Look up user info."""
+    # highlight-next-line
+    user_id = state["user_id"]
+    return "User is John Smith" if user_id == "user_123" else "Unknown user"
+
+agent = create_react_agent(
+    model="anthropic:claude-3-7-sonnet-latest",
+    tools=[get_user_info],
+    # highlight-next-line
+    state_schema=CustomState,
+)
+
+agent.invoke({
+    "messages": "look up user information",
+    # highlight-next-line
+    "user_id": "user_123"
+})
+```
+
+See the [Context](./context.md#__tabbed_2_2) guide for more information.
+
+### Write from tools { #write-short-term }
+
+To modify the agent's short-term memory (state) during execution, you can return state updates directly from the tools. This is useful for persisting intermediate results or making information accessible to subsequent tools or prompts.
+
+```python
+from typing import Annotated
+from langchain_core.tools import InjectedToolCallId
+from langchain_core.runnables import RunnableConfig
+from langchain_core.messages import ToolMessage
+from langgraph.prebuilt import InjectedState, create_react_agent
+from langgraph.prebuilt.chat_agent_executor import AgentState
+from langgraph.types import Command
+
+class CustomState(AgentState):
+    # highlight-next-line
+    user_name: str
+
+def update_user_info(
+    tool_call_id: Annotated[str, InjectedToolCallId],
+    config: RunnableConfig
+) -> Command:
+    """Look up and update user info."""
+    user_id = config["configurable"].get("user_id")
+    name = "John Smith" if user_id == "user_123" else "Unknown user"
+    # highlight-next-line
+    return Command(update={
+        # highlight-next-line
+        "user_name": name,
+        # update the message history
+        "messages": [
+            ToolMessage(
+                "Successfully looked up user information",
+                tool_call_id=tool_call_id
+            )
+        ]
+    })
+
+def greet(
+    # highlight-next-line
+    state: Annotated[CustomState, InjectedState]
+) -> str:
+    """Use this to greet the user once you found their info."""
+    user_name = state["user_name"]
+    return f"Hello {user_name}!"
+
+agent = create_react_agent(
+    model="anthropic:claude-3-7-sonnet-latest",
+    tools=[update_user_info, greet],
+    # highlight-next-line
+    state_schema=CustomState
+)
+
+agent.invoke(
+    {"messages": [{"role": "user", "content": "greet the user"}]},
+    # highlight-next-line
+    config={"configurable": {"user_id": "user_123"}}
+)
+```
+
+For more details, see [how to update state from tools](../how-tos/tool-calling.ipynb#update).
+
+## Long-term memory
+
+Use long-term memory to store user-specific or application-specific data across conversations. This is useful for applications like chatbots, where you want to remember user preferences or other information.
+
+To use long-term memory, you need to:
+
+1. [Configure a store](../how-tos/persistence.ipynb#add-long-term-memory) to persist data across invocations.
+2. Use the [`get_store`][langgraph.config.get_store] function to access the store from within tools or prompts.
+
+### Read { #read-long-term }
+
+```python title="A tool the agent can use to look up user information"
+from langchain_core.runnables import RunnableConfig
+from langgraph.config import get_store
+from langgraph.prebuilt import create_react_agent
+from langgraph.store.memory import InMemoryStore
+
+# highlight-next-line
+store = InMemoryStore() # (1)!
+
+# highlight-next-line
+store.put(  # (2)!
+    ("users",),  # (3)!
+    "user_123",  # (4)!
+    {
+        "name": "John Smith",
+        "language": "English",
+    } # (5)!
+)
+
+def get_user_info(config: RunnableConfig) -> str:
+    """Look up user info."""
+    # Same as that provided to `create_react_agent`
+    # highlight-next-line
+    store = get_store() # (6)!
+    user_id = config["configurable"].get("user_id")
+    # highlight-next-line
+    user_info = store.get(("users",), user_id) # (7)!
+    return str(user_info.value) if user_info else "Unknown user"
+
+agent = create_react_agent(
+    model="anthropic:claude-3-7-sonnet-latest",
+    tools=[get_user_info],
+    # highlight-next-line
+    store=store # (8)!
+)
+
+# Run the agent
+agent.invoke(
+    {"messages": [{"role": "user", "content": "look up user information"}]},
+    # highlight-next-line
+    config={"configurable": {"user_id": "user_123"}}
+)
+```
+
+1. The `InMemoryStore` is a store that stores data in memory. In a production setting, you would typically use a database or other persistent storage. Please review the [store documentation](../reference/store.md) for more options. If you're deploying with **LangGraph Platform**, the platform will provide a production-ready store for you.
+2. For this example, we write some sample data to the store using the `put` method. Please see the [BaseStore.put][langgraph.store.base.BaseStore.put] API reference for more details.
+3. The first argument is the namespace. This is used to group related data together. In this case, we are using the `users` namespace to group user data.
+4. A key within the namespace. This example uses a user ID for the key.
+5. The data that we want to store for the given user.
+6. The `get_store` function is used to access the store. You can call it from anywhere in your code, including tools and prompts. This function returns the store that was passed to the agent when it was created.
+7. The `get` method is used to retrieve data from the store. The first argument is the namespace, and the second argument is the key. This will return a `StoreValue` object, which contains the value and metadata about the value.
+8. The `store` is passed to the agent. This enables the agent to access the store when running tools. You can also use the `get_store` function to access the store from anywhere in your code.
+
+### Write { #write-long-term }
+
+```python title="Example of a tool that updates user information"
+from typing_extensions import TypedDict
+
+from langgraph.config import get_store
+from langgraph.prebuilt import create_react_agent
+from langgraph.store.memory import InMemoryStore
+
+store = InMemoryStore() # (1)!
+
+class UserInfo(TypedDict): # (2)!
+    name: str
+
+def save_user_info(user_info: UserInfo, config: RunnableConfig) -> str: # (3)!
+    """Save user info."""
+    # Same as that provided to `create_react_agent`
+    # highlight-next-line
+    store = get_store() # (4)!
+    user_id = config["configurable"].get("user_id")
+    # highlight-next-line
+    store.put(("users",), user_id, user_info) # (5)!
+    return "Successfully saved user info."
+
+agent = create_react_agent(
+    model="anthropic:claude-3-7-sonnet-latest",
+    tools=[save_user_info],
+    # highlight-next-line
+    store=store
+)
+
+# Run the agent
+agent.invoke(
+    {"messages": [{"role": "user", "content": "My name is John Smith"}]},
+    # highlight-next-line
+    config={"configurable": {"user_id": "user_123"}} # (6)!
+)
+
+# You can access the store directly to get the value
+store.get(("users",), "user_123").value
+```
+
+1. The `InMemoryStore` is a store that stores data in memory. In a production setting, you would typically use a database or other persistent storage. Please review the [store documentation](../reference/store.md) for more options. If you're deploying with **LangGraph Platform**, the platform will provide a production-ready store for you.
+2. The `UserInfo` class is a `TypedDict` that defines the structure of the user information. The LLM will use this to format the response according to the schema.
+3. The `save_user_info` function is a tool that allows an agent to update user information. This could be useful for a chat application where the user wants to update their profile information.
+4. The `get_store` function is used to access the store. You can call it from anywhere in your code, including tools and prompts. This function returns the store that was passed to the agent when it was created.
+5. The `put` method is used to store data in the store. The first argument is the namespace, and the second argument is the key. This will store the user information in the store.
+6. The `user_id` is passed in the config. This is used to identify the user whose information is being updated.
+
+### Semantic search
+
+LangGraph also allows you to [search](https://langchain-ai.github.io/langgraph/how-tos/memory/semantic-search/#using-in-create-react-agent) for items in long-term memory by semantic similarity.
+
+### Prebuilt memory tools
+
+**LangMem** is a LangChain-maintained library that offers tools for managing long-term memories in your agent. See the [LangMem documentation](https://langchain-ai.github.io/langmem/) for usage examples.
+
+
+## Additional resources
+
+* [Memory in LangGraph](../concepts/memory.md)

docs/docs/agents/models.md

@@ -1,78 +1,233 @@
+---
+search:
+  boost: 2
+tags:
+  - anthropic
+  - openai
+  - agent
+hide:
+  - tags
+---
+
 # Models
 
-LangGraph provides built-in support for [LLMs (language models)](https://python.langchain.com/docs/concepts/chat_models/) via the LangChain library. This makes it easy to integrate various LLMs into your agents and workflows.
+This page describes how to configure the chat model used by an agent.
+
+## Tool calling support
+
+To enable tool-calling agents, the underlying LLM must support [tool calling](https://python.langchain.com/docs/concepts/tool_calling/).
+
+Compatible models can be found in the [LangChain integrations directory](https://python.langchain.com/docs/integrations/chat/).
+
+## Specifying a model by name
+
+You can configure an agent with a model name string:
+
+=== "OpenAI"
+
+    ```python
+    import os
+    from langgraph.prebuilt import create_react_agent
+
+    os.environ["OPENAI_API_KEY"] = "sk-..."
+
+    agent = create_react_agent(
+        # highlight-next-line
+        model="openai:gpt-4.1",
+        # other parameters
+    )
+    ```
+
+=== "Anthropic"
+
+    ```python
+    import os
+    from langgraph.prebuilt import create_react_agent
+
+    os.environ["ANTHROPIC_API_KEY"] = "sk-..."
+
+    agent = create_react_agent(
+        # highlight-next-line
+        model="anthropic:claude-3-7-sonnet-latest",
+        # other parameters
+    )
+    ```
+
+=== "Azure"
+
+    ```python
+    import os
+    from langgraph.prebuilt import create_react_agent
+
+    os.environ["AZURE_OPENAI_API_KEY"] = "..."
+    os.environ["AZURE_OPENAI_ENDPOINT"] = "..."
+    os.environ["OPENAI_API_VERSION"] = "2025-03-01-preview"
+
+    agent = create_react_agent(
+        # highlight-next-line
+        model="azure_openai:gpt-4.1",
+        # other parameters
+    )
+    ```
+
+=== "Google Gemini"
+
+    ```python
+    import os
+    from langgraph.prebuilt import create_react_agent
+
+    os.environ["GOOGLE_API_KEY"] = "..."
+
+    agent = create_react_agent(
+        # highlight-next-line
+        model="google_genai:gemini-2.0-flash",
+        # other parameters
+    )
+    ```
+
+=== "AWS Bedrock"
+
+    ```python
+    from langgraph.prebuilt import create_react_agent
+
+    # Follow the steps here to configure your credentials:
+    # https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html
+
+    agent = create_react_agent(
+        # highlight-next-line
+        model="bedrock_converse:anthropic.claude-3-5-sonnet-20240620-v1:0",
+        # other parameters
+    )
+    ```
 
 
-## Initialize a model
+## Using `init_chat_model`
 
-Use [`init_chat_model`](https://python.langchain.com/docs/how_to/chat_models_universal_init/) to initialize models:
+The [`init_chat_model`](https://python.langchain.com/docs/how_to/chat_models_universal_init/) utility simplifies model initialization with configurable parameters:
 
-{!snippets/chat_model_tabs.md!}
+=== "OpenAI"
 
-### Instantiate a model directly
+    ```
+    pip install -U "langchain[openai]"
+    ```
+    ```python
+    import os
+    from langchain.chat_models import init_chat_model
+
+    os.environ["OPENAI_API_KEY"] = "sk-..."
+
+    model = init_chat_model(
+        "openai:gpt-4.1",
+        temperature=0,
+        # other parameters
+    )
+    ```
+
+=== "Anthropic"
+
+    ```
+    pip install -U "langchain[anthropic]"
+    ```
+    ```python
+    import os
+    from langchain.chat_models import init_chat_model
+
+    os.environ["ANTHROPIC_API_KEY"] = "sk-..."
+
+    model = init_chat_model(
+        "anthropic:claude-3-5-sonnet-latest",
+        temperature=0,
+        # other parameters
+    )
+    ```
+
+=== "Azure"
+
+    ```
+    pip install -U "langchain[openai]"
+    ```
+    ```python
+    import os
+    from langchain.chat_models import init_chat_model
+
+    os.environ["AZURE_OPENAI_API_KEY"] = "..."
+    os.environ["AZURE_OPENAI_ENDPOINT"] = "..."
+    os.environ["OPENAI_API_VERSION"] = "2025-03-01-preview"
+
+    model = init_chat_model(
+        "azure_openai:gpt-4.1",
+        azure_deployment=os.environ["AZURE_OPENAI_DEPLOYMENT_NAME"],
+        temperature=0,
+        # other parameters
+    )
+    ```
+
+=== "Google Gemini"
+
+    ```
+    pip install -U "langchain[google-genai]"
+    ```
+    ```python
+    import os
+    from langchain.chat_models import init_chat_model
+
+    os.environ["GOOGLE_API_KEY"] = "..."
+
+    model = init_chat_model(
+        "google_genai:gemini-2.0-flash",
+        temperature=0,
+        # other parameters
+    )
+    ```
+
+=== "AWS Bedrock"
+
+    ```
+    pip install -U "langchain[aws]"
+    ```
+    ```python
+    from langchain.chat_models import init_chat_model
+
+    # Follow the steps here to configure your credentials:
+    # https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html
+
+    model = init_chat_model(
+        "anthropic.claude-3-5-sonnet-20240620-v1:0",
+        model_provider="bedrock_converse",
+        temperature=0,
+        # other parameters
+    )
+    ```
+
+
+Refer to the [API reference](https://python.langchain.com/api_reference/langchain/chat_models/langchain.chat_models.base.init_chat_model.html) for advanced options.
+
+## Using provider-specific LLMs 
 
 If a model provider is not available via `init_chat_model`, you can instantiate the provider's model class directly. The model must implement the [BaseChatModel interface](https://python.langchain.com/api_reference/core/language_models/langchain_core.language_models.chat_models.BaseChatModel.html) and support tool calling:
 
-
 ```python
-# Anthropic is already supported by `init_chat_model`,
-# but you can also instantiate it directly.
 from langchain_anthropic import ChatAnthropic
+from langgraph.prebuilt import create_react_agent
 
 model = ChatAnthropic(
-  model="claude-3-7-sonnet-latest",
-  temperature=0,
-  max_tokens=2048
+    model="claude-3-7-sonnet-latest",
+    temperature=0,
+    max_tokens=2048
+)
+
+agent = create_react_agent(
+    # highlight-next-line
+    model=model,
+    # other parameters
 )
 ```
 
-!!! important "Tool calling support"
+!!! note "Illustrative example" 
 
-    If you are building an agent or workflow that requires the model to call external tools, ensure that the underlying
-    language model supports [tool calling](../concepts/tools.md). Compatible models can be found in the [LangChain integrations directory](https://python.langchain.com/docs/integrations/chat/).
+    The example above uses `ChatAnthropic`, which is already supported by `init_chat_model`. This pattern is shown to illustrate how to manually instantiate a model not available through init_chat_model.
 
-
-## Use in an agent
-
-When using `create_react_agent` you can specify the model by its name string, which is a shorthand for initializing the model using `init_chat_model`. This allows you to use the model without needing to import or instantiate it directly.
-
-=== "model name"
-
-
-      ```python
-      from langgraph.prebuilt import create_react_agent
-
-      create_react_agent(
-         # highlight-next-line
-         model="anthropic:claude-3-7-sonnet-latest",
-         # other parameters
-      )
-      ```
-
-=== "model instance"
-
-      ```python
-      from langchain_anthropic import ChatAnthropic
-      from langgraph.prebuilt import create_react_agent
-
-      model = ChatAnthropic(
-          model="claude-3-7-sonnet-latest",
-          temperature=0,
-          max_tokens=2048
-      )
-      # Alternatively
-      # model = init_chat_model("anthropic:claude-3-7-sonnet-latest")
-
-      agent = create_react_agent(
-        # highlight-next-line
-        model=model,
-        # other parameters
-      )
-      ```
-
-## Advanced model configuration
-
-### Disable streaming
+## Disable streaming
 
 To disable streaming of the individual LLM tokens, set `disable_streaming=True` when initializing the model:
 
@@ -102,7 +257,7 @@ To disable streaming of the individual LLM tokens, set `disable_streaming=True`
 
 Refer to the [API reference](https://python.langchain.com/api_reference/core/language_models/langchain_core.language_models.chat_models.BaseChatModel.html#langchain_core.language_models.chat_models.BaseChatModel.disable_streaming) for more information on `disable_streaming`
 
-### Add model fallbacks
+## Adding model fallbacks
 
 You can add a fallback to a different model or a different LLM provider using `model.with_fallbacks([...])`:
 
@@ -137,43 +292,7 @@ You can add a fallback to a different model or a different LLM provider using `m
 
 See this [guide](https://python.langchain.com/docs/how_to/fallbacks/#fallback-to-better-model) for more information on model fallbacks.
 
-### Use the built-in rate limiter
-
-Langchain includes a built-in in-memory rate limiter. This rate limiter is thread safe and can be shared by multiple threads in the same process.
-
-```python
-from langchain_core.rate_limiters import InMemoryRateLimiter
-from langchain_anthropic import ChatAnthropic
-
-rate_limiter = InMemoryRateLimiter(
-    requests_per_second=0.1,  # <-- Super slow! We can only make a request once every 10 seconds!!
-    check_every_n_seconds=0.1,  # Wake up every 100 ms to check whether allowed to make a request,
-    max_bucket_size=10,  # Controls the maximum burst size.
-)
-
-model = ChatAnthropic(
-   model_name="claude-3-opus-20240229", 
-   rate_limiter=rate_limiter
-)
-```
-
-See the LangChain docs for more information on how to [handle rate limiting](https://python.langchain.com/docs/how_to/chat_model_rate_limiting/).
-
-## Bring your own model
-
-If your desired LLM isn't officially supported by LangChain, consider these options:
-
-1. **Implement a custom LangChain chat model**: Create a model conforming to the [LangChain chat model interface](https://python.langchain.com/docs/how_to/custom_chat_model/). This enables full compatibility with LangGraph's agents and workflows but requires understanding of the LangChain framework.
-
-2. **Direct invocation with custom streaming**: Use your model directly by [adding custom streaming logic](../how-tos/streaming.md#use-with-any-llm) with `StreamWriter`.
-   Refer to the [custom streaming documentation](../how-tos/streaming.md#use-with-any-llm) for guidance. This approach suits custom workflows where prebuilt agent integration is not necessary.
-
- 
 ## Additional resources
 
-- [Multimodal inputs](https://python.langchain.com/docs/how_to/multimodal_inputs/)
-- [Structured outputs](https://python.langchain.com/docs/how_to/structured_output/)
 - [Model integration directory](https://python.langchain.com/docs/integrations/chat/)
-- [Force model to call a specific tool](https://python.langchain.com/docs/how_to/tool_choice/)
-- [All chat model how-to guides](https://python.langchain.com/docs/how_to/#chat-models)
-- [Chat model integrations](https://python.langchain.com/docs/integrations/chat/)
+- [Universal initialization with `init_chat_model`](https://python.langchain.com/docs/how_to/chat_models_universal_init/)

docs/docs/agents/overview.md

@@ -8,9 +8,9 @@ hide:
   - tags
 ---
 
-# Agent development using prebuilt components
+# Agent development with LangGraph
 
-LangGraph provides both low-level primitives and high-level prebuilt components for building agent-based applications. This section focuses on the prebuilt, ready-to-use components designed to help you construct agentic systems quickly and reliably—without the need to implement orchestration, memory, or human feedback handling from scratch.
+**LangGraph** provides both low-level primitives and high-level prebuilt components for building agent-based applications. This section focuses on the **prebuilt**, **reusable** components designed to help you construct agentic systems quickly and reliably—without the need to implement orchestration, memory, or human feedback handling from scratch.
 
 ## What is an agent?
 
@@ -27,12 +27,12 @@ The LLM operates in a loop. In each iteration, it selects a tool to invoke, prov
 
 LangGraph includes several capabilities essential for building robust, production-ready agentic systems:
 
-- [**Memory integration**](../how-tos/memory/add-memory.md): Native support for *short-term* (session-based) and *long-term* (persistent across sessions) memory, enabling stateful behaviors in chatbots and assistants.
-- [**Human-in-the-loop control**](../concepts/human_in_the_loop.md): Execution can pause *indefinitely* to await human feedback—unlike websocket-based solutions limited to real-time interaction. This enables asynchronous approval, correction, or intervention at any point in the workflow.
-- [**Streaming support**](../how-tos/streaming.md): Real-time streaming of agent state, model tokens, tool outputs, or combined streams.
+- [**Memory integration**](./memory.md): Native support for *short-term* (session-based) and *long-term* (persistent across sessions) memory, enabling stateful behaviors in chatbots and assistants.
+- [**Human-in-the-loop control**](./human-in-the-loop.md): Execution can pause *indefinitely* to await human feedback—unlike websocket-based solutions limited to real-time interaction. This enables asynchronous approval, correction, or intervention at any point in the workflow.
+- [**Streaming support**](./streaming.md): Real-time streaming of agent state, model tokens, tool outputs, or combined streams.
 - [**Deployment tooling**](./deployment.md): Includes infrastructure-free deployment tools. [**LangGraph Platform**](https://langchain-ai.github.io/langgraph/concepts/langgraph_platform/) supports testing, debugging, and deployment.
     - **[Studio](https://langchain-ai.github.io/langgraph/concepts/langgraph_studio/)**: A visual IDE for inspecting and debugging workflows.
-    - Supports multiple [**deployment options**](https://langchain-ai.github.io/langgraph/concepts/deployment_options.md) for production.
+    - Supports multiple [**deployment options**](https://langchain-ai.github.io/langgraph/tutorials/deployment/) for production.
 
 ## High-level building blocks
 
@@ -50,7 +50,7 @@ The high-level components are organized into several packages, each with a speci
 | `langgraph-supervisor`                     | Tools for building [**supervisor**](./multi-agent.md#supervisor) agents     | `pip install -U langgraph-supervisor`   |
 | `langgraph-swarm`                          | Tools for building a [**swarm**](./multi-agent.md#swarm) multi-agent system | `pip install -U langgraph-swarm`        |
 | `langchain-mcp-adapters`                   | Interfaces to [**MCP servers**](./mcp.md) for tool and resource integration | `pip install -U langchain-mcp-adapters` |
-| `langmem`                                  | Agent memory management: [**short-term and long-term**](../how-tos/memory/add-memory.md)        | `pip install -U langmem`                |
+| `langmem`                                  | Agent memory management: [**short-term and long-term**](./memory.md)        | `pip install -U langmem`                |
 | `agentevals`                               | Utilities to [**evaluate agent performance**](./evals.md)                   | `pip install -U agentevals`             |
 
 ## Visualize an agent graph

docs/docs/agents/prebuilt.md

@@ -1,10 +1,10 @@
 [//]: # (This file is automatically generated using a script in docs/_scripts. Do not edit this file directly!)
-# Community Agents
+# Community agents
 
 If you’re looking for other prebuilt libraries, explore the community-built options 
 below. These libraries can extend LangGraph's functionality in various ways.
 
-## 📚 Available Libraries
+## 📚 Available libraries
 
 [//]: # (This file is automatically generated using a script in docs/_scripts. Do not edit this file directly!)
 | Name | GitHub URL | Description | Weekly Downloads | Stars |
@@ -23,7 +23,7 @@ below. These libraries can extend LangGraph's functionality in various ways.
 | **langgraph-reflection** | [langchain-ai/langgraph-reflection](https://github.com/langchain-ai/langgraph-reflection) | LangGraph agent that runs a reflection step. | -12345 | ![GitHub stars](https://img.shields.io/github/stars/langchain-ai/langgraph-reflection?style=social)
 | **langgraph-codeact** | [langchain-ai/langgraph-codeact](https://github.com/langchain-ai/langgraph-codeact) | LangGraph implementation of CodeAct agent that generates and executes code instead of tool calling. | -12345 | ![GitHub stars](https://img.shields.io/github/stars/langchain-ai/langgraph-codeact?style=social)
 
-## ✨ Contributing Your Library
+## ✨ Contributing your library
 
 Have you built an awesome open-source library using LangGraph? We'd love to feature 
 your project on the official LangGraph documentation pages! 🏆

docs/docs/agents/run_agents.md

@@ -10,7 +10,7 @@ hide:
 # Running agents
 
 
-Agents support both synchronous and asynchronous execution using either `.invoke()` / `await .ainvoke()` for full responses, or `.stream()` / `.astream()` for **incremental** [streaming](../how-tos/streaming.md) output. This section explains how to provide input, interpret output, enable streaming, and control execution limits.
+Agents support both synchronous and asynchronous execution using either `.invoke()` / `await .ainvoke()` for full responses, or `.stream()` / `.astream()` for **incremental** [streaming](streaming.md) output. This section explains how to provide input, interpret output, enable streaming, and control execution limits.
 
 
 ## Basic usage
@@ -109,7 +109,7 @@ Streaming is available in both sync and async modes:
 
 !!! tip
 
-    For full details, see the [streaming guide](../how-tos/streaming.md).
+    For full details, see the [streaming guide](./streaming.md).
 
 ## Max iterations
 

docs/docs/agents/streaming.md

@@ -0,0 +1,223 @@
+---
+search:
+  boost: 2
+tags:
+  - agent
+hide:
+  - tags
+---
+
+# Streaming
+
+Streaming is key to building responsive applications. There are a few types of data you’ll want to stream:
+
+1. [**Agent progress**](#agent-progress) — get updates after each node in the agent graph is executed.
+2. [**LLM tokens**](#llm-tokens) — stream tokens as they are generated by the language model.
+3. [**Custom updates**](#tool-updates) — emit custom data from tools during execution (e.g., "Fetched 10/100 records")
+
+You can stream [more than one type of data](#stream-multiple-modes) at a time. 
+
+
+<figure markdown="1">
+![image](./assets/fast_parrot.png){: style="max-height:300px"}
+<figcaption>
+Waiting is for pigeons.
+</figcaption>
+</figure>
+
+## Agent progress
+
+To stream agent progress, use the [`stream()`][langgraph.graph.state.CompiledStateGraph.stream] or [`astream()`][langgraph.graph.state.CompiledStateGraph.astream] methods with [`stream_mode="updates"`](https://langchain-ai.github.io/langgraph/how-tos/streaming/#updates). This emits an event after every agent step.
+
+For example, if you have an agent that calls a tool once, you should see the following updates:
+
+* **LLM node**: AI message with tool call requests
+* **Tool node**: Tool message with execution result
+* **LLM node**: Final AI response
+
+=== "Sync"
+
+    ```python
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_weather],
+    )
+    # highlight-next-line
+    for chunk in agent.stream(
+        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        # highlight-next-line
+        stream_mode="updates"
+    ):
+        print(chunk)
+        print("\n")
+    ```
+
+=== "Async"
+
+    ```python
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_weather],
+    )
+    # highlight-next-line
+    async for chunk in agent.astream(
+        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        # highlight-next-line
+        stream_mode="updates"
+    ):
+        print(chunk)
+        print("\n")
+    ```
+
+## LLM tokens
+
+To stream tokens as they are produced by the LLM, use `stream_mode="messages"`:
+
+=== "Sync"
+
+    ```python
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_weather],
+    )
+    # highlight-next-line
+    for token, metadata in agent.stream(
+        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        # highlight-next-line
+        stream_mode="messages"
+    ):
+        print("Token", token)
+        print("Metadata", metadata)
+        print("\n")
+    ```
+
+=== "Async"
+
+    ```python
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_weather],
+    )
+    # highlight-next-line
+    async for token, metadata in agent.astream(
+        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        # highlight-next-line
+        stream_mode="messages"
+    ):
+        print("Token", token)
+        print("Metadata", metadata)
+        print("\n")
+    ```
+
+## Tool updates
+
+To stream updates from tools as they are executed, you can use [get_stream_writer][langgraph.config.get_stream_writer].
+
+=== "Sync"
+
+    ```python
+    # highlight-next-line
+    from langgraph.config import get_stream_writer
+
+    def get_weather(city: str) -> str:
+        """Get weather for a given city."""
+        # highlight-next-line
+        writer = get_stream_writer()
+        # stream any arbitrary data
+        # highlight-next-line
+        writer(f"Looking up data for city: {city}")
+        return f"It's always sunny in {city}!"
+
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_weather],
+    )
+
+    for chunk in agent.stream(
+        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        # highlight-next-line
+        stream_mode="custom"
+    ):
+        print(chunk)
+        print("\n")
+    ```
+
+=== "Async"
+
+    ```python
+    # highlight-next-line
+    from langgraph.config import get_stream_writer
+
+    def get_weather(city: str) -> str:
+        """Get weather for a given city."""
+        # highlight-next-line
+        writer = get_stream_writer()
+        # stream any arbitrary data
+        # highlight-next-line
+        writer(f"Looking up data for city: {city}")
+        return f"It's always sunny in {city}!"
+
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_weather],
+    )
+
+    async for chunk in agent.astream(
+        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        # highlight-next-line
+        stream_mode="custom"
+    ):
+        print(chunk)
+        print("\n")
+    ```
+
+!!! Note
+    If you add `get_stream_writer` inside your tool, you won't be able to invoke the tool outside of a LangGraph execution context. 
+
+## Stream multiple modes
+
+You can specify multiple streaming modes by passing stream mode as a list: `stream_mode=["updates", "messages", "custom"]`:
+
+=== "Sync"
+
+    ```python
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_weather],
+    )
+
+    for stream_mode, chunk in agent.stream(
+        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        # highlight-next-line
+        stream_mode=["updates", "messages", "custom"]
+    ):
+        print(chunk)
+        print("\n")
+    ```
+
+=== "Async"
+
+    ```python
+    agent = create_react_agent(
+        model="anthropic:claude-3-7-sonnet-latest",
+        tools=[get_weather],
+    )
+
+    async for stream_mode, chunk in agent.astream(
+        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
+        # highlight-next-line
+        stream_mode=["updates", "messages", "custom"]
+    ):
+        print(chunk)
+        print("\n")
+    ```
+
+## Disable streaming
+
+In some applications you might need to disable streaming of individual tokens for a given model. This is useful in [multi-agent](./multi-agent.md) systems to control which agents stream their output.
+
+See the [Models](./models.md#disable-streaming) guide to learn how to disable streaming.
+
+## Additional resources
+
+* [Streaming in LangGraph](https://langchain-ai.github.io/langgraph/how-tos/streaming)

docs/docs/agents/tools.md

@@ -273,10 +273,10 @@ See [API reference][langgraph.prebuilt.tool_node.ToolNode] for more information
 
 ## Working with memory
 
-LangGraph allows access to short-term and long-term memory from tools. See [Memory](../how-tos/memory/add-memory.md) guide for more information on:
+LangGraph allows access to short-term and long-term memory from tools. See [Memory](./memory.md) guide for more information on:
 
-* how to [read](../how-tos/memory/add-memory.md#read-short-term) from and [write](../how-tos/memory/add-memory.md#write-short-term) to **short-term** memory
-* how to [read](../how-tos/memory/add-memory.md#read-long-term) from and [write](../how-tos/memory/add-memory.md#write-long-term) to **long-term** memory
+* how to [read](./memory.md#read-short-term) from and [write](./memory.md#write-short-term) to **short-term** memory
+* how to [read](./memory.md#read-long-term) from and [write](./memory.md#write-long-term) to **long-term** memory
 
 ## Prebuilt tools
 

docs/docs/agents/ui.md

@@ -25,7 +25,7 @@ Then, navigate to [Agent Chat UI](https://agentchat.vercel.app), or clone the re
 
 ## Add human-in-the-loop
 
-Agent Chat UI has full support for [human-in-the-loop](../concepts/human_in_the_loop.md) workflows. To try it out, replace the agent code in `src/agent/graph.py` (from the [deployment](./deployment.md) guide) with this [agent implementation](../how-tos/human_in_the_loop/add-human-in-the-loop.md#add-interrupts-to-any-tool):
+Agent Chat UI has full support for [human-in-the-loop](../concepts/human_in_the_loop.md) workflows. To try it out, replace the agent code in `src/agent/graph.py` (from the [deployment](./deployment.md) guide) with this [agent implementation](./human-in-the-loop.md#using-with-agent-inbox):
 
 <video controls src="../assets/interrupt-chat-ui.mp4" type="video/mp4"></video>
 

docs/docs/cloud/concepts/runs.md

@@ -0,0 +1,5 @@
+# Runs
+
+A run is an invocation of an [assistant](../../concepts/assistants.md). 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](./threads.md).
+
+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/cloud/concepts/streaming.md

@@ -0,0 +1,138 @@
+# Streaming
+
+Streaming is critical for making LLM applications feel responsive to end users.  
+When creating a streaming run, the **streaming mode** determines what kinds of data are streamed back to the API client.
+
+## Supported streaming modes
+
+LangGraph Platform supports the following streaming modes:
+
+| Mode                 | Description                                                                                                                                                    | LangGraph Library Method                                                |
+|----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------|
+| **`values`**         | Stream the full graph state after each [super-step](https://langchain-ai.github.io/langgraph/concepts/low_level/#graphs). [Guide](../how-tos/streaming.md#stream-graph-state) | `.stream()` / `.astream()` with `stream_mode="values"`                  |
+| **`updates`**        | Stream only the updates to the graph state after each node. [Guide](../how-tos/streaming.md#stream-graph-state)                                                              | `.stream()` / `.astream()` with `stream_mode="updates"`                 |
+| **`messages-tuple`** | Stream LLM tokens for any messages generated inside the graph (useful for chat apps). [Guide](../how-tos/streaming.md#messages)                                   | `.stream()` / `.astream()` with `stream_mode="messages"`                |
+| **`debug`**          | Stream debug information throughout graph execution. [Guide](../how-tos/streaming.md#debug)                                                                       | `.stream()` / `.astream()` with `stream_mode="debug"`                   |
+| **`custom`**         | Stream custom data. [Guide](../../how-tos/streaming.md#stream-custom-data)                                                                                                                                             | `.stream()` / `.astream()` with `stream_mode="custom"`                  |
+| **`events`**         | Stream all events (including the state of the graph); mainly useful when migrating large LCEL apps. [Guide](../how-tos/streaming.md#stream-events)                       | `.astream_events()`                                                     |
+
+✅ You can also **combine multiple modes** at the same time.  See the [how-to guide](../how-tos/streaming.md#stream-multiple-modes) for configuration details.
+
+## Stateless runs
+
+If you don't want to **persist the outputs** of a streaming run in the [checkpointer](../../concepts/persistence.md) DB, you can create a stateless run without creating a thread:
+
+=== "Python"
+
+    ```python
+    from langgraph_sdk import get_client
+    client = get_client(url=<DEPLOYMENT_URL>, api_key=<API_KEY>)
+
+    async for chunk in client.runs.stream(
+        # highlight-next-line
+        None,  # (1)!
+        assistant_id,
+        input=inputs,
+        stream_mode="updates"
+    ):
+        print(chunk.data)
+    ```
+
+    1. We are passing `None` instead of a `thread_id` UUID.
+
+=== "JavaScript"
+
+    ```js
+    import { Client } from "@langchain/langgraph-sdk";
+    const client = new Client({ apiUrl: <DEPLOYMENT_URL>, apiKey: <API_KEY> });
+
+    // create a streaming run
+    // highlight-next-line
+    const streamResponse = client.runs.stream(
+      // highlight-next-line
+      null,  // (1)!
+      assistantID,
+      {
+        input,
+        streamMode: "updates"
+      }
+    );
+    for await (const chunk of streamResponse) {
+      console.log(chunk.data);
+    }
+    ```
+
+    1. We are passing `None` instead of a `thread_id` UUID.
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+    --url <DEPLOYMENT_URL>/runs/stream \
+    --header 'Content-Type: application/json' \
+    --header 'x-api-key: <API_KEY>'
+    --data "{
+      \"assistant_id\": \"agent\",
+      \"input\": <inputs>,
+      \"stream_mode\": \"updates\"
+    }"
+    ```
+
+## Join and stream
+
+LangGraph Platform allows you to join an active [background run](../how-tos/background_run.md) and stream outputs from it. To do so, you can use [LangGraph SDK's](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/python_sdk_ref/) `client.runs.join_stream` method:
+
+=== "Python"
+
+    ```python
+    from langgraph_sdk import get_client
+    client = get_client(url=<DEPLOYMENT_URL>, api_key=<API_KEY>)
+
+    # highlight-next-line
+    async for chunk in client.runs.join_stream(
+        thread_id,
+        # highlight-next-line
+        run_id,  # (1)!
+    ):
+        print(chunk)
+    ```
+
+    1. This is the `run_id` of an existing run you want to join.
+
+
+=== "JavaScript"
+
+    ```js
+    import { Client } from "@langchain/langgraph-sdk";
+    const client = new Client({ apiUrl: <DEPLOYMENT_URL>, apiKey: <API_KEY> });
+
+    // highlight-next-line
+    const streamResponse = client.runs.joinStream(
+      threadID,
+      // highlight-next-line
+      runId  // (1)!
+    );
+    for await (const chunk of streamResponse) {
+      console.log(chunk);
+    }
+    ```
+
+    1. This is the `run_id` of an existing run you want to join.
+
+=== "cURL"
+
+    ```bash
+    curl --request GET \
+    --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/<RUN_ID>/stream \
+    --header 'Content-Type: application/json' \
+    --header 'x-api-key: <API_KEY>'
+    ```
+
+!!! warning "Outputs not buffered"
+
+    When you use `.join_stream`, output is not buffered, so any output produced before joining will not be received.
+
+## API Reference
+
+For API usage and implementation, refer to the [API reference](../reference/api/api_ref.html#tag/thread-runs/POST/threads/{thread_id}/runs/stream). 
+

docs/docs/cloud/concepts/threads.md

@@ -1,6 +1,6 @@
 # Threads
 
-A thread contains the accumulated state of a sequence of [runs](../../concepts/assistants.md#execution). When a run is executed, the [state](../../concepts/low_level.md#state) of the underlying graph of the assistant will be persisted to the thread.
+A thread contains the accumulated state of a sequence of [runs](./runs.md). When a run is executed, the [state](../../concepts/low_level.md#state) of the underlying graph of the assistant will be persisted to the thread.
 
 A thread's current and historical state can be retrieved. To persist state, a thread must be created prior to executing a run.
 

docs/docs/cloud/deployment/cloud.md

@@ -62,15 +62,6 @@ Starting from the `LangGraph Platform` view...
 1. In the panel, select the `Server` tab to view server logs for the revision. Server logs are only available after a revision has been deployed.
 1. Within the `Server` tab, adjust the date/time range picker as needed. By default, the date/time range picker is set to the `Last 7 days`.
 
-## View Deployment Metrics
-
-Starting from the <a href="https://smith.langchain.com/" target="_blank">LangSmith UI</a>...
-
-1. In the left-hand navigation panel, select `LangGraph Platform`. The `LangGraph Platform` view contains a list of existing LangGraph Platform deployments.
-1. Select an existing deployment to monitor.
-1. Select the `Monitoring` tab to view the deployment metrics. See a list of [all available metrics](../../concepts/langgraph_control_plane.md#monitoring).
-1. Within the `Monitoring` tab, use the date/time range picker as needed. By default, the date/time range picker is set to the `Last 15 minutes`.
-
 ## Interrupt Revision
 
 Interrupting a revision will stop deployment of the revision.

docs/docs/cloud/deployment/graph_rebuild.md

@@ -20,7 +20,7 @@ my-app/
 |-- openai_agent.py     # code for your graph
 ```
 
-where the graph is defined in `openai_agent.py`. 
+where the graph is defined in `openai_agent.py`.
 
 ### No rebuild
 
@@ -28,11 +28,11 @@ In the standard LangGraph API configuration, the server uses the compiled graph
 
 ```python
 from langchain_openai import ChatOpenAI
-from langgraph.graph import END, START, MessageGraph
+from langgraph.graph import END, START, StateGraph, MessagesState
 
 model = ChatOpenAI(temperature=0)
 
-graph_workflow = MessageGraph()
+graph_workflow = StateGraph(MessagesState)
 
 graph_workflow.add_node("agent", model)
 graph_workflow.add_edge("agent", END)
@@ -61,7 +61,7 @@ To make your graph rebuild on each new run with custom configuration, you need t
 from typing import Annotated
 from typing_extensions import TypedDict
 from langchain_openai import ChatOpenAI
-from langgraph.graph import END, START, MessageGraph
+from langgraph.graph import END, START
 from langgraph.graph.state import StateGraph
 from langgraph.graph.message import add_messages
 from langgraph.prebuilt import ToolNode
@@ -144,4 +144,4 @@ Finally, you need to specify the path to your graph-making function (`make_graph
 }
 ```
 
-See more info on LangGraph API configuration file [here](../reference/cli.md#configuration-file)
+See more info on LangGraph API configuration file [here](../reference/cli.md#configuration-file)

docs/docs/cloud/deployment/self_hosted_data_plane.md

@@ -15,15 +15,11 @@ Before deploying, review the [conceptual guide for the Self-Hosted Data Plane](.
 ### Prerequisites
 1. `KEDA` is installed on your cluster.
 
-        helm repo add kedacore https://kedacore.github.io/charts
+        helm repo add kedacore https://kedacore.github.io/charts 
         helm install keda kedacore/keda --namespace keda --create-namespace
 
 1. A valid `Ingress` controller is installed on your cluster.
 1. You have slack space in your cluster for multiple deployments. `Cluster-Autoscaler` is recommended to automatically provision new nodes.
-1. You will need to enable egress to two control plane URLs. The listener polls these endpoints for deployments:
-
-        https://api.host.langchain.com
-        https://api.smith.langchain.com
 
 ### Setup
 

docs/docs/cloud/how-tos/add-human-in-the-loop.md

@@ -1,8 +1,38 @@
-# Human-in-the-loop using Server API
+# Human-in-the-loop
 
-To review, edit, and approve tool calls in an agent or workflow, use LangGraph's [human-in-the-loop](../../concepts/human_in_the_loop.md) features.
+LangGraph supports robust **human-in-the-loop (HIL)** workflows, enabling human intervention at any point in an automated process. This is especially useful in large language model (LLM)-driven applications where model output may require validation, correction, or additional context.
 
-## LangGraph API invoke & resume
+Please see [the overview of LangGraph human-in-the-loop](../../concepts/human_in_the_loop.md) features for more information.
+
+## `interrupt`
+
+The [`interrupt` function][langgraph.types.interrupt] in LangGraph enables human-in-the-loop workflows by pausing the graph at a specific node, presenting information to a human, and resuming the graph with their input. It's useful for tasks like approvals, edits, or gathering additional context.
+
+The graph is resumed using a [`Command`][langgraph.types.Command] object that provides the human's response.
+
+**Graph node with `interrupt`:**
+
+```python
+# highlight-next-line
+from langgraph.types import interrupt, Command
+
+def human_node(state: State):
+    # highlight-next-line
+    value = interrupt( # (1)!
+        {
+            "text_to_revise": state["some_text"] # (2)!
+        }
+    )
+    return {
+        "some_text": value # (3)!
+    }
+```
+
+1. `interrupt(...)` pauses execution at `human_node`, surfacing the given payload to a human.
+2. Any JSON serializable value can be passed to the `interrupt` function. Here, a dict containing the text to revise.
+3. Once resumed, the return value of `interrupt(...)` is the human-provided input, which is used to update the state.
+
+**LangGraph API invoke & resume:**
 
 === "Python"
 
@@ -307,5 +337,6 @@ To review, edit, and approve tool calls in an agent or workflow, use LangGraph's
 
 ## Learn more
 
-- [Human-in-the-loop conceptual guide](../../concepts/human_in_the_loop.md): learn more about LangGraph human-in-the-loop features. 
-- [Common patterns](../../how-tos/human_in_the_loop/add-human-in-the-loop.md#common-patterns): learn how to implement patterns like approving/rejecting actions, requesting user input, tool call review, and validating human input.
+- [**LangGraph human-in-the-loop overview**](../../concepts/human_in_the_loop.md): learn more about LangGraph human-in-the-loop features. 
+- [**Design patterns**](../../how-tos/human_in_the_loop/add-human-in-the-loop.md#design-patterns): learn how to implement patterns like approving/rejecting actions, requesting user input, and more.
+- [**How to review tool calls**](./human_in_the_loop_review_tool_calls.md): detailed examples of how to review and approve/edit tool calls or provide feedback to the tool-calling LLM.

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

@@ -212,7 +212,6 @@ We have now created an assistant called "Open AI Assistant" that has `model_name
 
 Output:
 
-    ```
     Receiving event of type: metadata
     {'run_id': '1ef6746e-5893-67b1-978a-0f1cd4060e16'}
 
@@ -220,7 +219,6 @@ Output:
 
     Receiving event of type: updates
     {'agent': {'messages': [{'content': 'I was created by OpenAI, a research organization focused on developing and advancing artificial intelligence technology.', 'additional_kwargs': {}, 'response_metadata': {'finish_reason': 'stop', 'model_name': 'gpt-4o-2024-05-13', 'system_fingerprint': 'fp_157b3831f5'}, 'type': 'ai', 'name': None, 'id': 'run-e1a6b25c-8416-41f2-9981-f9cfe043f414', 'example': False, 'tool_calls': [], 'invalid_tool_calls': [], 'usage_metadata': None}]}}
-    ```
 
 ### LangGraph Platform UI
 
@@ -233,11 +231,9 @@ Inside your deployment, select the "Assistants" tab. For the assistant you would
 To edit the assistant, use the `update` method. This will create a new version of the assistant with the provided edits. See the [Python](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/python_sdk_ref/#langgraph_sdk.client.AssistantsClient.update) and [JS](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#update) SDK reference docs for more information.
 
 !!! note "Note"
-
-    You must pass in the ENTIRE config (and metadata if you are using it). The update endpoint creates new versions completely from scratch and does not rely on previous versions.
+You must pass in the ENTIRE config (and metadata if you are using it). The update endpoint creates new versions completely from scratch and does not rely on previous versions.
 
 For example, to update your assistant's system prompt:
-
 === "Python"
 
     ```python

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

@@ -1,16 +1,10 @@
-# Set breakpoints using Server API
+# Breakpoints
 
 [Breakpoints](../../concepts/breakpoints.md) pause graph execution at defined points and let you step through each stage. They use LangGraph's [**persistence layer**](../../concepts/persistence.md), which saves the graph state after each step.
 
-With breakpoints, you can inspect the graph's state and node inputs at any point. Execution pauses indefinitely until you resume, as the checkpointer preserves the state.
+With breakpoints, you can inspect the graph's state and node inputs at any point. Execution pauses **indefinitely** until you resume, as the checkpointer preserves the state.
 
-!!! tip
-
-    For conceptual information on breakpoints, see [Breakpoints](../../concepts/breakpoints.md).
-
-## Set static breakpoints
-
-Static breakpoints are triggered either before or after a node executes. You can set static breakpoints by specifying `interrupt_before` and `interrupt_after` at compile time or run time.
+## Set breakpoints
 
 === "Compile time"
 
@@ -84,9 +78,10 @@ Static breakpoints are triggered either before or after a node executes. You can
         }"
         ```
 
-## Example
+!!! tip
+
+    This example shows how to add **static** breakpoints. See [this guide](../../how-tos/human_in_the_loop/breakpoints.ipynb) for more options for how to add breakpoints.
 
-This example shows how to add **static** breakpoints. See [Use breakpoints](../../how-tos/human_in_the_loop/breakpoints.md) for more options on adding breakpoints.
 
 === "Python"
 
@@ -182,4 +177,8 @@ This example shows how to add **static** breakpoints. See [Use breakpoints](../.
     --data "{
       \"assistant_id\": \"agent\"
     }"
-    ```
+    ```
+
+## Learn more
+
+- [**LangGraph breakpoints guide**](../../how-tos/human_in_the_loop/breakpoints.ipynb): learn more about adding breakpoints in LangGraph.

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

@@ -0,0 +1,549 @@
+# How to review tool calls
+
+!!! tip "Prerequisites"
+
+    This guide assumes familiarity with the following concepts:
+
+    * [Tool calling](https://python.langchain.com/docs/concepts/tool_calling/)
+    * [Human-in-the-loop](../../concepts/human_in_the_loop.md)
+    * [LangGraph Glossary](../../concepts/low_level.md)
+
+Human-in-the-loop (HIL) interactions are crucial for [agentic systems](../../concepts/agentic_concepts.md). A common pattern is to add some human in the loop step after certain tool calls. These tool calls often lead to either a function call or saving of some information. Examples include:
+
+- A tool call to execute SQL, which will then be run by the tool
+- A tool call to generate a summary, which will then be saved to the State of the graph
+
+Note that using tool calls is common **whether actually calling tools or not**.
+
+There are typically a few different interactions you may want to do here:
+
+1. Approve the tool call and continue
+2. Modify the tool call manually and then continue
+3. Give natural language feedback, and then pass that back to the agent
+
+
+We can implement these in LangGraph using the [`interrupt()`][langgraph.types.interrupt] function. `interrupt` allows us to stop graph execution to collect input from a user and continue execution with collected input:
+
+
+```python
+def human_review_node(state) -> Command[Literal["call_llm", "run_tool"]]:
+    # this is the value we'll be providing via Command(resume=<human_review>)
+    human_review = interrupt(
+        {
+            "question": "Is this correct?",
+            # Surface tool calls for review
+            "tool_call": tool_call
+        }
+    )
+
+    review_action, review_data = human_review
+
+    # Approve the tool call and continue
+    if review_action == "continue":
+        return Command(goto="run_tool")
+
+    # Modify the tool call manually and then continue
+    elif review_action == "update":
+        ...
+        updated_msg = get_updated_msg(review_data)
+        return Command(goto="run_tool", update={"messages": [updated_message]})
+
+    # Give natural language feedback, and then pass that back to the agent
+    elif review_action == "feedback":
+        ...
+        feedback_msg = get_feedback_msg(review_data)
+        return Command(goto="call_llm", update={"messages": [feedback_msg]})
+
+```
+
+## Setup
+
+We are not going to show the full code for the graph we are hosting, but you can see it [here](../../how-tos/human_in_the_loop/review-tool-calls.ipynb). Once this graph is hosted, we are ready to invoke it and wait for user input. 
+
+### SDK initialization
+
+First, we need to setup our client so that we can communicate with our hosted graph:
+
+
+=== "Python"
+
+    ```python
+    from langgraph_sdk import get_client
+    client = get_client(url=<DEPLOYMENT_URL>)
+    # Using the graph deployed with the name "agent"
+    assistant_id = "agent"
+    thread = await client.threads.create()
+    ```
+
+=== "Javascript"
+
+    ```js
+    import { Client } from "@langchain/langgraph-sdk";
+
+    const client = new Client({ apiUrl: <DEPLOYMENT_URL> });
+    // Using the graph deployed with the name "agent"
+    const assistantId = "agent";
+    const thread = await client.threads.create();
+    ```
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+      --url <DEPLOYMENT_URL>/threads \
+      --header 'Content-Type: application/json' \
+      --data '{}'
+    ```
+
+## Example of approving tool
+
+First, let's run the agent with an input that requires tool calls with approval:
+
+=== "Python"
+
+    ```python
+    input = {"messages": [{"role": "user", "content": "what's the weather in sf?"}]}
+
+    async for chunk in client.runs.stream(
+        thread["thread_id"],
+        assistant_id,
+        input=input,
+        stream_mode="updates",
+    ):
+        if chunk.data and chunk.event != "metadata": 
+            print(chunk.data)
+    ```
+
+=== "Javascript"
+
+    ```js
+    const input = { "messages": [{ "role": "user", "content": "what's the weather in sf?" }] };
+
+    const streamResponse = client.runs.stream(
+      thread["thread_id"],
+      assistantId,
+      {
+        input: input,
+        streamMode: "updates"
+      }
+    );
+
+    for await (const chunk of streamResponse) {
+      if (chunk.data && chunk.event !== "metadata") {
+        console.log(chunk.data);
+      }
+    }
+    ```
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+     --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
+     --header 'Content-Type: application/json' \
+     --data "{
+       \"assistant_id\": \"agent\",
+       \"input\": {\"messages\": [{\"role\": \"human\", \"content\": \"what's the weather in sf?\"}]},
+       \"stream_mode\": [
+         \"updates\"
+       ]
+     }"
+    ```
+
+Output:
+
+    {'call_llm': {'messages': [{'content': [{'text': "I'll help you check the weather in San Francisco.", 'type': 'text'}, {'id': 'toolu_01142G3woscA8JjFTLdqymtn', 'input': {'city': 'San Francisco'}, 'name': 'weather_search', 'type': 'tool_use'}], 'additional_kwargs': {}, 'response_metadata': {'id': 'msg_01Tdfufy4nZYXMbVZvgyNbhc', 'model': 'claude-3-5-sonnet-20241022', 'stop_reason': 'tool_use', 'stop_sequence': None, 'usage': {'cache_creation_input_tokens': 0, 'cache_read_input_tokens': 0, 'input_tokens': 379, 'output_tokens': 66}, 'model_name': 'claude-3-5-sonnet-20241022'}, 'type': 'ai', 'name': None, 'id': 'run-a33434b2-f5ca-40c6-98e2-6288d349d4ce-0', 'example': False, 'tool_calls': [{'name': 'weather_search', 'args': {'city': 'San Francisco'}, 'id': 'toolu_01142G3woscA8JjFTLdqymtn', 'type': 'tool_call'}], 'invalid_tool_calls': [], 'usage_metadata': {'input_tokens': 379, 'output_tokens': 66, 'total_tokens': 445, 'input_token_details': {'cache_read': 0, 'cache_creation': 0}}}]}}
+    {'__interrupt__': [{'value': {'question': 'Is this correct?', 'tool_call': {'name': 'weather_search', 'args': {'city': 'San Francisco'}, 'id': 'toolu_01142G3woscA8JjFTLdqymtn', 'type': 'tool_call'}}, 'resumable': True, 'ns': ['human_review_node:9caf42cf-1371-7213-a331-e6fe5d026be8'], 'when': 'during'}]}
+
+To approve the tool call, we need to let `human_review_node` know what value to use for the `human_review` variable we defined inside the node. We can provide this value by invoking the graph with a `Command(resume=<human_review>)` input.  Since we're approving the tool call, we'll provide `resume` value of `{"action": "continue"}` to navigate to `run_tool` node:
+
+=== "Python"
+
+    ```python
+    # highlight-next-line
+    from langgraph_sdk.schema import Command
+
+    async for chunk in client.runs.stream(
+        thread["thread_id"],
+        assistant_id,
+        # highlight-next-line
+        command=Command(resume={"action": "continue"}),
+        stream_mode="updates",
+    ):
+        if chunk.data and chunk.event != "metadata": 
+            print(chunk.data)
+    ```
+
+=== "Javascript"
+
+    ```js
+    const streamResponse = client.runs.stream(
+      thread["thread_id"],
+      assistantId,
+      {
+        // highlight-next-line
+        command: { resume: { "action": "continue" } },
+        streamMode: "updates"
+      }
+    );
+
+    for await (const chunk of streamResponse) {
+      if (chunk.data && chunk.event !== "metadata") {
+        console.log(chunk.data);
+      }
+    }
+    ```
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+     --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
+     --header 'Content-Type: application/json' \
+     --data "{
+       \"assistant_id\": \"agent\",
+       \"command\": {
+         \"resume\": { \"action\": \"continue\"}
+       },
+       \"stream_mode\": [
+         \"updates\"
+       ]
+     }"
+    ```
+
+Output:
+
+    {'human_review_node': None}
+    {'run_tool': {'messages': [{'role': 'tool', 'name': 'weather_search', 'content': 'Sunny!', 'tool_call_id': 'toolu_01142G3woscA8JjFTLdqymtn'}]}}
+    {'call_llm': {'messages': [{'content': "According to the search, it's sunny in San Francisco right now!", 'additional_kwargs': {}, 'response_metadata': {'id': 'msg_01JJE9AtT4a9Lob91RRiW9rU', 'model': 'claude-3-5-sonnet-20241022', 'stop_reason': 'end_turn', 'stop_sequence': None, 'usage': {'cache_creation_input_tokens': 0, 'cache_read_input_tokens': 0, 'input_tokens': 458, 'output_tokens': 18}, 'model_name': 'claude-3-5-sonnet-20241022'}, 'type': 'ai', 'name': None, 'id': 'run-5e8d80b5-c46a-4aad-af37-b01f8bb15963-0', 'example': False, 'tool_calls': [], 'invalid_tool_calls': [], 'usage_metadata': {'input_tokens': 458, 'output_tokens': 18, 'total_tokens': 476, 'input_token_details': {'cache_read': 0, 'cache_creation': 0}}}]}}
+
+## Edit Tool Call
+
+Let's now say we want to edit the tool call. E.g. change some of the parameters (or even the tool called!) but then execute that tool.
+
+=== "Python"
+
+    ```python
+    input = {"messages": [{"role": "user", "content": "what's the weather in sf?"}]}
+
+    async for chunk in client.runs.stream(
+        thread["thread_id"],
+        assistant_id,
+        input=input,
+        stream_mode="updates",
+    ):
+        if chunk.data and chunk.event != "metadata": 
+            print(chunk.data)
+    ```
+
+=== "Javascript"
+
+    ```js
+    const input = { "messages": [{ "role": "user", "content": "what's the weather in sf?" }] };
+
+    const streamResponse = client.runs.stream(
+      thread["thread_id"],
+      assistantId,
+      {
+        input: input,
+        streamMode: "updates",
+      }
+    );
+
+    for await (const chunk of streamResponse) {
+      if (chunk.data && chunk.event !== "metadata") {
+        console.log(chunk.data);
+      }
+    }
+    ```
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+     --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
+     --header 'Content-Type: application/json' \
+     --data "{
+       \"assistant_id\": \"agent\",
+       \"input\": {\"messages\": [{\"role\": \"human\", \"content\": \"what's the weather in sf?\"}]},
+       \"stream_mode\": [
+         \"updates\"
+       ]
+     }"
+    ```
+
+To do this, we will use `Command` with a different resume value of `{"action": "update", "data": <tool call args>}`. This will do the following:
+
+* combine existing tool call with user-provided tool call arguments and update the existing AI message with the new tool call
+* navigate to `run_tool` node with the updated AI message and continue execution
+
+
+=== "Python"
+
+    ```python
+    # highlight-next-line
+    from langgraph_sdk.schema import Command
+
+    async for chunk in client.runs.stream(
+        thread["thread_id"],
+        assistant_id,
+        # highlight-next-line
+        command=Command(
+            # highlight-next-line
+            resume={"action": "update", "data": {"city": "San Francisco, USA"}}
+            # highlight-next-line
+        ),
+        stream_mode="updates",
+    ):
+        if chunk.data and chunk.event != "metadata": 
+            print(chunk.data)
+    ```
+
+=== "Javascript"
+
+    ```js
+    const streamResponse = client.runs.stream(
+      thread["thread_id"],
+      assistantId,
+      {
+        // highlight-next-line
+        command: {
+          // highlight-next-line
+          resume: { "action": "update", "data": { "city": "San Francisco, USA" } }
+          // highlight-next-line
+        },
+        streamMode: "updates"
+      }
+    );
+
+    for await (const chunk of streamResponse) {
+      if (chunk.data && chunk.event !== "metadata") {
+        console.log(chunk.data);
+      }
+    }
+    ```
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+     --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
+     --header 'Content-Type: application/json' \
+     --data "{
+       \"assistant_id\": \"agent\",
+       \"command\": {
+         \"resume\": { \"action\": \"update\", \"data\": { \"city\": \"San Francisco, USA\" } }
+       },
+       \"stream_mode\": [
+         \"updates\"
+       ]
+     }"
+    ```
+
+Output:
+
+    {'human_review_node': {'messages': [{'role': 'ai', 'content': [{'text': "I'll help you check the weather in San Francisco.", 'type': 'text'}, {'id': 'toolu_016L4EDPcaQRzzZxiB4Wq2wa', 'input': {'city': 'San Francisco'}, 'name': 'weather_search', 'type': 'tool_use'}], 'tool_calls': [{'id': 'toolu_016L4EDPcaQRzzZxiB4Wq2wa', 'name': 'weather_search', 'args': {'city': 'San Francisco, USA'}}], 'id': 'run-b07f0c35-4e93-43a5-9b48-363767ada3ca-0'}]}}
+    {'run_tool': {'messages': [{'role': 'tool', 'name': 'weather_search', 'content': 'Sunny!', 'tool_call_id': 'toolu_016L4EDPcaQRzzZxiB4Wq2wa'}]}}
+    {'call_llm': {'messages': [{'content': "According to the search, it's sunny in San Francisco right now!", 'additional_kwargs': {}, 'response_metadata': {'id': 'msg_01De5HurjNUMwMUpfRtMLbX1', 'model': 'claude-3-5-sonnet-20241022', 'stop_reason': 'end_turn', 'stop_sequence': None, 'usage': {'cache_creation_input_tokens': 0, 'cache_read_input_tokens': 0, 'input_tokens': 460, 'output_tokens': 18}, 'model_name': 'claude-3-5-sonnet-20241022'}, 'type': 'ai', 'name': None, 'id': 'run-85e2aaaa-6f61-4fa0-b594-b6e57129d7e7-0', 'example': False, 'tool_calls': [], 'invalid_tool_calls': [], 'usage_metadata': {'input_tokens': 460, 'output_tokens': 18, 'total_tokens': 478, 'input_token_details': {'cache_read': 0, 'cache_creation': 0}}}]}}
+
+## Give feedback to a tool call
+
+Sometimes, you may not want to execute a tool call, but you also may not want to ask the user to manually modify the tool call. In that case it may be better to get natural language feedback from the user. You can then insert this feedback as a mock **RESULT** of the tool call.
+
+There are multiple ways to do this:
+
+1. You could add a new message to the state (representing the "result" of a tool call)
+2. You could add TWO new messages to the state - one representing an "error" from the tool call, other HumanMessage representing the feedback
+
+Both are similar in that they involve adding messages to the state. The main difference lies in the logic AFTER the `human_review_node` and how it handles different types of messages.
+
+For this example we will just add a single tool call representing the feedback (see `human_review_node` implementation). Let's see this in action!
+
+=== "Python"
+
+    ```python
+    input = {"messages": [{"role": "user", "content": "what's the weather in sf?"}]}
+
+    async for chunk in client.runs.stream(
+        thread["thread_id"],
+        assistant_id,
+        input=input,
+        stream_mode="updates",
+    ):
+        if chunk.data and chunk.event != "metadata": 
+            print(chunk.data)
+    ```
+
+=== "Javascript"
+
+    ```js
+    const input = { "messages": [{ "role": "user", "content": "what's the weather in sf?" }] };
+
+    const streamResponse = client.runs.stream(
+      thread["thread_id"],
+      assistantId,
+      {
+        input: input,
+        streamMode: "updates"
+      }
+    );
+
+    for await (const chunk of streamResponse) {
+      if (chunk.data && chunk.event !== "metadata") {
+        console.log(chunk.data);
+      }
+    }
+    ```
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+     --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
+     --header 'Content-Type: application/json' \
+     --data "{
+       \"assistant_id\": \"agent\",
+       \"input\": {\"messages\": [{\"role\": \"human\", \"content\": \"what's the weather in sf?\"}]},
+       \"stream_mode\": [
+         \"updates\"
+       ]
+     }"
+    ```
+
+To do this, we will use `Command` with a different resume value of `{"action": "feedback", "data": <feedback string>}`. This will do the following:
+
+* create a new tool message that combines existing tool call from LLM with the with user-provided feedback as content
+* navigate to `call_llm` node with the updated tool message and continue execution
+
+=== "Python"
+
+    ```python
+    # highlight-next-line
+    from langgraph_sdk.schema import Command
+
+    async for chunk in client.runs.stream(
+        thread["thread_id"],
+        assistant_id,
+        # highlight-next-line
+        command=Command(
+            resume={
+                "action": "feedback", 
+                "data": "User requested changes: use <city, country> format for location"
+            }
+        ),
+        stream_mode="updates",
+    ):
+        if chunk.data and chunk.event != "metadata": 
+            print(chunk.data)
+    ```
+
+=== "Javascript"
+
+    ```js
+    const streamResponse = client.runs.stream(
+      thread["thread_id"],
+      assistantId,
+      {
+        // highlight-next-line
+        command: {
+          resume: {
+            "action": "feedback", 
+            "data": "User requested changes: use <city, country> format for location"
+          }
+        },
+        streamMode: "updates"
+      }
+    );
+
+    for await (const chunk of streamResponse) {
+      if (chunk.data && chunk.event !== "metadata") {
+        console.log(chunk.data);
+      }
+    }
+    ```
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+     --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
+     --header 'Content-Type: application/json' \
+     --data "{
+       \"assistant_id\": \"agent\",
+       \"command\": {
+         \"resume\": { \"action\": \"feedback\", \"data\": \"User requested changes: use <city, country> format for location\" }
+       },
+       \"stream_mode\": [
+         \"updates\"
+       ]
+     }"
+    ```
+
+
+Output:
+
+    {'human_review_node': {'messages': [{'role': 'tool', 'content': 'User requested changes: use <city, country> format for location', 'name': 'weather_search', 'tool_call_id': 'toolu_01RkPHCjpfoUvPAktaq4Cqhm'}]}}
+    {'call_llm': {'messages': [{'content': [{'text': 'Let me try that again with the correct format:', 'type': 'text'}, {'id': 'toolu_01Rdrag6cVufHZG26BwVaiE7', 'input': {'city': 'San Francisco, USA'}, 'name': 'weather_search', 'type': 'tool_use'}], 'additional_kwargs': {}, 'response_metadata': {'id': 'msg_01EBan969yY5f6iGk6sPgKcj', 'model': 'claude-3-5-sonnet-20241022', 'stop_reason': 'tool_use', 'stop_sequence': None, 'usage': {'cache_creation_input_tokens': 0, 'cache_read_input_tokens': 0, 'input_tokens': 469, 'output_tokens': 68}, 'model_name': 'claude-3-5-sonnet-20241022'}, 'type': 'ai', 'name': None, 'id': 'run-64bbc255-d126-4db0-8ae5-3197cf29bed1-0', 'example': False, 'tool_calls': [{'name': 'weather_search', 'args': {'city': 'San Francisco, USA'}, 'id': 'toolu_01Rdrag6cVufHZG26BwVaiE7', 'type': 'tool_call'}], 'invalid_tool_calls': [], 'usage_metadata': {'input_tokens': 469, 'output_tokens': 68, 'total_tokens': 537, 'input_token_details': {'cache_read': 0, 'cache_creation': 0}}}]}}
+    {'__interrupt__': [{'value': {'question': 'Is this correct?', 'tool_call': {'name': 'weather_search', 'args': {'city': 'San Francisco, USA'}, 'id': 'toolu_01Rdrag6cVufHZG26BwVaiE7', 'type': 'tool_call'}}, 'resumable': True, 'ns': ['human_review_node:e9856878-e28c-5dd1-d353-4d83aa1a3a2b'], 'when': 'during'}]}
+
+We can see that we now get to another interrupt - because it went back to the model and got an entirely new prediction of what to call. Let's now approve this one and continue.
+
+=== "Python"
+
+    ```python
+    # highlight-next-line
+    from langgraph_sdk.schema import Command
+
+    async for chunk in client.runs.stream(
+        thread["thread_id"],
+        assistant_id,
+        # highlight-next-line
+        command=Command(resume={"action": "continue"}),
+        stream_mode="updates",
+    ):
+        if chunk.data and chunk.event != "metadata": 
+            print(chunk.data)
+    ```
+
+=== "Javascript"
+
+    ```js
+    const streamResponse = client.runs.stream(
+      thread["thread_id"],
+      assistantId,
+      {
+        // highlight-next-line
+        command: { resume: { "action": "continue" } },
+        streamMode: "updates"
+      }
+    );
+
+    for await (const chunk of streamResponse) {
+      if (chunk.data && chunk.event !== "metadata") {
+        console.log(chunk.data);
+      }
+    }
+    ```
+
+=== "cURL"
+
+    ```bash
+    curl --request POST \
+     --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
+     --header 'Content-Type: application/json' \
+     --data "{
+       \"assistant_id\": \"agent\",
+       \"command\": {
+         \"resume\": { \"action\": \"continue\"}
+       },
+       \"stream_mode\": [
+         \"updates\"
+       ]
+     }"
+    ```
+
+Output:
+
+    {'human_review_node': None}
+    {'run_tool': {'messages': [{'role': 'tool', 'name': 'weather_search', 'content': 'Sunny!', 'tool_call_id': 'toolu_01Rdrag6cVufHZG26BwVaiE7'}]}}
+    {'call_llm': {'messages': [{'content': 'The weather in San Francisco is sunny!', 'additional_kwargs': {}, 'response_metadata': {'id': 'msg_013WTDHhbg8WiYLiQ9n2CaTk', 'model': 'claude-3-5-sonnet-20241022', 'stop_reason': 'end_turn', 'stop_sequence': None, 'usage': {'cache_creation_input_tokens': 0, 'cache_read_input_tokens': 0, 'input_tokens': 550, 'output_tokens': 12}, 'model_name': 'claude-3-5-sonnet-20241022'}, 'type': 'ai', 'name': None, 'id': 'run-b6c815f0-989a-47cf-b150-33e3bbc4eab7-0', 'example': False, 'tool_calls': [], 'invalid_tool_calls': [], 'usage_metadata': {'input_tokens': 550, 'output_tokens': 12, 'total_tokens': 562, 'input_token_details': {'cache_read': 0, 'cache_creation': 0}}}]}}

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

@@ -1,8 +1,10 @@
-# Time travel using Server API
+# Time travel
 
-LangGraph provides the [**time travel**](../../concepts/time-travel.md) functionality to resume execution from a prior checkpoint, either replaying the same state or modifying it to explore alternatives. In all cases, resuming past execution produces a new fork in the history.
+LangGraph provides [**time travel**](../../concepts/time-travel.md) functionality to **resume execution from a prior checkpoint** — either replaying the same state or modifying it to explore alternatives. In all cases, resuming past execution produces a **new fork** in the history.
 
-To time travel using the LangGraph Server API (via the LangGraph SDK):
+## Use time travel
+
+To use time-travel in LangGraph:
 
 1. **Run the graph** with initial inputs using [LangGraph SDK](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/python_sdk_ref/)'s [`client.runs.wait`][langgraph_sdk.client.RunsClient.wait] or [`client.runs.stream`][langgraph_sdk.client.RunsClient.stream] APIs.
 2. **Identify a checkpoint in an existing thread**: Use [`client.threads.get_history`][langgraph_sdk.client.ThreadsClient.get_history] method to retrieve the execution history for a specific `thread_id` and locate the desired `checkpoint_id`.
@@ -10,7 +12,7 @@ To time travel using the LangGraph Server API (via the LangGraph SDK):
 3. **(Optional) modify the graph state**: Use the [`client.threads.update_state`][langgraph_sdk.client.ThreadsClient.update_state] method to modify the graph’s state at the checkpoint and resume execution from alternative state.
 4. **Resume execution from the checkpoint**: Use the [`client.runs.wait`][langgraph_sdk.client.RunsClient.wait] or [`client.runs.stream`][langgraph_sdk.client.RunsClient.stream] APIs with an input of `None` and the appropriate `thread_id` and `checkpoint_id`.
 
-## Use time travel in a workflow
+## Example
 
 ??? example "Example graph"
 
@@ -235,4 +237,4 @@ To time travel using the LangGraph Server API (via the LangGraph SDK):
 
 ## Learn more
 
-- [**LangGraph time travel guide**](../../how-tos/human_in_the_loop/time-travel.md): learn more about using time travel in LangGraph.
+- [**LangGraph time travel guide**](../../how-tos/human_in_the_loop/time-travel.ipynb): learn more about using time travel in LangGraph.

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

@@ -247,7 +247,5 @@ Verify that the original, interrupted run was interrupted
 
 Output:
 
-    ```
     'interrupted'
-    ```
 

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

@@ -3,7 +3,7 @@
 !!!info  "Prerequisites"
     - [Running agents](../../agents/run_agents.md#running-agents)
 
-This guide shows how to submit a [run](../../concepts/assistants.md#execution) to your application.
+This guide shows how to submit a [run](../concepts/runs.md) to your application.
 
 ## Graph mode
 
@@ -33,7 +33,7 @@ For more information on breakpoints see [here](../../concepts/breakpoints.md).
 
 ### Submit run
 
-To submit the run with the specified input and run settings, click the "Submit" button. This will add a [run](../../concepts/assistants.md#execution) to the existing selected [thread](../../concepts/persistence.md#threads). If no thread is currently selected, a new one will be created.
+To submit the run with the specified input and run settings, click the "Submit" button. This will add a [run](../concepts/runs.md) to the existing selected [thread](../concepts/threads.md). If no thread is currently selected, a new one will be created.
 
 To cancel the ongoing run, click the "Cancel" button.
 

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

@@ -1,12 +1,8 @@
-# Streaming API
+# Stream outputs
 
-[LangGraph SDK](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/python_sdk_ref/) allows you to [stream outputs](../../concepts/streaming.md) from the LangGraph API server.
+## Streaming API
 
-!!! note
-
-    LangGraph SDK and LangGraph Server are a part of [LangGraph Platform](../../concepts/langgraph_platform.md).
-
-## Basic usage
+[LangGraph SDK](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/python_sdk_ref/) allows you to stream outputs from the LangGraph API server.
 
 Basic usage example:
 
@@ -837,121 +833,3 @@ To stream all events, including the state of the graph:
       \"stream_mode\": \"events\"
     }"
     ```
-
-## Stateless runs
-
-If you don't want to **persist the outputs** of a streaming run in the [checkpointer](../../concepts/persistence.md) DB, you can create a stateless run without creating a thread:
-
-=== "Python"
-
-    ```python
-    from langgraph_sdk import get_client
-    client = get_client(url=<DEPLOYMENT_URL>, api_key=<API_KEY>)
-
-    async for chunk in client.runs.stream(
-        # highlight-next-line
-        None,  # (1)!
-        assistant_id,
-        input=inputs,
-        stream_mode="updates"
-    ):
-        print(chunk.data)
-    ```
-
-    1. We are passing `None` instead of a `thread_id` UUID.
-
-=== "JavaScript"
-
-    ```js
-    import { Client } from "@langchain/langgraph-sdk";
-    const client = new Client({ apiUrl: <DEPLOYMENT_URL>, apiKey: <API_KEY> });
-
-    // create a streaming run
-    // highlight-next-line
-    const streamResponse = client.runs.stream(
-      // highlight-next-line
-      null,  // (1)!
-      assistantID,
-      {
-        input,
-        streamMode: "updates"
-      }
-    );
-    for await (const chunk of streamResponse) {
-      console.log(chunk.data);
-    }
-    ```
-
-    1. We are passing `None` instead of a `thread_id` UUID.
-
-=== "cURL"
-
-    ```bash
-    curl --request POST \
-    --url <DEPLOYMENT_URL>/runs/stream \
-    --header 'Content-Type: application/json' \
-    --header 'x-api-key: <API_KEY>'
-    --data "{
-      \"assistant_id\": \"agent\",
-      \"input\": <inputs>,
-      \"stream_mode\": \"updates\"
-    }"
-    ```
-
-## Join and stream
-
-LangGraph Platform allows you to join an active [background run](../how-tos/background_run.md) and stream outputs from it. To do so, you can use [LangGraph SDK's](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/python_sdk_ref/) `client.runs.join_stream` method:
-
-=== "Python"
-
-    ```python
-    from langgraph_sdk import get_client
-    client = get_client(url=<DEPLOYMENT_URL>, api_key=<API_KEY>)
-
-    # highlight-next-line
-    async for chunk in client.runs.join_stream(
-        thread_id,
-        # highlight-next-line
-        run_id,  # (1)!
-    ):
-        print(chunk)
-    ```
-
-    1. This is the `run_id` of an existing run you want to join.
-
-
-=== "JavaScript"
-
-    ```js
-    import { Client } from "@langchain/langgraph-sdk";
-    const client = new Client({ apiUrl: <DEPLOYMENT_URL>, apiKey: <API_KEY> });
-
-    // highlight-next-line
-    const streamResponse = client.runs.joinStream(
-      threadID,
-      // highlight-next-line
-      runId  // (1)!
-    );
-    for await (const chunk of streamResponse) {
-      console.log(chunk);
-    }
-    ```
-
-    1. This is the `run_id` of an existing run you want to join.
-
-=== "cURL"
-
-    ```bash
-    curl --request GET \
-    --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/<RUN_ID>/stream \
-    --header 'Content-Type: application/json' \
-    --header 'x-api-key: <API_KEY>'
-    ```
-
-!!! warning "Outputs not buffered"
-
-    When you use `.join_stream`, output is not buffered, so any output produced before joining will not be received.
-
-## API Reference
-
-For API usage and implementation, refer to the [API reference](../reference/api/api_ref.html#tag/thread-runs/POST/threads/{thread_id}/runs/stream). 

docs/docs/cloud/how-tos/studio/quick_start.md

@@ -13,7 +13,7 @@ LangGraph Studio is accessed from the LangSmith UI, within the LangGraph Platfor
 
 For applications that are [deployed](../../quick_start.md) on LangGraph Platform, you can access Studio as part of that deployment. To do so, navigate to the deployment in LangGraph Platform within the LangSmith UI and click the "LangGraph Studio" button.
 
-This will load the Studio UI connected to your live deployment, allowing you to create, read, and update the [threads](../../../concepts/persistence.md#threads), [assistants](../../../concepts/assistants.md), and [memory](../../../concepts//memory.md) in that deployment.
+This will load the Studio UI connected to your live deployment, allowing you to create, read, and update the [threads](../../concepts/threads.md), [assistants](../../../concepts/assistants.md), and [memory](../../../concepts//memory.md) in that deployment.
 
 ## Local development server
 
@@ -73,11 +73,9 @@ langgraph dev --debug-port 5678
 Then attach your preferred debugger:
 
 === "VS Code"
-
-    Add this configuration to `launch.json`:
-
-    ```json
-    {
+Add this configuration to `launch.json`:
+`json
+      {
         "name": "Attach to LangGraph",
         "type": "debugpy",
         "request": "attach",
@@ -85,16 +83,11 @@ Then attach your preferred debugger:
           "host": "0.0.0.0",
           "port": 5678
         }
-    }
-    ```
+      }
+    `
+Specify the port number you chose in the previous step.
 
-=== "PyCharm" 
-
-    1. Go to Run → Edit Configurations 
-    2. Click + and select "Python Debug Server" 
-    3. Set IDE host name: `localhost` 
-    4. Set port: `5678` (or the port number you chose in the previous step) 
-    5. Click "OK" and start debugging
+=== "PyCharm" 1. Go to Run → Edit Configurations 2. Click + and select "Python Debug Server" 3. Set IDE host name: `localhost` 4. Set port: `5678` (or the port number you chose in the previous step) 5. Click "OK" and start debugging
 
 ## Troubleshooting
 

docs/docs/cloud/how-tos/studio/run_evals.md

@@ -1,57 +0,0 @@
-# Run experiments over a dataset
-
-LangGraph Studio supports evaluations by allowing you to run your assistant over a pre-defined LangSmith dataset. This enables you to understand how your application performs over a variety of inputs, compare the results to reference outputs, and score the results using [evaluators](../../../agents/evals.md).
-
-This guide shows you how to run an experiment end-to-end from Studio.
-
----
-
-## Prerequisites
-
-Before running an experiment, ensure you have the following:
-
-1.  **A LangSmith dataset**: Your dataset should contain the inputs you want to test and optionally, reference outputs for comparison.
-
-    - The schema for the inputs must match the required input schema for the assistant. For more information on schemas, see [here](../../../concepts/low_level.md#schema).
-    - For more on creating datasets, see [How to Manage Datasets](https://docs.smith.langchain.com/evaluation/how_to_guides/manage_datasets_in_application#set-up-your-dataset).
-
-2.  **(Optional) Evaluators**: You can attach evaluators (e.g., LLM-as-a-Judge, heuristics, or custom functions) to your dataset in LangSmith. These will run automatically after the graph has processed all inputs.
-
-    - To learn more, read about [Evaluation Concepts](https://docs.smith.langchain.com/evaluation/concepts#evaluators).
-
-3.  **A running application**: The experiment can be run against:
-    - An application deployed on [LangGraph Platform](../../quick_start.md).
-    - A locally running application started via the [langgraph-cli](../../../tutorials/langgraph-platform/local-server.md).
-
----
-
-## Step-by-step guide
-
-### 1. Launch the experiment
-
-Click the **Run experiment** button in the top right corner of the Studio page.
-
-### 2. Select your dataset
-
-In the modal that appears, select the dataset (or a specific dataset split) to use for the experiment and click **Start**.
-
-### 3. Monitor the progress
-
-All of the inputs in the dataset will now be run against the active assistant. Monitor the experiment's progress via the badge in the top right corner.
-
-You can continue to work in Studio while the experiment runs in the background. Click the arrow icon button at any time to navigate to LangSmith and view the detailed experiment results.
-
----
-
-## Troubleshooting
-
-### "Run experiment" button is disabled
-
-If the "Run experiment" button is disabled, check the following:
-
-- **Deployed application**: If your application is deployed on LangGraph Platform, you may need to create a new revision to enable this feature.
-- **Local development server**: If you are running your application locally, make sure you have upgraded to the latest version of the `langgraph-cli` (`pip install -U langgraph-cli`). Additionally, ensure you have tracing enabled by setting the `LANGSMITH_API_KEY` in your project's `.env` file.
-
-### Evaluator results are missing
-
-When you run an experiment, any attached evaluators are scheduled for execution in a queue. If you don't see results immediately, it likely means they are still pending.

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

@@ -1,6 +1,10 @@
 # Manage threads
 
-Studio allows you to view [threads](../../concepts/persistence.md#threads) from the server and edit their state.
+!!! info "Prerequisites"
+
+    - [Threads Overview](../concepts/threads.md)
+
+Studio allows you to view threads from the server and edit their state.
 
 ## View threads
 

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

@@ -1,6 +1,10 @@
 # Use threads
 
-In this guide, we will show how to create, view, and inspect [threads](../../concepts/persistence.md#threads).
+!!! info "Prerequisites"
+
+    - [Threads Overview](../concepts/threads.md)
+
+In this guide, we will show how to create, view, and inspect threads.
 
 ## Create a thread
 

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

@@ -8,15 +8,15 @@ Currently, the SDK does not provide built-in support for defining webhook endpoi
 
 The following API endpoints accept a `webhook` parameter:
 
-| Operation            | HTTP Method | Endpoint                          |
-|----------------------|-------------|-----------------------------------|
-| Create Run           | `POST`      | `/thread/{thread_id}/runs`        |
-| Create Thread Cron   | `POST`      | `/thread/{thread_id}/runs/crons`  |
-| Stream Run           | `POST`      | `/thread/{thread_id}/runs/stream` |
-| Wait Run             | `POST`      | `/thread/{thread_id}/runs/wait`   |
-| Create Cron          | `POST`      | `/runs/crons`                     |
-| Stream Run Stateless | `POST`      | `/runs/stream`                    |
-| Wait Run Stateless   | `POST`      | `/runs/wait`                      |
+| Operation | HTTP Method | Endpoint |
+|-----------|------------|----------|
+| Create Run | `POST` | `/thread/{thread_id}/runs` |
+| Create Thread Cron | `POST` | `/thread/{thread_id}/runs/crons` |
+| Stream Run | `POST` | `/thread/{thread_id}/runs/stream` |
+| Wait Run | `POST` | `/thread/{thread_id}/runs/wait` |
+| Create Cron | `POST` | `/runs/crons` |
+| Stream Run Stateless | `POST` | `/runs/stream` |
+| Wait Run Stateless | `POST` | `/runs/wait` |
 
 In this guide, we’ll show how to trigger a webhook after streaming a run.
 
@@ -25,39 +25,36 @@ In this guide, we’ll show how to trigger a webhook after streaming a run.
 Before making API calls, set up your assistant and thread.
 
 === "Python"
+```python
+from langgraph_sdk import get_client
 
-    ```python
-    from langgraph_sdk import get_client
-
-    client = get_client(url=<DEPLOYMENT_URL>)
-    assistant_id = "agent"
-    thread = await client.threads.create()
-    print(thread)
-    ```
+client = get_client(url=<DEPLOYMENT_URL>)
+assistant_id = "agent"
+thread = await client.threads.create()
+print(thread)
+```
 
 === "JavaScript"
+```js
+import { Client } from "@langchain/langgraph-sdk";
 
-    ```js
-    import { Client } from "@langchain/langgraph-sdk";
-
-    const client = new Client({ apiUrl: <DEPLOYMENT_URL> });
-    const assistantID = "agent";
-    const thread = await client.threads.create();
-    console.log(thread);
-    ```
+const client = new Client({ apiUrl: <DEPLOYMENT_URL> });
+const assistantID = "agent";
+const thread = await client.threads.create();
+console.log(thread);
+```
 
 === "CURL"
-
-    ```bash
-    curl --request POST \
-        --url <DEPLOYMENT_URL>/assistants/search \
-        --header 'Content-Type: application/json' \
-        --data '{ "limit": 10, "offset": 0 }' | jq -c 'map(select(.config == null or .config == {})) | .[0]' && \
-    curl --request POST \
-        --url <DEPLOYMENT_URL>/threads \
-        --header 'Content-Type: application/json' \
-        --data '{}'
-    ```
+```bash
+curl --request POST \
+    --url <DEPLOYMENT_URL>/assistants/search \
+    --header 'Content-Type: application/json' \
+    --data '{ "limit": 10, "offset": 0 }' | jq -c 'map(select(.config == null or .config == {})) | .[0]' && \
+curl --request POST \
+    --url <DEPLOYMENT_URL>/threads \
+    --header 'Content-Type: application/json' \
+    --data '{}'
+```
 
 Example response:
 
@@ -80,55 +77,52 @@ To use a webhook, specify the `webhook` parameter in your API request. When the
 For example, if your server listens for webhook events at `https://my-server.app/my-webhook-endpoint`, include this in your request:
 
 === "Python"
+```python
+input = { "messages": [{ "role": "user", "content": "Hello!" }] }
 
-    ```python
-    input = { "messages": [{ "role": "user", "content": "Hello!" }] }
-
-    async for chunk in client.runs.stream(
-        thread_id=thread["thread_id"],
-        assistant_id=assistant_id,
-        input=input,
-        stream_mode="events",
-        webhook="https://my-server.app/my-webhook-endpoint"
-    ):
-        pass
-    ```
+async for chunk in client.runs.stream(
+    thread_id=thread["thread_id"],
+    assistant_id=assistant_id,
+    input=input,
+    stream_mode="events",
+    webhook="https://my-server.app/my-webhook-endpoint"
+):
+    pass
+```
 
 === "JavaScript"
+```js
+const input = { messages: [{ role: "human", content: "Hello!" }] };
 
-    ```js
-    const input = { messages: [{ role: "human", content: "Hello!" }] };
+const streamResponse = client.runs.stream(
+  thread["thread_id"],
+  assistantID,
+  {
+    input: input,
+    webhook: "https://my-server.app/my-webhook-endpoint"
+  }
+);
 
-    const streamResponse = client.runs.stream(
-      thread["thread_id"],
-      assistantID,
-      {
-        input: input,
-        webhook: "https://my-server.app/my-webhook-endpoint"
-      }
-    );
-
-    for await (const chunk of streamResponse) {
-      // Handle stream output
-    }
-    ```
+for await (const chunk of streamResponse) {
+  // Handle stream output
+}
+```
 
 === "CURL"
-
-    ```bash
-    curl --request POST \
-        --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
-        --header 'Content-Type: application/json' \
-        --data '{
-            "assistant_id": <ASSISTANT_ID>,
-            "input": {"messages": [{"role": "user", "content": "Hello!"}]},
-            "webhook": "https://my-server.app/my-webhook-endpoint"
-        }'
-    ```
+```bash
+curl --request POST \
+    --url <DEPLOYMENT_URL>/threads/<THREAD_ID>/runs/stream \
+    --header 'Content-Type: application/json' \
+    --data '{
+        "assistant_id": <ASSISTANT_ID>,
+        "input": {"messages": [{"role": "user", "content": "Hello!"}]},
+        "webhook": "https://my-server.app/my-webhook-endpoint"
+    }'
+```
 
 ## Webhook payload
 
-LangGraph Platform sends webhook notifications in the format of a [Run](../../concepts/assistants.md#execution). See the [API Reference](https://langchain-ai.github.io/langgraph/cloud/reference/api/api_ref.html#model/run) for details. The request payload includes run input, configuration, and other metadata in the `kwargs` field.
+LangGraph Platform sends webhook notifications in the format of a [Run](../../cloud/concepts/runs.md). See the [API Reference](https://langchain-ai.github.io/langgraph/cloud/reference/api/api_ref.html#model/run) for details. The request payload includes run input, configuration, and other metadata in the `kwargs` field.
 
 ## Secure webhooks
 

docs/docs/cloud/reference/api/openapi.json

@@ -2601,7 +2601,8 @@
             "description": "Configuration to use for the graph. Useful when graph is configurable and you want to update the assistant's configuration."
           },
           "metadata": {
-            "type": "object",            "title": "Metadata",
+            "type": "object",
+            "title": "Metadata",
             "description": "Metadata to merge with existing assistant metadata."
           },
           "name": {
@@ -2707,13 +2708,6 @@
             "title": "Schedule",
             "description": "The cron schedule to execute this job on."
           },
-          "end_time": {
-            "type": "string",
-            "format": "date-time",
-            "title": "End Time",
-            "description": "The end date to stop running the cron."
-          },
-
           "assistant_id": {
             "anyOf": [
               {
@@ -2820,18 +2814,6 @@
             "description": "The number of results to skip.",
             "default": 0,
             "minimum": 0
-          },
-          "sort_by": {
-            "type": "string",
-            "enum": ["cron_id", "assistant_id", "thread_id", "next_run_date", "end_time", "created_at", "updated_at"],
-            "title": "Sort By",
-            "description": "The field to sort by."
-          },
-          "sort_order": {
-            "type": "string",
-            "enum": ["asc", "desc"],
-            "title": "Sort Order",
-            "description": "The order to sort by."
           }
         },
         "type": "object",

docs/docs/cloud/reference/cli.md

@@ -50,10 +50,9 @@ The LangGraph CLI requires a JSON configuration file that follows this [schema](
     | <span style="white-space: nowrap;">`python_version`</span>   | `3.11`, `3.12`, or `3.13`. Defaults to `3.11`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
     | <span style="white-space: nowrap;">`node_version`</span>     | Specify `node_version: 20` to use LangGraph.js.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
     | <span style="white-space: nowrap;">`pip_config_file`</span>  | Path to `pip` config file.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
-    | <span style="white-space: nowrap;">`pip_installer`</span> | _(Added in v0.3)_ Optional. Python package installer selector. It can be set to `"auto"`, `"pip"`, or `"uv"`. From version&nbsp;0.3 onward the default strategy is to run `uv pip`, which typically delivers faster builds while remaining a drop-in replacement. In the uncommon situation where `uv` cannot handle your dependency graph or the structure of your `pyproject.toml`, specify `"pip"` here to revert to the earlier behaviour. |
     | <span style="white-space: nowrap;">`dockerfile_lines`</span> | Array of additional lines to add to Dockerfile following the import from parent image.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
     | <span style="white-space: nowrap;">`checkpointer`</span>   | Configuration for the checkpointer. Contains a `ttl` field which is an object with the following keys: <ul><li>`strategy`: How to handle expired checkpoints (e.g., `"delete"`).</li><li>`sweep_interval_minutes`: How often to check for expired checkpoints (integer).</li><li>`default_ttl`: Default time-to-live for checkpoints in **minutes** (integer). Defines how long checkpoints are kept before the specified strategy is applied.</li></ul> |
-    | <span style="white-space: nowrap;">`http`</span>            | HTTP server configuration with the following fields: <ul><li>`app`: Path to custom Starlette/FastAPI app (e.g., `"./src/agent/webapp.py:app"`). See [custom routes guide](../../how-tos/http/custom_routes.md).</li><li>`disable_assistants`: Disable `/assistants` routes</li><li>`disable_threads`: Disable `/threads` routes</li><li>`disable_runs`: Disable `/runs` routes</li><li>`disable_store`: Disable `/store` routes</li><li>`disable_meta`: Disable `/ok`, `/info`, `/metrics`, and `/docs` routes</li><li>`disable_mcp`: Disable `/mcp` routes</li><li>`cors`: CORS configuration with fields for `allow_origins`, `allow_methods`, `allow_headers`, etc.</li><li>`configurable_headers`: Define which request headers to exclude or include as a run's configurable values.</li></ul> |
+    | <span style="white-space: nowrap;">`http`</span>            | HTTP server configuration with the following fields: <ul><li>`app`: Path to custom Starlette/FastAPI app (e.g., `"./src/agent/webapp.py:app"`). See [custom routes guide](../../how-tos/http/custom_routes.md).</li><li>`disable_assistants`: Disable `/assistants` routes</li><li>`disable_threads`: Disable `/threads` routes</li><li>`disable_runs`: Disable `/runs` routes</li><li>`disable_store`: Disable `/store` routes</li><li>`disable_meta`: Disable `/ok`, `/info`, `/metrics`, and `/docs` routes</li><li>`cors`: CORS configuration with fields for `allow_origins`, `allow_methods`, `allow_headers`, etc.</li><li>`configurable_headers`: Define which request headers to exclude or include as a run's configurable values.</li></ul> |
 
 === "JS"
 
@@ -129,7 +128,7 @@ The LangGraph CLI requires a JSON configuration file that follows this [schema](
         - `cohere:embed-english-v3.0`: 1024 
         - `cohere:embed-english-light-v3.0`: 384 
         - `cohere:embed-multilingual-v3.0`: 1024 
-        - `cohere:embed-multilingual-light-v3.0`: 384 
+        - `cohere:embed-multilingual-light-v3.0`: 384
 
     #### Semantic search with a custom embedding function
 
@@ -362,8 +361,8 @@ The LangGraph CLI requires a JSON configuration file that follows this [schema](
 
     **Options**
 
-    | Option               | Default          | Description                                                                                                     |
-    | -------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------- |
+    | Option               | Default          | Description                                                                                                                  |
+    | -------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------- |
     | `--platform TEXT`    |                  | Target platform(s) to build the Docker image for. Example: `langgraph build --platform linux/amd64,linux/arm64`              |
     | `-t, --tag TEXT`     |                  | **Required**. Tag for the Docker image. Example: `langgraph build -t my-image`                                               |
     | `--pull / --no-pull` | `--pull`         | Build with latest remote Docker image. Use `--no-pull` for running the LangGraph Platform API server with locally built images. |
@@ -382,8 +381,8 @@ The LangGraph CLI requires a JSON configuration file that follows this [schema](
 
     **Options**
 
-    | Option               | Default          | Description                                                                                                     |
-    | -------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------- |
+    | Option               | Default          | Description                                                                                                                  |
+    | -------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------- |
     | `--platform TEXT`    |                  | Target platform(s) to build the Docker image for. Example: `langgraph build --platform linux/amd64,linux/arm64`              |
     | `-t, --tag TEXT`     |                  | **Required**. Tag for the Docker image. Example: `langgraph build -t my-image`                                               |
     | `--no-pull`          |                  | Use locally built images. Defaults to `false` to build with latest remote Docker image.                                      |

docs/docs/cloud/reference/env_var.md

@@ -50,9 +50,10 @@ Set this environment variable to have a deployment send traces to a self-hosted
 
 ## `LANGSMITH_TRACING`
 
-Set `LANGSMITH_TRACING` to `false` to disable tracing to LangSmith.
+!!! info "Only for Self-Hosted Data Plane, Self-Hosted Control Plane, and Standalone Container"
+    Disabling LangSmith tracing is only available for [Self-Hosted Data Plane](../../concepts/langgraph_self_hosted_data_plane.md), [Self-Hosted Control Plane](../../concepts/langgraph_self_hosted_control_plane.md), and [Standalone Container](../../concepts/langgraph_standalone_container.md) deployments.
 
-Defaults to `true`.
+Set `LANGSMITH_TRACING` to `false` to disable tracing to LangSmith.
 
 ## `LOG_LEVEL`
 

docs/docs/concepts/agentic_concepts.md

@@ -58,10 +58,10 @@ Tools are useful whenever you want an agent to interact with external systems. E
 
 ### Memory
 
-[Memory](../how-tos/memory/add-memory.md) is crucial for agents, enabling them to retain and utilize information across multiple steps of problem-solving. It operates on different scales:
+[Memory](./memory.md) is crucial for agents, enabling them to retain and utilize information across multiple steps of problem-solving. It operates on different scales:
 
-1. [Short-term memory](../how-tos/memory/add-memory.md#add-short-term-memory): Allows the agent to access information acquired during earlier steps in a sequence.
-2. [Long-term memory](../how-tos/memory/add-memory.md#add-long-term-memory): Enables the agent to recall information from previous interactions, such as past messages in a conversation.
+1. [Short-term memory](./memory.md#short-term-memory): Allows the agent to access information acquired during earlier steps in a sequence.
+2. [Long-term memory](./memory.md#long-term-memory): Enables the agent to recall information from previous interactions, such as past messages in a conversation.
 
 LangGraph provides full control over memory implementation:
 
@@ -69,7 +69,9 @@ LangGraph provides full control over memory implementation:
 - [`Checkpointer`](./persistence.md#checkpoints): Mechanism to store state at every step across different interactions within a session.
 - [`Store`](./persistence.md#memory-store): Mechanism to store user-specific or application-level data across sessions.
 
-This flexible approach allows you to tailor the memory system to your specific agent architecture needs. Effective memory management enhances an agent's ability to maintain context, learn from past experiences, and make more informed decisions over time. For a practical guide on adding and managing memory, see [Memory](../how-tos/memory/add-memory.md).
+This flexible approach allows you to tailor the memory system to your specific agent architecture needs. For a practical guide on adding memory to your graph, see [this tutorial](../how-tos/persistence.ipynb).
+
+Effective [memory management](../how-tos/memory.ipynb) enhances an agent's ability to maintain context, learn from past experiences, and make more informed decisions over time.
 
 ### Planning
 

docs/docs/concepts/assistants.md

@@ -1,31 +1,29 @@
 # 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.
+!!! info "Prerequisites"
 
-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.
+    - [LangGraph Server](./langgraph_server.md)
+    - [Configuration](./low_level.md#configuration)
+
+When building agents, it is common to make rapid changes that _do not_ alter the graph logic. For example, simply changing prompts or the LLM selection can have significant impacts on the behavior of the agent but does not require updating your graph's architecture. Assistants offer a straightforward way to manage these configurations separately from your graph's core logic.
+
+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.
 
 ![assistant versions](img/assistants.png)
 
-The LangGraph Cloud API provides several endpoints for creating and managing assistants and their versions. See the [API reference](../cloud/reference/api/api_ref.html#tag/assistants) for more details.
-
-!!! info
-
-    Assistants are a [LangGraph Platform](langgraph_platform.md) concept. They are not available in the open source LangGraph library.
-
-## Configuration
+## Configuring assistants
 
 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.
+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.
 
 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.
 
-## Versioning
+## Versioning assistants
 
 Assistants support versioning to track changes over time.
 Once you've created an assistant, subsequent edits to that assistant will create new versions. See [this how-to](../cloud/how-tos/configuration_cloud.md#create-a-new-version-for-your-assistant) for more details on how to manage assistant versions.
 
-## Execution
+## Learn more
 
-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).
-
-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.
+* The LangGraph Cloud API provides several endpoints for creating and managing assistants and their versions. See the [API reference](../cloud/reference/api/api_ref.html#tag/assistants) for more details.

docs/docs/concepts/breakpoints.md

@@ -5,14 +5,10 @@ search:
 
 # Breakpoints
 
-[Breakpoints](../how-tos/human_in_the_loop/breakpoints.md) pause graph execution at defined points and let you step through each stage. They use LangGraph's [**persistence layer**](./persistence.md), which saves the graph state after each step.
+Breakpoints pause graph execution at defined points and let you step through each stage. They use LangGraph's [**persistence layer**](./persistence.md), which saves the graph state after each step.
 
 With breakpoints, you can inspect the graph's state and node inputs at any point. Execution pauses **indefinitely** until you resume, as the checkpointer preserves the state.
 
 <figure markdown="1">
 ![image](img/breakpoints.png){: style="max-height:400px"}
 <figcaption>An example graph consisting of 3 sequential steps with a breakpoint before step_3. </figcaption> </figure>
-
-!!! tip
-
-    For information on how to use breakpoints, see [Set breakpoints](../how-tos/human_in_the_loop/breakpoints.md) and [Set breakpoints using Server API](../cloud/how-tos/human_in_the_loop_breakpoint.md).

docs/docs/concepts/deployment_options.md

@@ -5,16 +5,7 @@ search:
 
 # Deployment Options
 
-## Free deployment
-
-There are two free options for deploying LangGraph applications via the LangGraph Server:
-
-1. [Local](../tutorials/langgraph-platform/local-server.md): Deploy for local testing and development. 
-1. [Standalone Container (Lite)](../concepts/langgraph_standalone_container.md): A limited version of Standalone Container for deployments unlikely to see more that 1 million node executions per year and that do not need crons and other enterprise features. Standalone Container (Lite) deployment option is free with a LangSmith API key.
-
-## Production deployment
-
-There are 4 main options for deploying with the [LangGraph Platform](langgraph_platform.md):
+There are 4 main options for deploying with the LangGraph Platform:
 
 1. [Cloud SaaS](#cloud-saas)
 
@@ -31,7 +22,7 @@ A quick comparison:
 |----------------------|----------------|----------------------------|-------------------------------|--------------------------|
 | **[Control plane UI/API](../concepts/langgraph_control_plane.md)** | Yes | Yes | Yes | No |
 | **CI/CD** | Managed internally by platform | Managed externally by you | Managed externally by you | Managed externally by you |
-| **Data/compute residency** | LangChain's cloud | Your cloud | Your cloud | Your cloud |
+| **Data/compute residency** | LangChain’s cloud | Your cloud | Your cloud | Your cloud |
 | **LangSmith compatibility** | Trace to LangSmith SaaS | Trace to LangSmith SaaS | Trace to Self-Hosted LangSmith | Optional tracing |
 | **[Server version compatibility](../concepts/langgraph_server.md#server-versions)** | Enterprise | Enterprise | Enterprise | Lite, Enterprise |
 | **[Pricing](https://www.langchain.com/pricing-langgraph-platform)** | Plus | Enterprise | Enterprise | Developer |

docs/docs/concepts/faq.md

@@ -63,8 +63,4 @@ Yes! LangGraph is totally ambivalent to what LLMs are used under the hood. The m
 
 Yes! You can use the [development version of LangGraph Server](../tutorials/langgraph-platform/local-server.md) to run the backend locally.
 This will connect to the studio frontend hosted as part of LangSmith.
-If you set an environment variable of `LANGSMITH_TRACING=false`, then no traces will be sent to LangSmith.
-
-## What does "nodes executed" mean for LangGraph Platform usage?
-
-**Nodes Executed** is the aggregate number of nodes in a LangGraph application that are called and completed successfully during an invocation of the application. If a node in the graph is not called during execution or ends in an error state, these nodes will not be counted. If a node is called and completes successfully multiple times, each occurrence will be counted.
+If you set an environment variable of `LANGSMITH_TRACING=false`, then no traces will be sent to LangSmith.

docs/docs/concepts/functional_api.md

@@ -7,7 +7,7 @@ search:
 
 ## Overview
 
-The **Functional API** allows you to add LangGraph's key features — [persistence](./persistence.md), [memory](../how-tos/memory/add-memory.md), [human-in-the-loop](./human_in_the_loop.md), and [streaming](./streaming.md) — to your applications with minimal changes to your existing code.
+The **Functional API** allows you to add LangGraph's key features — [persistence](./persistence.md), [memory](./memory.md), [human-in-the-loop](./human_in_the_loop.md), and [streaming](./streaming.md) — to your applications with minimal changes to your existing code.
 
 It is designed to integrate these features into existing code that may use standard language primitives for branching and control flow, such as `if` statements, `for` loops, and function calls. Unlike many data orchestration frameworks that require restructuring code into an explicit pipeline or DAG, the Functional API allows you to incorporate these capabilities without enforcing a rigid execution model.  
 
@@ -18,21 +18,10 @@ The Functional API uses two key building blocks:
 
 This provides a minimal abstraction for building workflows with state management and streaming.
 
-!!! tip
-
-    For information on how to use the functional API, see [Use Functional API](../how-tos/use-functional-api.md).
-
-## Functional API vs. Graph API
-
-For users who prefer a more declarative approach, LangGraph's [Graph API](./low_level.md) allows you to define workflows using a Graph paradigm. Both APIs share the same underlying runtime, so you can use them together in the same application.
-
-Here are some key differences:
-
-- **Control flow**: The Functional API does not require thinking about graph structure. You can use standard Python constructs to define workflows. This will usually trim the amount of code you need to write.
-- **Short-term memory**: The **GraphAPI** requires declaring a [**State**](./low_level.md#state) and may require defining [**reducers**](./low_level.md#reducers) to manage updates to the graph state. `@entrypoint` and `@tasks` do not require explicit state management as their state is scoped to the function and is not shared across functions.
-- **Checkpointing**: Both APIs generate and use checkpoints. In the **Graph API** a new checkpoint is generated after every [superstep](./low_level.md). In the **Functional API**, when tasks are executed, their results are saved to an existing checkpoint associated with the given entrypoint instead of creating a new checkpoint.
-- **Visualization**: The Graph API makes it easy to visualize the workflow as a graph which can be useful for debugging, understanding the workflow, and sharing with others. The Functional API does not support visualization as the graph is dynamically generated during runtime.
+!!! tip 
 
+    For users who prefer a more declarative approach, LangGraph's [Graph API](./low_level.md) allows you to define workflows using a Graph paradigm. Both APIs share the same underlying runtime, so you can use them together in the same application.
+    Please see the [Functional API vs. Graph API](#functional-api-vs-graph-api) section for a comparison of the two paradigms.
 
 ## Example
 
@@ -543,6 +532,15 @@ While different runs of a workflow can produce different results, resuming a **s
 
 Idempotency ensures that running the same operation multiple times produces the same result. This helps prevent duplicate API calls and redundant processing if a step is rerun due to a failure. Always place API calls inside **tasks** functions for checkpointing, and design them to be idempotent in case of re-execution. Re-execution can occur if a **task** starts, but does not complete successfully. Then, if the workflow is resumed, the **task** will run again. Use idempotency keys or verify existing results to avoid duplication.
 
+## Functional API vs. Graph API
+
+The **Functional API** and the [Graph APIs (StateGraph)](./low_level.md#stategraph) provide two different paradigms to create applications with LangGraph. Here are some key differences:
+
+- **Control flow**: The Functional API does not require thinking about graph structure. You can use standard Python constructs to define workflows. This will usually trim the amount of code you need to write.
+- **Short-term memory**: The **GraphAPI** requires declaring a [**State**](./low_level.md#state) and may require defining [**reducers**](./low_level.md#reducers) to manage updates to the graph state. `@entrypoint` and `@tasks` do not require explicit state management as their state is scoped to the function and is not shared across functions.
+- **Checkpointing**: Both APIs generate and use checkpoints. In the **Graph API** a new checkpoint is generated after every [superstep](./low_level.md). In the **Functional API**, when tasks are executed, their results are saved to an existing checkpoint associated with the given entrypoint instead of creating a new checkpoint.
+- **Visualization**: The Graph API makes it easy to visualize the workflow as a graph which can be useful for debugging, understanding the workflow, and sharing with others. The Functional API does not support visualization as the graph is dynamically generated during runtime.
+
 ## Common Pitfalls
 
 ### Handling side effects

docs/docs/concepts/human_in_the_loop.md

@@ -11,27 +11,21 @@ hide:
 
 # Human-in-the-loop
 
-To review, edit, and approve tool calls in an agent or workflow, [use LangGraph's human-in-the-loop features](../how-tos/human_in_the_loop/add-human-in-the-loop.md) to enable human intervention at any point in a workflow. This is especially useful in large language model (LLM)-driven applications where model output may require validation, correction, or additional context.
-
-<figure markdown="1">
-![image](../concepts/img/human_in_the_loop/tool-call-review.png){: style="max-height:400px"}
-</figure>
-
-!!! tip
-
-    For information on how to use human-in-the-loop, see [Enable human intervention](../how-tos/human_in_the_loop/add-human-in-the-loop.md) and [Human-in-the-loop using Server API](../cloud/how-tos/add-human-in-the-loop.md).
+LangGraph supports robust **human-in-the-loop (HIL)** workflows, enabling human intervention at any point in an automated process. This is especially useful in large language model (LLM)-driven applications where model output may require validation, correction, or additional context.
 
 ## Key capabilities
 
-* **Persistent execution state**: LangGraph allows you to pause execution **indefinitely** — for minutes, hours, or even days—until human input is received. This is possible because LangGraph checkpoints the graph state after each step, which allows the system to persist execution context and later resume the workflow, continuing from where it left off. This supports asynchronous human review or input without time constraints.
+* **Persistent execution state**: LangGraph checkpoints the graph state after each step, allowing execution to pause indefinitely at defined nodes. This supports asynchronous human review or input without time constraints.
 
 * **Flexible integration points**: HIL logic can be introduced at any point in the workflow. This allows targeted human involvement, such as approving API calls, correcting outputs, or guiding conversations.
 
-## Patterns
+## Typical use cases
 
-There are four typical design patterns that you can implement using `interrupt` and `Command`:
+1. [**🛠️ Reviewing tool calls**](../how-tos/human_in_the_loop/add-human-in-the-loop.md#review-tool-calls): Humans can review, edit, or approve tool calls requested by the LLM before tool execution.
+2. **✅ Validating LLM outputs**: Humans can review, edit, or approve content generated by the LLM.
+3. **💡 Providing context**: Enable the LLM to explicitly request human input for clarification or additional details or to support multi-turn conversations.
 
-- [Approve or reject](../how-tos/human_in_the_loop/add-human-in-the-loop.md#approve-or-reject): Pause the graph before a critical step, such as an API call, to review and approve the action. If the action is rejected, you can prevent the graph from executing the step, and potentially take an alternative action. This pattern often involves routing the graph based on the human's input.
-- [Edit graph state](../how-tos/human_in_the_loop/add-human-in-the-loop.md#review-and-edit-state): Pause the graph to review and edit the graph state. This is useful for correcting mistakes or updating the state with additional information. This pattern often involves updating the state with the human's input.
-- [Review tool calls](../how-tos/human_in_the_loop/add-human-in-the-loop.md#review-tool-calls): Pause the graph to review and edit tool calls requested by the LLM before tool execution.
-- [Validate human input](../how-tos/human_in_the_loop/add-human-in-the-loop.md#validate-human-input): Pause the graph to validate human input before proceeding with the next step.
+## Implementation
+
+* `interrupt` function: Pauses execution at a specific point, presents information for human review.
+* `Command` primitive: Used to resume execution with a value provided by the human.

docs/docs/concepts/langgraph_cli.md

@@ -9,18 +9,13 @@ search:
 
 ## Installation
 
-The LangGraph CLI can be installed via pip or [Homebrew](https://brew.sh/):
+The LangGraph CLI can be installed via pip:
 
 === "pip" 
     ```bash
     pip install langgraph-cli
     ```
 
-=== "Homebrew"
-    ```bash
-    brew install langgraph-cli
-    ```
-
 ## Commands
 
 LangGraph CLI provides the following core functionality:

docs/docs/concepts/langgraph_control_plane.md

@@ -19,7 +19,6 @@ From the control plane UI, you can:
 - Update a deployment.
 - Update environment variables for a deployment.
 - View build and server logs of a deployment.
-- View deployment metrics such as CPU and memory usage.
 - Delete a deployment.
 
 The Control Plane UI is embedded in [LangSmith](https://docs.smith.langchain.com/langgraph_cloud).
@@ -89,17 +88,6 @@ Infrastructure for deployments and revisions are provisioned and deployed asynch
 
 The control plane and [LangGraph Data Plane](./langgraph_data_plane.md) "listener" application coordinate to achieve asynchronous deployments.
 
-### Monitoring
-
-After a deployment is ready, the control plane monitors the deployment and records various metrics, such as:
-
-- CPU and memory usage of the deployment.
-- Number of container restarts.
-- Number of replicas (this will increase with [autoscaling](../concepts/langgraph_data_plane.md#autoscaling)).
-- [Postgres](../concepts/langgraph_data_plane.md#postgres) CPU, memory usage, and disk usage.
-
-These metrics are displayed as charts in the Control Plane UI.
-
 ### LangSmith Integration
 
 A [LangSmith](https://docs.smith.langchain.com/) tracing project is automatically created for each deployment. The tracing project has the same name as the deployment. When creating a deployment, the `LANGCHAIN_TRACING` and `LANGSMITH_API_KEY`/`LANGCHAIN_API_KEY` environment variables do not need to be specified; they are set automatically by the control plane.

docs/docs/concepts/langgraph_data_plane.md

@@ -56,7 +56,7 @@ This section describes various features of the data plane.
 
 1. CPU utilization
 1. Memory utilization
-1. Number of pending (in progress) [runs](./assistants.md#execution)
+1. Number of pending (in progress) [runs](../cloud/concepts/runs.md)
 
 For CPU utilization, the autoscaler targets 75% utilization. This means the autoscaler will scale the number of containers up or down to ensure that CPU utilization is at or near 75%. For memory utilization, the autoscaler targets 75% utilization as well.
 

docs/docs/concepts/langgraph_platform.md

@@ -17,7 +17,7 @@ Develop, deploy, scale, and manage agents with **LangGraph Platform** — the pu
 
 LangGraph Platform makes it easy to get your agent running in production —  whether it’s built with LangGraph or another framework — so you can focus on your app logic, not infrastructure. Deploy with one click to get a live endpoint, and use our robust APIs and built-in task queues to handle production scale. 
 
-- **[Streaming Support](../cloud/how-tos/streaming.md)**: As agents grow more sophisticated, they often benefit from streaming both token outputs and intermediate states back to the user. Without this, users are left waiting for potentially long operations with no feedback. LangGraph Server provides multiple streaming modes optimized for various application needs.
+- **[Streaming Support](../cloud/concepts/streaming.md)**: As agents grow more sophisticated, they often benefit from streaming both token outputs and intermediate states back to the user. Without this, users are left waiting for potentially long operations with no feedback. LangGraph Server provides multiple streaming modes optimized for various application needs.
 
 - **[Background Runs](../cloud/how-tos/background_run.md)**: For agents that take longer to process (e.g., hours), maintaining an open connection can be impractical. The LangGraph Server supports launching agent runs in the background and provides both polling endpoints and webhooks to monitor run status effectively.
  

docs/docs/concepts/langgraph_self_hosted_control_plane.md

@@ -3,7 +3,7 @@
 There are two versions of the self-hosted deployment: [Self-Hosted Data Plane](./deployment_options.md#self-hosted-data-plane) and [Self-Hosted Control Plane](./deployment_options.md#self-hosted-control-plane).
 
 !!! info "Important"
-    The Self-Hosted Control Plane deployment option is currently in beta stage and requires an [Enterprise](plans.md) plan.
+    The Self-Hosted Control Plane deployment option is currently in beta stage and requires an [Enterprise](../../concepts/plans.md) plan.
 
 ## Requirements
 

docs/docs/concepts/langgraph_self_hosted_data_plane.md

@@ -8,7 +8,7 @@ search:
 There are two versions of the self-hosted deployment: [Self-Hosted Data Plane](./deployment_options.md#self-hosted-data-plane) and [Self-Hosted Control Plane](./deployment_options.md#self-hosted-control-plane).
 
 !!! info "Important"
-    The Self-Hosted Data Plane deployment option is currently in beta stage and requires an [Enterprise](plans.md) plan.
+    The Self-Hosted Data Plane deployment option is currently in beta stage and requires an [Enterprise](../../concepts/plans.md) plan.
 
 ## Requirements
 

docs/docs/concepts/langgraph_server.md

@@ -7,7 +7,7 @@ search:
 
 **LangGraph Server** offers an API for creating and managing agent-based applications. It is built on the concept of [assistants](assistants.md), which are agents configured for specific tasks, and includes built-in [persistence](persistence.md#memory-store) and a **task queue**. This versatile API supports a wide range of agentic application use cases, from background processing to real-time interactions.
 
-Use LangGraph Server to create and manage [assistants](assistants.md), [threads](./persistence.md#threads), [runs](./assistants.md#execution), [cron jobs](../cloud/concepts/cron_jobs.md), [webhooks](../cloud/concepts/webhooks.md), and more.
+Use LangGraph Server to create and manage [assistants](assistants.md), [threads](../cloud/concepts/threads.md), [runs](../cloud/concepts/runs.md), [cron jobs](../cloud/concepts/cron_jobs.md), [webhooks](../cloud/concepts/webhooks.md), and more.
 
 !!! tip "API reference"
   
@@ -17,7 +17,7 @@ Use LangGraph Server to create and manage [assistants](assistants.md), [threads]
 
 There are two versions of LangGraph Server:
 
-- `Lite` is a limited version of the LangGraph Server that you can run locally or in a self-hosted manner (up to 1 million [nodes executed](../concepts/faq.md#what-does-nodes-executed-mean-for-langgraph-platform-usage) per year).
+- `Lite` is a limited version of the LangGraph Server that you can run locally or in a self-hosted manner (up to 1 million nodes executed per year).
 - `Enterprise` is the full version of the LangGraph Server. To use the `Enterprise` version, you must acquire a license key that you will need to specify when running the Docker image. To acquire a license key, please email sales@langchain.dev.
 
 Feature Differences:

docs/docs/concepts/langgraph_standalone_container.md

@@ -17,10 +17,6 @@ The Standalone Container deployment option is the least restrictive model for de
 | **Where is it hosted?** | n/a | Your cloud |
 | **Who provisions and manages it?** | n/a | You |
 
-!!! warning
-
-      LangGraph Platform should not be deployed in serverless environments. Scale to zero may cause task loss and scaling up will not work reliably.
-
 ## Architecture
 
 ![Standalone Container](./img/langgraph_platform_deployment_architecture.png)

docs/docs/concepts/langgraph_studio.md

@@ -24,7 +24,6 @@ Key features of LangGraph Studio:
 - [Manage assistants](../cloud/how-tos/studio/manage_assistants.md)
 - [Manage threads](../cloud/how-tos/threads_studio.md)
 - [Iterate on prompts](../cloud/how-tos/iterate_graph_studio.md)
-- [Run experiments over a dataset](../cloud/how-tos/studio/run_evals.md)
 - Manage [long term memory](memory.md)
 - Debug agent state via [time travel](time-travel.md)
 
@@ -42,4 +41,4 @@ Chat mode is a simpler UI for iterating on and testing chat-specific agents. It
 
 ## Learn more
 
-- See this guide on how to [get started](../cloud/how-tos/studio/quick_start.md) with LangGraph Studio.
+- See this guide on how to [get started](../cloud/how-tos/studio/quick_start.md) with LangGraph Studio.

docs/docs/concepts/memory.md

@@ -5,154 +5,182 @@ search:
 
 # Memory
 
-[Memory](../how-tos/memory/add-memory.md) is a system that remembers information about previous interactions. For AI agents, memory is crucial because it lets them remember previous interactions, learn from feedback, and adapt to user preferences. As agents tackle more complex tasks with numerous user interactions, this capability becomes essential for both efficiency and user satisfaction.
+## What is Memory?
 
-This conceptual guide covers two types of memory, based on their recall scope:
+[Memory](https://pmc.ncbi.nlm.nih.gov/articles/PMC10410470/) is a cognitive function that allows people to store, retrieve, and use information to understand their present and future. Consider the frustration of working with a colleague who forgets everything you tell them, requiring constant repetition! As AI agents undertake more complex tasks involving numerous user interactions, equipping them with memory becomes equally crucial for efficiency and user satisfaction. With memory, agents can learn from feedback and adapt to users' preferences. This guide covers two types of memory based on recall scope:
 
-- [Short-term memory](#short-term-memory), or [thread](persistence.md#threads)-scoped memory, tracks the ongoing conversation by maintaining message history within a session. LangGraph manages short-term memory as a part of your agent's [state](low_level.md#state). State is persisted to a database using a [checkpointer](persistence.md#checkpoints) so the thread can be resumed at any time. Short-term memory updates when the graph is invoked or a step is completed, and the State is read at the start of each step.
+**Short-term memory**, or [thread](persistence.md#threads)-scoped memory, can be recalled at any time **from within** a single conversational thread with a user. LangGraph manages short-term memory as a part of your agent's [state](low_level.md#state). State is persisted to a database using a [checkpointer](persistence.md#checkpoints) so the thread can be resumed at any time. Short-term memory updates when the graph is invoked or a step is completed, and the State is read at the start of each step.
 
-- [Long-term memory](#long-term-memory) stores user-specific or application-level data across sessions and is shared _across_ conversational threads. It can be recalled _at any time_ and _in any thread_. Memories are scoped to any custom namespace, not just within a single thread ID. LangGraph provides [stores](persistence.md#memory-store) ([reference doc](https://langchain-ai.github.io/langgraph/reference/store/#langgraph.store.base.BaseStore)) to let you save and recall long-term memories.
+**Long-term memory** is shared **across** conversational threads. It can be recalled _at any time_ and **in any thread**. Memories are scoped to any custom namespace, not just within a single thread ID. LangGraph provides [stores](persistence.md#memory-store) ([reference doc](https://langchain-ai.github.io/langgraph/reference/store/#langgraph.store.base.BaseStore)) to let you save and recall long-term memories.
+
+Both are important to understand and implement for your application.
 
 ![](img/memory/short-vs-long.png)
 
-
 ## Short-term memory
 
-[Short-term memory](../how-tos/memory/add-memory.md#add-short-term-memory) lets your application remember previous interactions within a single [thread](persistence.md#threads) or conversation. A [thread](persistence.md#threads) organizes multiple interactions in a session, similar to the way email groups messages in a single conversation.
+Short-term memory lets your application remember previous interactions within a single [thread](persistence.md#threads) or conversation. A [thread](persistence.md#threads) organizes multiple interactions in a session, similar to the way email groups messages in a single conversation.
 
 LangGraph manages short-term memory as part of the agent's state, persisted via thread-scoped checkpoints. This state can normally include the conversation history along with other stateful data, such as uploaded files, retrieved documents, or generated artifacts. By storing these in the graph's state, the bot can access the full context for a given conversation while maintaining separation between different threads.
 
-### Manage short-term memory
+Since conversation history is the most common form of representing short-term memory, in the next section, we will cover techniques for managing conversation history when the list of messages becomes **long**. If you want to stick to the high-level concepts, continue on to the [long-term memory](#long-term-memory) section.
 
-Conversation history is the most common form of short-term memory, and long conversations pose a challenge to today's LLMs. A full history may not fit inside an LLM's context window, resulting in an irrecoverable error. Even if your LLM supports the full context length, most LLMs still perform poorly over long contexts. They get "distracted" by stale or off-topic content, all while suffering from slower response times and higher costs.
+### Managing long conversation history
 
-Chat models accept context using messages, which include developer provided instructions (a system message) and user inputs (human messages). In chat applications, messages alternate between human inputs and model responses, resulting in a list of messages that grows longer over time. Because context windows are limited and token-rich message lists can be costly, many applications can benefit from using techniques to manually remove or forget stale information.
+Long conversations pose a challenge to today's LLMs. The full history may not even fit inside an LLM's context window, resulting in an irrecoverable error. Even _if_ your LLM technically supports the full context length, most LLMs still perform poorly over long contexts. They get "distracted" by stale or off-topic content, all while suffering from slower response times and higher costs.
+
+Managing short-term memory is an exercise of balancing [precision & recall](https://en.wikipedia.org/wiki/Precision_and_recall#:~:text=Precision%20can%20be%20seen%20as,irrelevant%20ones%20are%20also%20returned) with your application's other performance requirements (latency & cost). As always, it's important to think critically about how you represent information for your LLM and to look at your data. We cover a few common techniques for managing message lists below and hope to provide sufficient context for you to pick the best tradeoffs for your application:
+
+- [Editing message lists](#editing-message-lists): How to think about trimming and filtering a list of messages before passing to language model.
+- [Summarizing past conversations](#summarizing-past-conversations): A common technique to use when you don't just want to filter the list of messages.
+
+### Editing message lists
+
+Chat models accept context using [messages](https://python.langchain.com/docs/concepts/#messages), which include developer provided instructions (a system message) and user inputs (human messages). In chat applications, messages alternate between human inputs and model responses, resulting in a list of messages that grows longer over time. Because context windows are limited and token-rich message lists can be costly, many applications can benefit from using techniques to manually remove or forget stale information.
 
 ![](img/memory/filter.png)
 
-For more information on common techniques for managing messages, see the [Add and manage memory](../how-tos/memory/add-memory.md#manage-short-term-memory) guide.
+The most direct approach is to remove old messages from a list (similar to a [least-recently used cache](https://en.wikipedia.org/wiki/Page_replacement_algorithm#Least_recently_used)).
+
+The typical technique for deleting content from a list in LangGraph is to return an update from a node telling the system to delete some portion of the list. You get to define what this update looks like, but a common approach would be to let you return an object or dictionary specifying which values to retain.
+
+```python
+def manage_list(existing: list, updates: Union[list, dict]):
+    if isinstance(updates, list):
+        # Normal case, add to the history
+        return existing + updates
+    elif isinstance(updates, dict) and updates["type"] == "keep":
+        # You get to decide what this looks like.
+        # For example, you could simplify and just accept a string "DELETE"
+        # and clear the entire list.
+        return existing[updates["from"]:updates["to"]]
+    # etc. We define how to interpret updates
+
+class State(TypedDict):
+    my_list: Annotated[list, manage_list]
+
+def my_node(state: State):
+    return {
+        # We return an update for the field "my_list" saying to
+        # keep only values from index -5 to the end (deleting the rest)
+        "my_list": {"type": "keep", "from": -5, "to": None}
+    }
+```
+
+LangGraph will call the `manage_list` "[reducer](low_level.md#reducers)" function any time an update is returned under the key "my_list". Within that function, we define what types of updates to accept. Typically, messages will be added to the existing list (the conversation will grow); however, we've also added support to accept a dictionary that lets you "keep" certain parts of the state. This lets you programmatically drop old message context.
+
+Another common approach is to let you return a list of "remove" objects that specify the IDs of all messages to delete. If you're using the LangChain messages and the [`add_messages`](https://langchain-ai.github.io/langgraph/reference/graphs/#langgraph.graph.message.add_messages) reducer (or `MessagesState`, which uses the same underlying functionality) in LangGraph, you can do this using a `RemoveMessage`.
+
+```python
+from langchain_core.messages import RemoveMessage, AIMessage
+from langgraph.graph import add_messages
+# ... other imports
+
+class State(TypedDict):
+    # add_messages will default to upserting messages by ID to the existing list
+    # if a RemoveMessage is returned, it will delete the message in the list by ID
+    messages: Annotated[list, add_messages]
+
+def my_node_1(state: State):
+    # Add an AI message to the `messages` list in the state
+    return {"messages": [AIMessage(content="Hi")]}
+
+def my_node_2(state: State):
+    # Delete all but the last 2 messages from the `messages` list in the state
+    delete_messages = [RemoveMessage(id=m.id) for m in state['messages'][:-2]]
+    return {"messages": delete_messages}
+
+```
+
+In the example above, the `add_messages` reducer allows us to [append](https://langchain-ai.github.io/langgraph/concepts/low_level/#serialization) new messages to the `messages` state key as shown in `my_node_1`. When it sees a `RemoveMessage`, it will delete the message with that ID from the list (and the RemoveMessage will then be discarded). For more information on LangChain-specific message handling, check out [this how-to on using `RemoveMessage` ](https://langchain-ai.github.io/langgraph/how-tos/memory/delete-messages/).
+
+See this how-to [guide](https://langchain-ai.github.io/langgraph/how-tos/memory/manage-conversation-history/) and module 2 from our [LangChain Academy](https://github.com/langchain-ai/langchain-academy/tree/main/module-2) course for example usage.
+
+### Summarizing past conversations
+
+The problem with trimming or removing messages, as shown above, is that we may lose information from culling of the message queue. Because of this, some applications benefit from a more sophisticated approach of summarizing the message history using a chat model.
+
+![](img/memory/summary.png)
+
+Simple prompting and orchestration logic can be used to achieve this. As an example, in LangGraph we can extend the [MessagesState](https://langchain-ai.github.io/langgraph/concepts/low_level/#working-with-messages-in-graph-state) to include a `summary` key.
+
+```python
+from langgraph.graph import MessagesState
+class State(MessagesState):
+    summary: str
+```
+
+Then, we can generate a summary of the chat history, using any existing summary as context for the next summary. This `summarize_conversation` node can be called after some number of messages have accumulated in the `messages` state key.
+
+```python
+def summarize_conversation(state: State):
+
+    # First, we get any existing summary
+    summary = state.get("summary", "")
+
+    # Create our summarization prompt
+    if summary:
+
+        # A summary already exists
+        summary_message = (
+            f"This is a summary of the conversation to date: {summary}\n\n"
+            "Extend the summary by taking into account the new messages above:"
+        )
+
+    else:
+        summary_message = "Create a summary of the conversation above:"
+
+    # Add prompt to our history
+    messages = state["messages"] + [HumanMessage(content=summary_message)]
+    response = model.invoke(messages)
+
+    # Delete all but the 2 most recent messages
+    delete_messages = [RemoveMessage(id=m.id) for m in state["messages"][:-2]]
+    return {"summary": response.content, "messages": delete_messages}
+```
+
+See this how-to [here](https://langchain-ai.github.io/langgraph/how-tos/memory/add-summary-conversation-history/) and module 2 from our [LangChain Academy](https://github.com/langchain-ai/langchain-academy/tree/main/module-2) course for example usage.
+
+### Knowing **when** to remove messages
+
+Most LLMs have a maximum supported context window (denominated in tokens). A simple way to decide when to truncate messages is to count the tokens in the message history and truncate whenever it approaches that limit. Naive truncation is straightforward to implement on your own, though there are a few "gotchas". Some model APIs further restrict the sequence of message types (must start with human message, cannot have consecutive messages of the same type, etc.). If you're using LangChain, you can use the [`trim_messages`](https://python.langchain.com/docs/how_to/trim_messages/#trimming-based-on-token-count) utility and specify the number of tokens to keep from the list, as well as the `strategy` (e.g., keep the last `max_tokens`) to use for handling the boundary.
+
+Below is an example.
+
+```python
+from langchain_core.messages import trim_messages
+trim_messages(
+    messages,
+    # Keep the last <= n_count tokens of the messages.
+    strategy="last",
+    # Remember to adjust based on your model
+    # or else pass a custom token_encoder
+    token_counter=ChatOpenAI(model="gpt-4"),
+    # Remember to adjust based on the desired conversation
+    # length
+    max_tokens=45,
+    # Most chat models expect that chat history starts with either:
+    # (1) a HumanMessage or
+    # (2) a SystemMessage followed by a HumanMessage
+    start_on="human",
+    # Most chat models expect that chat history ends with either:
+    # (1) a HumanMessage or
+    # (2) a ToolMessage
+    end_on=("human", "tool"),
+    # Usually, we want to keep the SystemMessage
+    # if it's present in the original history.
+    # The SystemMessage has special instructions for the model.
+    include_system=True,
+)
+```
 
 ## Long-term memory
 
-[Long-term memory](../how-tos/memory/add-memory.md#add-long-term-memory) in LangGraph allows systems to retain information across different conversations or sessions. Unlike short-term memory, which is **thread-scoped**, long-term memory is saved within custom "namespaces."
+Long-term memory in LangGraph allows systems to retain information across different conversations or sessions. Unlike short-term memory, which is **thread-scoped**, long-term memory is saved within custom "namespaces."
 
-Long-term memory is a complex challenge without a one-size-fits-all solution. However, the following questions provide a framework to help you navigate the different techniques:
+### Storing memories
 
-- [What is the type of memory?](#memory-types) Humans use memories to remember facts ([semantic memory](#semantic-memory)), experiences ([episodic memory](#episodic-memory)), and rules ([procedural memory](#procedural-memory)). AI agents can use memory in the same ways. For example, AI agents can use memory to remember specific facts about a user to accomplish a task.
-
-- [When do you want to update memories?](#writing-memories) Memory can be updated as part of an agent's application logic (e.g., "on the hot path"). In this case, the agent typically decides to remember facts before responding to a user. Alternatively, memory can be updated as a background task (logic that runs in the background / asynchronously and generates memories). We explain the tradeoffs between these approaches in the [section below](#writing-memories).
-
-### Memory types
-
-Different applications require various types of memory. Although the analogy isn't perfect, examining [human memory types](https://www.psychologytoday.com/us/basics/memory/types-of-memory?ref=blog.langchain.dev) can be insightful. Some research (e.g., the [CoALA paper](https://arxiv.org/pdf/2309.02427)) have even mapped these human memory types to those used in AI agents.
-
-| Memory Type | What is Stored | Human Example | Agent Example |
-|-------------|----------------|---------------|---------------|
-| [Semantic](#semantic-memory) | Facts | Things I learned in school | Facts about a user |
-| [Episodic](#episodic-memory) | Experiences | Things I did | Past agent actions |
-| [Procedural](#procedural-memory) | Instructions | Instincts or motor skills | Agent system prompt |
-
-#### Semantic memory
-
-[Semantic memory](https://en.wikipedia.org/wiki/Semantic_memory), both in humans and AI agents, involves the retention of specific facts and concepts. In humans, it can include information learned in school and the understanding of concepts and their relationships. For AI agents, semantic memory is often used to personalize applications by remembering facts or concepts from past interactions. 
-
-!!! note
-
-    Semantic memory is different from "semantic search," which is a technique for finding similar content using "meaning" (usually as embeddings). Semantic memory is a term from psychology, referring to storing facts and knowledge, while semantic search is a method for retrieving information based on meaning rather than exact matches.
-
-
-##### Profile
-
-Semantic memories can be managed in different ways. For example, memories can be a single, continuously updated "profile" of well-scoped and specific information about a user, organization, or other entity (including the agent itself). A profile is generally just a JSON document with various key-value pairs you've selected to represent your domain. 
-
-When remembering a profile, you will want to make sure that you are **updating** the profile each time. As a result, you will want to pass in the previous profile and [ask the model to generate a new profile](https://github.com/langchain-ai/memory-template) (or some [JSON patch](https://github.com/hinthornw/trustcall) to apply to the old profile). This can be become error-prone as the profile gets larger, and may benefit from splitting a profile into multiple documents or **strict** decoding when generating documents to ensure the memory schemas remains valid.
-
-![](img/memory/update-profile.png)
-
-##### Collection
-
-Alternatively, memories can be a collection of documents that are continuously updated and extended over time. Each individual memory can be more narrowly scoped and easier to generate, which means that you're less likely to **lose** information over time. It's easier for an LLM to generate _new_ objects for new information than reconcile new information with an existing profile. As a result, a document collection tends to lead to [higher recall downstream](https://en.wikipedia.org/wiki/Precision_and_recall).
-
-However, this shifts some complexity memory updating. The model must now _delete_ or _update_ existing items in the list, which can be tricky. In addition, some models may default to over-inserting and others may default to over-updating. See the [Trustcall](https://github.com/hinthornw/trustcall) package for one way to manage this and consider evaluation (e.g., with a tool like [LangSmith](https://docs.smith.langchain.com/tutorials/Developers/evaluation)) to help you tune the behavior.
-
-Working with document collections also shifts complexity to memory **search** over the list. The `Store` currently supports both [semantic search](https://langchain-ai.github.io/langgraph/reference/store/#langgraph.store.base.SearchOp.query) and [filtering by content](https://langchain-ai.github.io/langgraph/reference/store/#langgraph.store.base.SearchOp.filter).
-
-Finally, using a collection of memories can make it challenging to provide comprehensive context to the model. While individual memories may follow a specific schema, this structure might not capture the full context or relationships between memories. As a result, when using these memories to generate responses, the model may lack important contextual information that would be more readily available in a unified profile approach.
-
-![](img/memory/update-list.png)
-
-Regardless of memory management approach, the central point is that the agent will use the semantic memories to [ground its responses](https://python.langchain.com/docs/concepts/rag/), which often leads to more personalized and relevant interactions.
-
-#### Episodic memory
-
-[Episodic memory](https://en.wikipedia.org/wiki/Episodic_memory), in both humans and AI agents, involves recalling past events or actions. The [CoALA paper](https://arxiv.org/pdf/2309.02427) frames this well: facts can be written to semantic memory, whereas *experiences* can be written to episodic memory. For AI agents, episodic memory is often used to help an agent remember how to accomplish a task. 
-
-In practice, episodic memories are often implemented through [few-shot example prompting](https://python.langchain.com/docs/concepts/few_shot_prompting/), where agents learn from past sequences to perform tasks correctly. Sometimes it's easier to "show" than "tell" and LLMs learn well from examples. Few-shot learning lets you ["program"](https://x.com/karpathy/status/1627366413840322562) your LLM by updating the prompt with input-output examples to illustrate the intended behavior. While various [best-practices](https://python.langchain.com/docs/concepts/#1-generating-examples) can be used to generate few-shot examples, often the challenge lies in selecting the most relevant examples based on user input.
-
-Note that the memory [store](persistence.md#memory-store) is just one way to store data as few-shot examples. If you want to have more developer involvement, or tie few-shots more closely to your evaluation harness, you can also use a [LangSmith Dataset](https://docs.smith.langchain.com/evaluation/how_to_guides/datasets/index_datasets_for_dynamic_few_shot_example_selection) to store your data. Then dynamic few-shot example selectors can be used out-of-the box to achieve this same goal. LangSmith will index the dataset for you and enable retrieval of few shot examples that are most relevant to the user input based upon keyword similarity ([using a BM25-like algorithm](https://docs.smith.langchain.com/how_to_guides/datasets/index_datasets_for_dynamic_few_shot_example_selection) for keyword based similarity). 
-
-See this how-to [video](https://www.youtube.com/watch?v=37VaU7e7t5o) for example usage of dynamic few-shot example selection in LangSmith. Also, see this [blog post](https://blog.langchain.dev/few-shot-prompting-to-improve-tool-calling-performance/) showcasing few-shot prompting to improve tool calling performance and this [blog post](https://blog.langchain.dev/aligning-llm-as-a-judge-with-human-preferences/) using few-shot example to align an LLMs to human preferences.
-
-#### Procedural memory
-
-[Procedural memory](https://en.wikipedia.org/wiki/Procedural_memory), in both humans and AI agents, involves remembering the rules used to perform tasks. In humans, procedural memory is like the internalized knowledge of how to perform tasks, such as riding a bike via basic motor skills and balance. Episodic memory, on the other hand, involves recalling specific experiences, such as the first time you successfully rode a bike without training wheels or a memorable bike ride through a scenic route. For AI agents, procedural memory is a combination of model weights, agent code, and agent's prompt that collectively determine the agent's functionality. 
-
-In practice, it is fairly uncommon for agents to modify their model weights or rewrite their code. However, it is more common for agents to modify their own prompts. 
-
-One effective approach to refining an agent's instructions is through ["Reflection"](https://blog.langchain.dev/reflection-agents/) or meta-prompting. This involves prompting the agent with its current instructions (e.g., the system prompt) along with recent conversations or explicit user feedback. The agent then refines its own instructions based on this input. This method is particularly useful for tasks where instructions are challenging to specify upfront, as it allows the agent to learn and adapt from its interactions.
-
-For example, we built a [Tweet generator](https://www.youtube.com/watch?v=Vn8A3BxfplE) using external feedback and prompt re-writing to produce high-quality paper summaries for Twitter. In this case, the specific summarization prompt was difficult to specify *a priori*, but it was fairly easy for a user to critique the generated Tweets and provide feedback on how to improve the summarization process. 
-
-The below pseudo-code shows how you might implement this with the LangGraph memory [store](persistence.md#memory-store), using the store to save a prompt, the `update_instructions` node to get the current prompt (as well as feedback from the conversation with the user captured in `state["messages"]`), update the prompt, and save the new prompt back to the store. Then, the `call_model` get the updated prompt from the store and uses it to generate a response.
-
-```python
-# Node that *uses* the instructions
-def call_model(state: State, store: BaseStore):
-    namespace = ("agent_instructions", )
-    instructions = store.get(namespace, key="agent_a")[0]
-    # Application logic
-    prompt = prompt_template.format(instructions=instructions.value["instructions"])
-    ...
-
-# Node that updates instructions
-def update_instructions(state: State, store: BaseStore):
-    namespace = ("instructions",)
-    current_instructions = store.search(namespace)[0]
-    # Memory logic
-    prompt = prompt_template.format(instructions=instructions.value["instructions"], conversation=state["messages"])
-    output = llm.invoke(prompt)
-    new_instructions = output['new_instructions']
-    store.put(("agent_instructions",), "agent_a", {"instructions": new_instructions})
-    ...
-```
-
-![](img/memory/update-instructions.png)
-
-### Writing memories
-
-There are two primary methods for agents to write memories: ["in the hot path"](#in-the-hot-path) and ["in the background"](#in-the-background).
-
-![](img/memory/hot_path_vs_background.png)
-
-#### In the hot path
-
-Creating memories during runtime offers both advantages and challenges. On the positive side, this approach allows for real-time updates, making new memories immediately available for use in subsequent interactions. It also enables transparency, as users can be notified when memories are created and stored.
-
-However, this method also presents challenges. It may increase complexity if the agent requires a new tool to decide what to commit to memory. In addition, the process of reasoning about what to save to memory can impact agent latency. Finally, the agent must multitask between memory creation and its other responsibilities, potentially affecting the quantity and quality of memories created.
-
-As an example, ChatGPT uses a [save_memories](https://openai.com/index/memory-and-new-controls-for-chatgpt/) tool to upsert memories as content strings, deciding whether and how to use this tool with each user message. See our [memory-agent](https://github.com/langchain-ai/memory-agent) template as an reference implementation.
-
-#### In the background
-
-Creating memories as a separate background task offers several advantages. It eliminates latency in the primary application, separates application logic from memory management, and allows for more focused task completion by the agent. This approach also provides flexibility in timing memory creation to avoid redundant work.
-
-However, this method has its own challenges. Determining the frequency of memory writing becomes crucial, as infrequent updates may leave other threads without new context. Deciding when to trigger memory formation is also important. Common strategies include scheduling after a set time period (with rescheduling if new events occur), using a cron schedule, or allowing manual triggers by users or the application logic.
-
-See our [memory-service](https://github.com/langchain-ai/memory-template) template as an reference implementation.
-
-### Memory storage
-
-LangGraph stores long-term memories as JSON documents in a [store](persistence.md#memory-store). Each memory is organized under a custom `namespace` (similar to a folder) and a distinct `key` (like a file name). Namespaces often include user or org IDs or other labels that makes it easier to organize information. This structure enables hierarchical organization of memories. Cross-namespace searching is then supported through content filters.
+LangGraph stores long-term memories as JSON documents in a [store](persistence.md#memory-store) ([reference doc](https://langchain-ai.github.io/langgraph/reference/store/#langgraph.store.base.BaseStore)). Each memory is organized under a custom `namespace` (similar to a folder) and a distinct `key` (like a filename). Namespaces often include user or org IDs or other labels that makes it easier to organize information. This structure enables hierarchical organization of memories. Cross-namespace searching is then supported through content filters. See the example below for an example.
 
 ```python
 from langgraph.store.memory import InMemoryStore
@@ -187,4 +215,120 @@ items = store.search(
 )
 ```
 
-For more information about the memory store, see the [Persistence](persistence.md#memory-store) guide.
+### Framework for thinking about long-term memory
+
+Long-term memory is a complex challenge without a one-size-fits-all solution. However, the following questions provide a structure framework to help you navigate the different techniques:
+
+**What is the type of memory?**
+
+Humans use memories to remember [facts](https://en.wikipedia.org/wiki/Semantic_memory), [experiences](https://en.wikipedia.org/wiki/Episodic_memory), and [rules](https://en.wikipedia.org/wiki/Procedural_memory). AI agents can use memory in the same ways. For example, AI agents can use memory to remember specific facts about a user to accomplish a task. We expand on several types of memories in the [section below](#memory-types).
+
+**When do you want to update memories?**
+
+Memory can be updated as part of an agent's application logic (e.g. "on the hot path"). In this case, the agent typically decides to remember facts before responding to a user. Alternatively, memory can be updated as a background task (logic that runs in the background / asynchronously and generates memories). We explain the tradeoffs between these approaches in the [section below](#writing-memories).
+
+## Memory types
+
+Different applications require various types of memory. Although the analogy isn't perfect, examining [human memory types](https://www.psychologytoday.com/us/basics/memory/types-of-memory?ref=blog.langchain.dev) can be insightful. Some research (e.g., the [CoALA paper](https://arxiv.org/pdf/2309.02427)) have even mapped these human memory types to those used in AI agents.
+
+| Memory Type | What is Stored | Human Example | Agent Example |
+|-------------|----------------|---------------|---------------|
+| Semantic | Facts | Things I learned in school | Facts about a user |
+| Episodic | Experiences | Things I did | Past agent actions |
+| Procedural | Instructions | Instincts or motor skills | Agent system prompt |
+
+### Semantic Memory
+
+[Semantic memory](https://en.wikipedia.org/wiki/Semantic_memory), both in humans and AI agents, involves the retention of specific facts and concepts. In humans, it can include information learned in school and the understanding of concepts and their relationships. For AI agents, semantic memory is often used to personalize applications by remembering facts or concepts from past interactions. 
+
+> Note: Not to be confused with "semantic search" which is a technique for finding similar content using "meaning" (usually as embeddings). Semantic memory is a term from psychology, referring to storing facts and knowledge, while semantic search is a method for retrieving information based on meaning rather than exact matches.
+
+
+#### Profile
+
+Semantic memories can be managed in different ways. For example, memories can be a single, continuously updated "profile" of well-scoped and specific information about a user, organization, or other entity (including the agent itself). A profile is generally just a JSON document with various key-value pairs you've selected to represent your domain. 
+
+When remembering a profile, you will want to make sure that you are **updating** the profile each time. As a result, you will want to pass in the previous profile and [ask the model to generate a new profile](https://github.com/langchain-ai/memory-template) (or some [JSON patch](https://github.com/hinthornw/trustcall) to apply to the old profile). This can be become error-prone as the profile gets larger, and may benefit from splitting a profile into multiple documents or **strict** decoding when generating documents to ensure the memory schemas remains valid.
+
+![](img/memory/update-profile.png)
+
+#### Collection
+
+Alternatively, memories can be a collection of documents that are continuously updated and extended over time. Each individual memory can be more narrowly scoped and easier to generate, which means that you're less likely to **lose** information over time. It's easier for an LLM to generate _new_ objects for new information than reconcile new information with an existing profile. As a result, a document collection tends to lead to [higher recall downstream](https://en.wikipedia.org/wiki/Precision_and_recall).
+
+However, this shifts some complexity memory updating. The model must now _delete_ or _update_ existing items in the list, which can be tricky. In addition, some models may default to over-inserting and others may default to over-updating. See the [Trustcall](https://github.com/hinthornw/trustcall) package for one way to manage this and consider evaluation (e.g., with a tool like [LangSmith](https://docs.smith.langchain.com/tutorials/Developers/evaluation)) to help you tune the behavior.
+
+Working with document collections also shifts complexity to memory **search** over the list. The `Store` currently supports both [semantic search](https://langchain-ai.github.io/langgraph/reference/store/#langgraph.store.base.SearchOp.query) and [filtering by content](https://langchain-ai.github.io/langgraph/reference/store/#langgraph.store.base.SearchOp.filter).
+
+Finally, using a collection of memories can make it challenging to provide comprehensive context to the model. While individual memories may follow a specific schema, this structure might not capture the full context or relationships between memories. As a result, when using these memories to generate responses, the model may lack important contextual information that would be more readily available in a unified profile approach.
+
+![](img/memory/update-list.png)
+
+Regardless of memory management approach, the central point is that the agent will use the semantic memories to [ground its responses](https://python.langchain.com/docs/concepts/rag/), which often leads to more personalized and relevant interactions.
+
+### Episodic Memory
+
+[Episodic memory](https://en.wikipedia.org/wiki/Episodic_memory), in both humans and AI agents, involves recalling past events or actions. The [CoALA paper](https://arxiv.org/pdf/2309.02427) frames this well: facts can be written to semantic memory, whereas *experiences* can be written to episodic memory. For AI agents, episodic memory is often used to help an agent remember how to accomplish a task. 
+
+In practice, episodic memories are often implemented through [few-shot example prompting](https://python.langchain.com/docs/concepts/few_shot_prompting/), where agents learn from past sequences to perform tasks correctly. Sometimes it's easier to "show" than "tell" and LLMs learn well from examples. Few-shot learning lets you ["program"](https://x.com/karpathy/status/1627366413840322562) your LLM by updating the prompt with input-output examples to illustrate the intended behavior. While various [best-practices](https://python.langchain.com/docs/concepts/#1-generating-examples) can be used to generate few-shot examples, often the challenge lies in selecting the most relevant examples based on user input.
+
+Note that the memory [store](persistence.md#memory-store) is just one way to store data as few-shot examples. If you want to have more developer involvement, or tie few-shots more closely to your evaluation harness, you can also use a [LangSmith Dataset](https://docs.smith.langchain.com/evaluation/how_to_guides/datasets/index_datasets_for_dynamic_few_shot_example_selection) to store your data. Then dynamic few-shot example selectors can be used out-of-the box to achieve this same goal. LangSmith will index the dataset for you and enable retrieval of few shot examples that are most relevant to the user input based upon keyword similarity ([using a BM25-like algorithm](https://docs.smith.langchain.com/how_to_guides/datasets/index_datasets_for_dynamic_few_shot_example_selection) for keyword based similarity). 
+
+See this how-to [video](https://www.youtube.com/watch?v=37VaU7e7t5o) for example usage of dynamic few-shot example selection in LangSmith. Also, see this [blog post](https://blog.langchain.dev/few-shot-prompting-to-improve-tool-calling-performance/) showcasing few-shot prompting to improve tool calling performance and this [blog post](https://blog.langchain.dev/aligning-llm-as-a-judge-with-human-preferences/) using few-shot example to align an LLMs to human preferences.
+
+### Procedural Memory
+
+[Procedural memory](https://en.wikipedia.org/wiki/Procedural_memory), in both humans and AI agents, involves remembering the rules used to perform tasks. In humans, procedural memory is like the internalized knowledge of how to perform tasks, such as riding a bike via basic motor skills and balance. Episodic memory, on the other hand, involves recalling specific experiences, such as the first time you successfully rode a bike without training wheels or a memorable bike ride through a scenic route. For AI agents, procedural memory is a combination of model weights, agent code, and agent's prompt that collectively determine the agent's functionality. 
+
+In practice, it is fairly uncommon for agents to modify their model weights or rewrite their code. However, it is more common for agents to modify their own prompts. 
+
+One effective approach to refining an agent's instructions is through ["Reflection"](https://blog.langchain.dev/reflection-agents/) or meta-prompting. This involves prompting the agent with its current instructions (e.g., the system prompt) along with recent conversations or explicit user feedback. The agent then refines its own instructions based on this input. This method is particularly useful for tasks where instructions are challenging to specify upfront, as it allows the agent to learn and adapt from its interactions.
+
+For example, we built a [Tweet generator](https://www.youtube.com/watch?v=Vn8A3BxfplE) using external feedback and prompt re-writing to produce high-quality paper summaries for Twitter. In this case, the specific summarization prompt was difficult to specify *a priori*, but it was fairly easy for a user to critique the generated Tweets and provide feedback on how to improve the summarization process. 
+
+The below pseudo-code shows how you might implement this with the LangGraph memory [store](persistence.md#memory-store), using the store to save a prompt, the `update_instructions` node to get the current prompt (as well as feedback from the conversation with the user captured in `state["messages"]`), update the prompt, and save the new prompt back to the store. Then, the `call_model` get the updated prompt from the store and uses it to generate a response.
+
+```python
+# Node that *uses* the instructions
+def call_model(state: State, store: BaseStore):
+    namespace = ("agent_instructions", )
+    instructions = store.get(namespace, key="agent_a")[0]
+    # Application logic
+    prompt = prompt_template.format(instructions=instructions.value["instructions"])
+    ...
+
+# Node that updates instructions
+def update_instructions(state: State, store: BaseStore):
+    namespace = ("instructions",)
+    current_instructions = store.search(namespace)[0]
+    # Memory logic
+    prompt = prompt_template.format(instructions=instructions.value["instructions"], conversation=state["messages"])
+    output = llm.invoke(prompt)
+    new_instructions = output['new_instructions']
+    store.put(("agent_instructions",), "agent_a", {"instructions": new_instructions})
+    ...
+```
+
+![](img/memory/update-instructions.png)
+
+## Writing memories
+
+While [humans often form long-term memories during sleep](https://medicine.yale.edu/news-article/sleeps-crucial-role-in-preserving-memory/), AI agents need a different approach. When and how should agents create new memories? There are at least two primary methods for agents to write memories: "on the hot path" and "in the background".
+
+![](img/memory/hot_path_vs_background.png)
+
+### Writing memories in the hot path
+
+Creating memories during runtime offers both advantages and challenges. On the positive side, this approach allows for real-time updates, making new memories immediately available for use in subsequent interactions. It also enables transparency, as users can be notified when memories are created and stored.
+
+However, this method also presents challenges. It may increase complexity if the agent requires a new tool to decide what to commit to memory. In addition, the process of reasoning about what to save to memory can impact agent latency. Finally, the agent must multitask between memory creation and its other responsibilities, potentially affecting the quantity and quality of memories created.
+
+As an example, ChatGPT uses a [save_memories](https://openai.com/index/memory-and-new-controls-for-chatgpt/) tool to upsert memories as content strings, deciding whether and how to use this tool with each user message. See our [memory-agent](https://github.com/langchain-ai/memory-agent) template as an reference implementation.
+
+### Writing memories in the background
+
+Creating memories as a separate background task offers several advantages. It eliminates latency in the primary application, separates application logic from memory management, and allows for more focused task completion by the agent. This approach also provides flexibility in timing memory creation to avoid redundant work.
+
+However, this method has its own challenges. Determining the frequency of memory writing becomes crucial, as infrequent updates may leave other threads without new context. Deciding when to trigger memory formation is also important. Common strategies include scheduling after a set time period (with rescheduling if new events occur), using a cron schedule, or allowing manual triggers by users or the application logic.
+
+See our [memory-service](https://github.com/langchain-ai/memory-template) template as an reference implementation.

docs/docs/concepts/multi_agent.md

@@ -87,7 +87,6 @@ One of the most common agent types is a [tool-calling agent](../agents/overview.
 ```python
 from langchain_core.tools import tool
 
-@tool
 def transfer_to_bob():
     """Transfer to bob."""
     return Command(
@@ -376,13 +375,13 @@ The most common way for agents to communicate is via a shared state channel, typ
 
 #### Sharing full thought process
 
-Agents can **share the full history** of their thought process (i.e., "scratchpad") with all other agents. This "scratchpad" would typically look like a [list of messages](./low_level.md#why-use-messages). The benefit of sharing the full thought process is that it might help other agents make better decisions and improve reasoning ability for the system as a whole. The downside is that as the number of agents and their complexity grows, the "scratchpad" will grow quickly and might require additional strategies for [memory management](../how-tos/memory/add-memory.md).
+Agents can **share the full history** of their thought process (i.e., "scratchpad") with all other agents. This "scratchpad" would typically look like a [list of messages](./low_level.md#why-use-messages). The benefit of sharing the full thought process is that it might help other agents make better decisions and improve reasoning ability for the system as a whole. The downside is that as the number of agents and their complexity grows, the "scratchpad" will grow quickly and might require additional strategies for [memory management](./memory.md/#managing-long-conversation-history).
 
 #### Sharing only final results
 
 Agents can have their own private "scratchpad" and only **share the final result** with the rest of the agents. This approach might work better for systems with many agents or agents that are more complex. In this case, you would need to define agents with [different state schemas](#using-different-state-schemas).
 
-For agents called as tools, the supervisor determines the inputs based on the tool schema. Additionally, LangGraph allows [passing state](../how-tos/tool-calling.md#short-term-memory) to individual tools at runtime, so subordinate agents can access parent state, if needed.
+For agents called as tools, the supervisor determines the inputs based on the tool schema. Additionally, LangGraph allows [passing state](../how-tos/tool-calling.ipynb#read-state) to individual tools at runtime, so subordinate agents can access parent state, if needed.
 
 #### Indicating agent name in messages
 
@@ -415,4 +414,4 @@ There are two high-level approaches to achieve that:
 An agent might need to have a different state schema from the rest of the agents. For example, a search agent might only need to keep track of queries and retrieved documents. There are two ways to achieve this in LangGraph:
 
 - Define [subgraph](./subgraphs.md) agents with a separate state schema. If there are no shared state keys (channels) between the subgraph and the parent graph, it’s important to [add input / output transformations](../how-tos/subgraph.ipynb#different-state-schemas) so that the parent graph knows how to communicate with the subgraphs.
-- Define agent node functions with a [private input state schema](../how-tos/graph-api.ipynb/#pass-private-state-between-nodes) that is distinct from the overall graph state schema. This allows passing information that is only needed for executing that particular agent.
+- Define agent node functions with a [private input state schema](../how-tos/graph-api.ipynb/#pass-private-state-between-nodes) that is distinct from the overall graph state schema. This allows passing information that is only needed for executing that particular agent.

docs/docs/concepts/persistence.md

@@ -5,7 +5,7 @@ search:
 
 # Persistence
 
-LangGraph has a built-in persistence layer, implemented through checkpointers. When you compile graph with a checkpointer, the checkpointer saves a `checkpoint` of the graph state at every super-step. Those checkpoints are saved to a `thread`, which can be accessed after graph execution. Because `threads` allow access to graph's state after execution, several powerful capabilities including human-in-the-loop, memory, time travel, and fault-tolerance are all possible. Below, we'll discuss each of these concepts in more detail. 
+LangGraph has a built-in persistence layer, implemented through checkpointers. When you compile graph with a checkpointer, the checkpointer saves a `checkpoint` of the graph state at every super-step. Those checkpoints are saved to a `thread`, which can be accessed after graph execution. Because `threads` allow access to graph's state after execution, several powerful capabilities including human-in-the-loop, memory, time travel, and fault-tolerance are all possible. See [this how-to guide](../how-tos/persistence.ipynb) for an end-to-end example on how to add and use checkpointers with your graph. Below, we'll discuss each of these concepts in more detail. 
 
 ![Checkpoints](img/persistence/checkpoints.jpg)
 
@@ -15,27 +15,21 @@ LangGraph has a built-in persistence layer, implemented through checkpointers. W
 
 ## Threads
 
-A thread is a unique ID or thread identifier assigned to each checkpoint saved by a checkpointer. It contains the accumulated state of a sequence of [runs](./assistants.md#execution). When a run is executed, the [state](../concepts/low_level.md#state) of the underlying graph of the assistant will be persisted to the thread.
-
-When invoking graph with a checkpointer, you **must** specify a `thread_id` as part of the `configurable` portion of the config:
+A thread is a unique ID or [thread identifier](#threads) assigned to each checkpoint saved by a checkpointer. When invoking graph with a checkpointer, you **must** specify a `thread_id` as part of the `configurable` portion of the config:
 
 ```python
 {"configurable": {"thread_id": "1"}}
 ```
 
-A thread's current and historical state can be retrieved. To persist state, a thread must be created prior to executing a run. The LangGraph Platform API provides several endpoints for creating and managing threads and thread state. See the [API reference](../cloud/reference/api/api_ref.html#tag/threads) for more details.
-
 ## Checkpoints
 
-The state of a thread at a particular point in time is called a checkpoint. Checkpoint is a snapshot of the graph state saved at each super-step and is represented by `StateSnapshot` object with the following key properties:
+Checkpoint is a snapshot of the graph state saved at each super-step and is represented by `StateSnapshot` object with the following key properties:
 
 - `config`: Config associated with this checkpoint. 
 - `metadata`: Metadata associated with this checkpoint.
 - `values`: Values of the state channels at this point in time.
 - `next` A tuple of the node names to execute next in the graph.
-- `tasks`: A tuple of `PregelTask` objects that contain information about next tasks to be executed. If the step was previously attempted, it will include error information. If a graph was interrupted [dynamically](../how-tos/human_in_the_loop/breakpoints.md#dynamic-breakpoints) from within a node, tasks will contain additional data associated with interrupts.
-
-Checkpoints are persisted and can be used to restore the state of a thread at a later time.
+- `tasks`: A tuple of `PregelTask` objects that contain information about next tasks to be executed. If the step was previously attempted, it will include error information. If a graph was interrupted [dynamically](../how-tos/human_in_the_loop/breakpoints.ipynb#dynamic-breakpoints) from within a node, tasks will contain additional data associated with interrupts.
 
 Let's see what checkpoints are saved when a simple graph is invoked as follows:
 
@@ -174,7 +168,7 @@ config = {"configurable": {"thread_id": "1", "checkpoint_id": "0c62ca34-ac19-445
 graph.invoke(None, config=config)
 ```
 
-Importantly, LangGraph knows whether a particular step has been executed previously. If it has, LangGraph simply *re-plays* that particular step in the graph and does not re-execute the step, but only for the steps _before_ the provided `checkpoint_id`. All of the steps _after_ `checkpoint_id` will be executed (i.e., a new fork), even if they have been executed previously. See this [how to guide on time-travel to learn more about replaying](../how-tos/human_in_the_loop/time-travel.md).
+Importantly, LangGraph knows whether a particular step has been executed previously. If it has, LangGraph simply *re-plays* that particular step in the graph and does not re-execute the step, but only for the steps _before_ the provided `checkpoint_id`. All of the steps _after_ `checkpoint_id` will be executed (i.e., a new fork), even if they have been executed previously. See this [how to guide on time-travel to learn more about replaying](../how-tos/human_in_the_loop/time-travel.ipynb).
 
 ![Replay](img/persistence/re_play.png)
 
@@ -224,7 +218,7 @@ The `foo` key (channel) is completely changed (because there is no reducer speci
 
 #### `as_node`
 
-The final thing you can optionally specify when calling `update_state` is `as_node`. If you provided it, the update will be applied as if it came from node `as_node`. If `as_node` is not provided, it will be set to the last node that updated the state, if not ambiguous. The reason this matters is that the next steps to execute depend on the last node to have given an update, so this can be used to control which node executes next. See this [how to guide on time-travel to learn more about forking state](../how-tos/human_in_the_loop/time-travel.md).
+The final thing you can optionally specify when calling `update_state` is `as_node`. If you provided it, the update will be applied as if it came from node `as_node`. If `as_node` is not provided, it will be set to the last node that updated the state, if not ambiguous. The reason this matters is that the next steps to execute depend on the last node to have given an update, so this can be used to control which node executes next. See this [how to guide on time-travel to learn more about forking state](../how-tos/human_in_the_loop/time-travel.ipynb).
 
 ![Update](img/persistence/checkpoints_full_story.jpg)
 
@@ -525,11 +519,11 @@ When running on LangGraph Platform, encryption is automatically enabled whenever
 
 ### Human-in-the-loop
 
-First, checkpointers facilitate [human-in-the-loop workflows](agentic_concepts.md#human-in-the-loop) workflows by allowing humans to inspect, interrupt, and approve graph steps. Checkpointers are needed for these workflows as the human has to be able to view the state of a graph at any point in time, and the graph has to be to resume execution after the human has made any updates to the state. See [these how-to guides](../how-tos/human_in_the_loop/breakpoints.md) for concrete examples.
+First, checkpointers facilitate [human-in-the-loop workflows](agentic_concepts.md#human-in-the-loop) workflows by allowing humans to inspect, interrupt, and approve graph steps. Checkpointers are needed for these workflows as the human has to be able to view the state of a graph at any point in time, and the graph has to be to resume execution after the human has made any updates to the state. See [these how-to guides](../how-tos/human_in_the_loop/breakpoints.ipynb) for concrete examples.
 
 ### Memory
 
-Second, checkpointers allow for ["memory"](../concepts/memory.md) between interactions.  In the case of repeated human interactions (like conversations) any follow up messages can be sent to that thread, which will retain its memory of previous ones. See [Add memory](../how-tos/memory/add-memory.md) for information on how to add and manage conversation memory using checkpointers.
+Second, checkpointers allow for ["memory"](agentic_concepts.md#memory) between interactions.  In the case of repeated human interactions (like conversations) any follow up messages can be sent to that thread, which will retain its memory of previous ones. See [this how-to guide](../how-tos/memory.ipynb) for an end-to-end example on how to add and manage conversation memory using checkpointers.
 
 ### Time Travel
 

docs/docs/concepts/plans.md

@@ -20,7 +20,7 @@ There are three different plans for using it.
 |                                                                  | Developer                                   | Plus                                                  | Enterprise                                          |
 |------------------------------------------------------------------|---------------------------------------------|-------------------------------------------------------|-----------------------------------------------------|
 | Deployment Options                                               | Standalone Container (Lite)                          | Cloud SaaS                                         | <ul><li>Cloud SaaS</li><li>Self-Hosted Data Plane</li><li>Self-Hosted Control Plane</li><li>Standalone Container (Enterprise)</li></ul> |
-| Usage                                                            | Free, limited to 1M [nodes executed](../concepts/faq.md#what-does-nodes-executed-mean-for-langgraph-platform-usage) per year | See [Pricing](https://www.langchain.com/langgraph-platform-pricing) | Custom                                              |
+| Usage                                                            | Free, limited to 1M nodes executed per year | Free while in Beta, will be charged per node executed | Custom                                              |
 | APIs for retrieving and updating state and conversational history | ✅                                           | ✅                                                     | ✅                                                   |
 | APIs for retrieving and updating long-term memory                | ✅                                           | ✅                                                     | ✅                                                   |
 | Horizontally scalable task queues and servers                    | ✅                                           | ✅                                                     | ✅                                                   |

docs/docs/concepts/server-mcp.md

@@ -6,14 +6,20 @@ hide:
   - tags
 ---
 
-# MCP endpoint in LangGraph Server
+# MCP Endpoint
 
 The **Model Context Protocol (MCP)** is an open protocol for describing tools and data sources in a model-agnostic format, enabling LLMs to discover
 and use them via a structured API. 
 
 [LangGraph Server](./langgraph_server.md) implements MCP using the [Streamable HTTP transport](https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/#streamable-http). This allows LangGraph **agents** to be exposed as **MCP tools**, making them usable with any MCP-compliant client supporting Streamable HTTP.
 
-The MCP endpoint is available at `/mcp` on [LangGraph Server](./langgraph_server.md).
+The MCP endpoint is available at:
+
+```
+/mcp
+```
+
+on [LangGraph Server](./langgraph_server.md).
 
 ## Requirements
 

docs/docs/concepts/streaming.md

@@ -18,6 +18,6 @@ There are three main categories of data you can stream:
 
 - [**Stream LLM tokens**](../how-tos/streaming.md#messages) — capture token streams from anywhere: inside nodes, subgraphs, or tools.
 - [**Emit progress notifications from tools**](../how-tos/streaming.md#stream-custom-data) — send custom updates or progress signals directly from tool functions.
-- [**Stream from subgraphs**](../how-tos/streaming.md#stream-subgraph-outputs) — include outputs from both the parent graph and any nested subgraphs.
+- [**Stream from subgraphs**](../how-tos/streaming.md#subgraphs) — include outputs from both the parent graph and any nested subgraphs.
 - [**Use any LLM**](../how-tos/streaming.md#use-with-any-llm) — stream tokens from any LLM, even if it's not a LangChain model using the `custom` streaming mode.
 - [**Use multiple streaming modes**](../how-tos/streaming.md#stream-multiple-modes) — choose from `values` (full state), `updates` (state deltas), `messages` (LLM tokens + metadata), `custom` (arbitrary user data), or `debug` (detailed traces).

docs/docs/concepts/time-travel.md

@@ -7,12 +7,9 @@ search:
 
 When working with non-deterministic systems that make model-based decisions (e.g., agents powered by LLMs), it can be useful to examine their decision-making process in detail:
 
-1. 🤔 **Understand reasoning**: Analyze the steps that led to a successful result.
-2. 🐞 **Debug mistakes**: Identify where and why errors occurred.
-3. 🔍 **Explore alternatives**: Test different paths to uncover better solutions.
+1. 🤔 **Understand Reasoning**: Analyze the steps that led to a successful result.
+2. 🐞 **Debug Mistakes**: Identify where and why errors occurred.
+3. 🔍 **Explore Alternatives**: Test different paths to uncover better solutions.
 
-LangGraph provides [time travel functionality](../how-tos/human_in_the_loop/time-travel.md) to support these use cases. Specifically, you can resume execution from a prior checkpoint — either replaying the same state or modifying it to explore alternatives. In all cases, resuming past execution produces a new fork in the history.
 
-!!! tip
-
-    For information on how to use time travel, see [Use time travel](../how-tos/human_in_the_loop/time-travel.md) and [Time travel using Server API](../cloud/how-tos/human_in_the_loop_time_travel.md).
+LangGraph provides **time travel** functionality to support these use cases. Specifically, you can **resume execution from a prior checkpoint** — either replaying the same state or modifying it to explore alternatives. In all cases, resuming past execution produces a **new fork** in the history.

docs/docs/concepts/tools.md

@@ -1,64 +1,62 @@
 # Tools
 
-Many AI applications interact with users via natural language. However, some use cases require models to interface directly with external systems—such as APIs, databases, or file systems—using structured input. In these scenarios, [tool calling](../how-tos/tool-calling.md) enables models to generate requests that conform to a specified input schema.
+Many AI applications interact directly with humans. In these cases, it is appropriate for models to respond in natural language.
+But what about cases where we want a model to also interact *directly* with systems, such as databases or an API?
+These systems often have a particular input schema; for example, APIs frequently have a required payload structure. You can use [tool calling](https://platform.openai.com/docs/guides/function-calling/example-use-cases) to request model responses that match a particular schema.
 
-**Tools** encapsulate a callable function and its input schema. These can be passed to compatible [chat models](https://python.langchain.com/docs/concepts/chat_models), allowing the model to decide whether to invoke a tool and with what arguments.
+[Tools](https://python.langchain.com/docs/concepts/tools/) are a way to encapsulate a function and its input schema in a way that can be passed to a chat model that supports tool calling. This allows the model to request the execution of this function with specific inputs.
+
+**Tools** can be passed to [chat models](https://python.langchain.com/docs/concepts/chat_models) that support [tool calling](https://python.langchain.com/docs/concepts/tool_calling) allowing the model to request the execution of a specific function with specific inputs.
+
+You can [create custom tools](https://python.langchain.com/docs/how_to/custom_tools/) or use [prebuilt](#prebuilt-tools) tools.
 
 ## Tool calling
 
 ![Diagram of a tool call by a model](./img/tool_call.png)
 
-Tool calling is typically **conditional**. Based on the user input and available tools, the model may choose to issue a tool call request. This request is returned in an `AIMessage` object, which includes a `tool_calls` field that specifies the tool name and input arguments:
+A key principle of tool calling is that the model decides when to use a tool based on the input's relevance. The model doesn't always need to call a tool.
+For example, given an input that is *irrelevant to the tool*, the model would not call the tool:
 
 ```python
-llm_with_tools.invoke("What is 2 multiplied by 3?")
-# -> AIMessage(tool_calls=[{'name': 'multiply', 'args': {'a': 2, 'b': 3}, ...}])
+result = llm_with_tools.invoke("Hello world!")
 ```
 
-If the input is unrelated to any tool, the model returns only a natural language message:
+The result would be an `AIMessage` containing the model's response in natural language (e.g., "Hello!").
+However, if we pass an input *relevant to the tool*, the model should choose to call it:
 
 ```python
-llm_with_tools.invoke("Hello world!")  # -> AIMessage(content="Hello!")
+result = llm_with_tools.invoke("What is 2 multiplied by 3?")
 ```
 
-Importantly, the model does not execute the tool—it only generates a request. A separate executor (such as a runtime or agent) is responsible for handling the tool call and returning the result.
+As before, the output `result` will be an `AIMessage`. 
+But, if the tool was called, `result` will have a `tool_calls` attribute.
+This attribute includes everything needed to execute the tool, including the tool name and input arguments:
 
-See the [tool calling guide](../how-tos/tool-calling.md) for more details.
+```
+result.tool_calls
+{'name': 'multiply', 'args': {'a': 2, 'b': 3}, 'id': 'xxx', 'type': 'tool_call'}
+```
+
+For more details on usage, see the [how-to guide](../how-tos/tool-calling.ipynb).
+
+## Execute tools
+
+LangGraph offers pre-built components — [`ToolNode`][langgraph.prebuilt.tool_node.ToolNode] and [`create_react_agent`][langgraph.prebuilt.chat_agent_executor.create_react_agent] — that invoke the tools on behalf of the user.
+
+See this [how-to guide](../how-tos/tool-calling.ipynb#use-prebuilt-toolnode) on tool calling.
 
 ## Prebuilt tools
 
-LangChain provides prebuilt tool integrations for common external systems including APIs, databases, file systems, and web data.
+LangChain supports a wide range of prebuilt tool integrations for interacting with APIs, databases, file systems, web data, and more. These tools extend the functionality of agents and enable rapid development.
 
-Browse the [integrations directory](https://python.langchain.com/docs/integrations/tools/) for available tools.
+You can browse the full list of available integrations in the [LangChain integrations directory](https://python.langchain.com/docs/integrations/tools/).
 
-Common categories:
+Some commonly used tool categories include:
 
-* **Search**: Bing, SerpAPI, Tavily
-* **Code execution**: Python REPL, Node.js REPL
-* **Databases**: SQL, MongoDB, Redis
-* **Web data**: Scraping and browsing
-* **APIs**: OpenWeatherMap, NewsAPI, etc.
+- **Search**: Bing, SerpAPI, Tavily
+- **Code interpreters**: Python REPL, Node.js REPL
+- **Databases**: SQL, MongoDB, Redis
+- **Web data**: Web scraping and browsing
+- **APIs**: OpenWeatherMap, NewsAPI, and others
 
-## Custom tools
-
-You can define custom tools using the `@tool` decorator or plain Python functions. For example:
-
-```python
-from langchain_core.tools import tool
-
-@tool
-def multiply(a: int, b: int) -> int:
-    """Multiply two numbers."""
-    return a * b
-```
-
-See the [tool calling guide](../how-tos/tool-calling.md) for more details.
-
-## Tool execution
-
-While the model determines when to call a tool, execution of the tool call must be handled by a runtime component.
-
-LangGraph provides prebuilt components for this:
-
-* [`ToolNode`][langgraph.prebuilt.tool_node.ToolNode]: A prebuilt node that executes tools.
-* [`create_react_agent`][langgraph.prebuilt.chat_agent_executor.create_react_agent]: Constructs a full agent that manages tool calling automatically.
+These integrations can be configured and added to your agents using the same `tools` parameter shown in the examples above.

docs/docs/how-tos/http/custom_routes.md

@@ -34,7 +34,7 @@ def read_root():
 
 ## Configure `langgraph.json`
 
-Add the following to your `langgraph.json` configuration file. Make sure the path points to the FastAPI application instance `app` in the `webapp.py` file you created above.
+Add the following to your `langgraph.json` configuration file. Make sure the path points to the `app.py` file you created above.
 
 ```json
 {
@@ -71,4 +71,4 @@ You can deploy this app as-is to LangGraph Platform or to your self-hosted platf
 
 ## Next steps
 
-Now that you've added a custom route to your deployment, you can use this same technique to further customize how your server behaves, such as defining custom [custom middleware](./custom_middleware.md) and [custom lifespan events](./custom_lifespan.md). 
+Now that you've added a custom route to your deployment, you can use this same technique to further customize how your server behaves, such as defining custom [custom middleware](./custom_middleware.md) and [custom lifespan events](./custom_lifespan.md). 

docs/docs/how-tos/human_in_the_loop/add-human-in-the-loop.md

@@ -9,20 +9,13 @@ hide:
   - tags
 ---
 
-# Enable human intervention
+# Add human-in-the-loop
 
-To review, edit, and approve tool calls in an agent or workflow, use LangGraph's [human-in-the-loop](../../concepts/human_in_the_loop.md) features.
-
-## Pause using `interrupt`
+## `interrupt`
 
 The [`interrupt` function][langgraph.types.interrupt] in LangGraph enables human-in-the-loop workflows by pausing the graph at a specific node, presenting information to a human, and resuming the graph with their input. It's useful for tasks like approvals, edits, or gathering additional context.
 
-To use `interrupt` in your graph, you need to:
-
-1. [**Specify a checkpointer**](../../concepts/persistence.md#checkpoints) to save the graph state after each step.
-2. **Call `interrupt()`** in the appropriate place. See the [Common Patterns](#common-patterns) section for examples.
-3. **Run the graph** with a [**thread ID**](../../concepts/persistence.md#threads) until the `interrupt` is hit.
-4. **Resume execution** using `invoke`/`ainvoke`/`stream`/`astream` (see [**The `Command` primitive**](#resume-using-the-command-primitive)).
+The graph is resumed using a [`Command`][langgraph.types.Command] object that provides the human's response.
 
 ```python
 # highlight-next-line
@@ -132,48 +125,34 @@ print(graph.invoke(Command(resume="Edited text"), config=config)) # (7)!
     7. The graph is resumed with a `Command(resume=...)`, injecting the human's input and continuing execution.
 
 
+
 !!! tip "New in 0.4.0"
 
       `__interrupt__` is a special key that will be returned when running the graph if the graph is interrupted. Support for `__interrupt__` in `invoke` and `ainvoke` has been added in version 0.4.0. If you're on an older version, you will only see `__interrupt__` in the result if you use `stream` or `astream`. You can also use `graph.get_state(thread_id)` to get the interrupt value.
 
 !!! warning
 
-      Interrupts are both powerful and ergonomic. However, while they may resemble Python's input() function in terms of developer experience, it's important to note that they do not automatically resume execution from the interruption point. Instead, they rerun the entire node where the interrupt was used. For this reason, interrupts are typically best placed at the start of a node or in a dedicated node.
+      Interrupts are both powerful and ergonomic. However, while they may resemble Python's input() function in terms of developer experience, it's important to note that they do not automatically resume execution from the interruption point. Instead, they rerun the entire node where the interrupt was used.
+      For this reason, interrupts are typically best placed at the start of a node or in a dedicated node. Please read the [resuming from an interrupt](#how-does-resuming-from-an-interrupt-work) section for more details.
 
+## Requirements
 
-## Resume using the `Command` primitive
+To use `interrupt` in your graph, you need to:
 
-!!! warning
+1. [**Specify a checkpointer**](../../concepts/persistence.md#checkpoints) to save the graph state after each step.
+2. **Call `interrupt()`** in the appropriate place. See the [Design Patterns](#design-patterns) section for examples.
+3. **Run the graph** with a [**thread ID**](../../concepts/persistence.md#threads) until the `interrupt` is hit.
+4. **Resume execution** using `invoke`/`ainvoke`/`stream`/`astream` (see [**The `Command` primitive**](#resume-using-the-command-primitive)).
 
-    Resuming from an `interrupt` is different from Python's `input()` function, where execution resumes from the exact point where the `input()` function was called.
+## Design patterns
 
-When the `interrupt` function is used within a graph, execution pauses at that point and awaits user input.
+There are typically three different **actions** that you can do with a human-in-the-loop workflow:
 
-To resume execution, use the [`Command`][langgraph.types.Command] primitive, which can be supplied via the `invoke`, `ainvoke`, `stream`, or `astream` methods. The graph resumes execution from the beginning of the node where `interrupt(...)` was initially called. This time, the `interrupt` function will return the value provided in `Command(resume=value)` rather than pausing again. All code from the beginning of the node to the `interrupt` will be re-executed.
+1. **Approve or Reject**: Pause the graph before a critical step, such as an API call, to review and approve the action. If the action is rejected, you can prevent the graph from executing the step, and potentially take an alternative action. This pattern often involve **routing** the graph based on the human's input.
+2. **Edit Graph State**: Pause the graph to review and edit the graph state. This is useful for correcting mistakes or updating the state with additional information. This pattern often involves **updating** the state with the human's input.
+3. **Get Input**: Explicitly request human input at a particular step in the graph. This is useful for collecting additional information or context to inform the agent's decision-making process.
 
-```python
-# Resume graph execution by providing the user's input.
-graph.invoke(Command(resume={"age": "25"}), thread_config)
-```
-
-### Resume multiple interrupts with one invocation
-
-If you have multiple interrupts in the task queue, you can use `Command.resume` with a dictionary mapping of interrupt ids to resume with a single `invoke` / `stream` call.
-
-For example, once your graph has been interrupted (multiple times, theoretically) and is stalled:
-
-```python
-resume_map = {
-    i.interrupt_id: f"human input for prompt {i.value}"
-    for i in parent.get_state(thread_config).interrupts
-}
-
-parent_graph.invoke(Command(resume=resume_map), config=thread_config)
-```
-
-## Common patterns
-
-Below we show different design patterns that can be implemented using `interrupt` and `Command`.
+Below we show different design patterns that can be implemented using these **actions**.
 
 ### Approve or reject
 
@@ -284,7 +263,9 @@ graph.invoke(Command(resume=True), config=thread_config)
     print(final_result)
     ```
 
-### Review and edit state
+See [how to review tool calls](./review-tool-calls.ipynb) for a more detailed example.
+
+### Review & edit state
 
 <figure markdown="1">
 ![image](../../concepts/img/human_in_the_loop/edit-graph-state-simple.png){: style="max-height:400px"}
@@ -412,209 +393,41 @@ critical in applications where the tool calls requested by the LLM may be sensit
 </figcaption>
 </figure>
 
-To add a human approval step to a tool:
-
-1. Use `interrupt()` in the tool to pause execution.
-2. Resume with a `Command(resume=...)` to continue based on human input.
-
 ```python
-from langgraph.checkpoint.memory import InMemorySaver
-from langgraph.types import interrupt
-from langgraph.prebuilt import create_react_agent
-
-# An example of a sensitive tool that requires human review / approval
-def book_hotel(hotel_name: str):
-    """Book a hotel"""
-    # highlight-next-line
-    response = interrupt(  # (1)!
-        f"Trying to call `book_hotel` with args {{'hotel_name': {hotel_name}}}. "
-        "Please approve or suggest edits."
-    )
-    if response["type"] == "accept":
-        pass
-    elif response["type"] == "edit":
-        hotel_name = response["args"]["hotel_name"]
-    else:
-        raise ValueError(f"Unknown response type: {response['type']}")
-    return f"Successfully booked a stay at {hotel_name}."
-
-# highlight-next-line
-checkpointer = InMemorySaver() # (2)!
-
-agent = create_react_agent(
-    model="anthropic:claude-3-5-sonnet-latest",
-    tools=[book_hotel],
-    # highlight-next-line
-    checkpointer=checkpointer, # (3)!
-)
-```
-
-1. The [`interrupt` function][langgraph.types.interrupt] pauses the agent graph at a specific node. In this case, we call `interrupt()` at the beginning of the tool function, which pauses the graph at the node that executes the tool. The information inside `interrupt()` (e.g., tool calls) can be presented to a human, and the graph can be resumed with the user input (tool call approval, edit or feedback).
-2. The `InMemorySaver` is used to store the agent state at every step in the tool calling loop. This enables [short-term memory](../memory/add-memory.md#add-short-term-memory) and [human-in-the-loop](../../concepts/human_in_the_loop.md) capabilities. In this example, we use `InMemorySaver` to store the agent state in memory. In a production application, the agent state will be stored in a database.
-3. Initialize the agent with the `checkpointer`.
-
-Run the agent with the `stream()` method, passing the `config` object to specify the thread ID. This allows the agent to resume the same conversation on future invocations.
-
-```python
-config = {
-   "configurable": {
-      # highlight-next-line
-      "thread_id": "1"
-   }
-}
-
-for chunk in agent.stream(
-    {"messages": [{"role": "user", "content": "book a stay at McKittrick hotel"}]},
-    # highlight-next-line
-    config
-):
-    print(chunk)
-    print("\n")
-```
-
-> You should see that the agent runs until it reaches the `interrupt()` call, at which point it pauses and waits for human input.
-
-Resume the agent with a `Command(resume=...)` to continue based on human input.
-
-```python
-from langgraph.types import Command
-
-for chunk in agent.stream(
-    # highlight-next-line
-    Command(resume={"type": "accept"}),  # (1)!
-    # Command(resume={"type": "edit", "args": {"hotel_name": "McKittrick Hotel"}}),
-    config
-):
-    print(chunk)
-    print("\n")
-```
-
-1. The [`interrupt` function][langgraph.types.interrupt] is used in conjunction with the [`Command`][langgraph.types.Command] object to resume the graph with a value provided by the human.
-
-### Add interrupts to any tool
-
-You can create a wrapper to add interrupts to *any* tool. The example below provides a reference implementation compatible with [Agent Inbox UI](https://github.com/langchain-ai/agent-inbox) and [Agent Chat UI](https://github.com/langchain-ai/agent-chat-ui).
-
-```python title="Wrapper that adds human-in-the-loop to any tool"
-from typing import Callable
-from langchain_core.tools import BaseTool, tool as create_tool
-from langchain_core.runnables import RunnableConfig
-from langgraph.types import interrupt 
-from langgraph.prebuilt.interrupt import HumanInterruptConfig, HumanInterrupt
-
-def add_human_in_the_loop(
-    tool: Callable | BaseTool,
-    *,
-    interrupt_config: HumanInterruptConfig = None,
-) -> BaseTool:
-    """Wrap a tool to support human-in-the-loop review.""" 
-    if not isinstance(tool, BaseTool):
-        tool = create_tool(tool)
-
-    if interrupt_config is None:
-        interrupt_config = {
-            "allow_accept": True,
-            "allow_edit": True,
-            "allow_respond": True,
+def human_review_node(state) -> Command[Literal["call_llm", "run_tool"]]:
+    # This is the value we'll be providing via Command(resume=<human_review>)
+    human_review = interrupt(
+        {
+            "question": "Is this correct?",
+            # Surface tool calls for review
+            "tool_call": tool_call
         }
-
-    @create_tool(  # (1)!
-        tool.name,
-        description=tool.description,
-        args_schema=tool.args_schema
     )
-    def call_tool_with_interrupt(config: RunnableConfig, **tool_input):
-        request: HumanInterrupt = {
-            "action_request": {
-                "action": tool.name,
-                "args": tool_input
-            },
-            "config": interrupt_config,
-            "description": "Please review the tool call"
-        }
-        # highlight-next-line
-        response = interrupt([request])[0]  # (2)!
-        # approve the tool call
-        if response["type"] == "accept":
-            tool_response = tool.invoke(tool_input, config)
-        # update tool call args
-        elif response["type"] == "edit":
-            tool_input = response["args"]["args"]
-            tool_response = tool.invoke(tool_input, config)
-        # respond to the LLM with user feedback
-        elif response["type"] == "response":
-            user_feedback = response["args"]
-            tool_response = user_feedback
-        else:
-            raise ValueError(f"Unsupported interrupt response type: {response['type']}")
 
-        return tool_response
+    review_action, review_data = human_review
 
-    return call_tool_with_interrupt
+    # Approve the tool call and continue
+    if review_action == "continue":
+        return Command(goto="run_tool")
+
+    # Modify the tool call manually and then continue
+    elif review_action == "update":
+        ...
+        updated_msg = get_updated_msg(review_data)
+        # Remember that to modify an existing message you will need
+        # to pass the message with a matching ID.
+        return Command(goto="run_tool", update={"messages": [updated_message]})
+
+    # Give natural language feedback, and then pass that back to the agent
+    elif review_action == "feedback":
+        ...
+        feedback_msg = get_feedback_msg(review_data)
+        return Command(goto="call_llm", update={"messages": [feedback_msg]})
 ```
 
-1. This wrapper creates a new tool that calls `interrupt()` **before** executing the wrapped tool.
-2. `interrupt()` is using special input and output format that's expected by [Agent Inbox UI](https://github.com/langchain-ai/agent-inbox):
-    - a list of [`HumanInterrupt`][langgraph.prebuilt.interrupt.HumanInterrupt] objects is sent to `AgentInbox` render interrupt information to the end user
-    - resume value is provided by `AgentInbox` as a list (i.e., `Command(resume=[...])`)
+See [how to review tool calls](./review-tool-calls.ipynb) for a more detailed example.
 
-You can use the `add_human_in_the_loop` wrapper to add `interrupt()` to any tool without having to add it *inside* the tool:
-
-```python
-from langgraph.checkpoint.memory import InMemorySaver
-from langgraph.prebuilt import create_react_agent
-
-# highlight-next-line
-checkpointer = InMemorySaver()
-
-def book_hotel(hotel_name: str):
-   """Book a hotel"""
-   return f"Successfully booked a stay at {hotel_name}."
-
-
-agent = create_react_agent(
-    model="anthropic:claude-3-5-sonnet-latest",
-    tools=[
-        # highlight-next-line
-        add_human_in_the_loop(book_hotel), # (1)!
-    ],
-    # highlight-next-line
-    checkpointer=checkpointer,
-)
-
-config = {"configurable": {"thread_id": "1"}}
-
-# Run the agent
-for chunk in agent.stream(
-    {"messages": [{"role": "user", "content": "book a stay at McKittrick hotel"}]},
-    # highlight-next-line
-    config
-):
-    print(chunk)
-    print("\n")
-```
-
-1. The `add_human_in_the_loop` wrapper is used to add `interrupt()` to the tool. This allows the agent to pause execution and wait for human input before proceeding with the tool call.
-
-> You should see that the agent runs until it reaches the `interrupt()` call, 
->  at which point it pauses and waits for human input.
-
-Resume the agent with a `Command(resume=...)`  to continue based on human input.
-
-```python
-from langgraph.types import Command 
-
-for chunk in agent.stream(
-    # highlight-next-line
-    Command(resume=[{"type": "accept"}]),
-    # Command(resume=[{"type": "edit", "args": {"args": {"hotel_name": "McKittrick Hotel"}}}]),
-    config
-):
-    print(chunk)
-    print("\n")
-```
-
-### Validate human input
+### Validating human input
 
 If you need to validate the input provided by the human within the graph itself (rather than on the client side), you can achieve this by using multiple interrupt calls within a single node.
 
@@ -712,15 +525,91 @@ def human_node(state: State):
     print(final_result)  # Should include the valid age
     ```
 
-## Considerations
 
-When using human-in-the-loop, there are some considerations to keep in mind.
+## Resume using the `Command` primitive
 
-### Using with code with side-effects
+When the `interrupt` function is used within a graph, execution pauses at that point and awaits user input.
 
-Place code with side effects, such as API calls, after the `interrupt` or in a separate node to avoid duplication, as these are re-triggered every time the node is resumed.
+To resume execution, use the [`Command`][langgraph.types.Command] primitive, which can be supplied via the `invoke`, `ainvoke`, `stream`, or `astream` methods.
 
-=== "Side effects after interrupt"
+**Providing a response to the `interrupt`:**
+To continue execution, pass the user's input using `Command(resume=value)`. The graph resumes execution from the beginning of the node where `interrupt(...)` was initially called. This time, the `interrupt` function will return the value provided in `Command(resume=value)` rather than pausing again.
+
+```python
+# Resume graph execution by providing the user's input.
+graph.invoke(Command(resume={"age": "25"}), thread_config)
+```
+
+## How does resuming from an interrupt work?
+
+!!! warning
+
+    Resuming from an `interrupt` is **different** from Python's `input()` function, where execution resumes from the exact point where the `input()` function was called.
+
+A critical aspect of using `interrupt` is understanding how resuming works. When you resume execution after an `interrupt`, graph execution starts from the **beginning** of the **graph node** where the last `interrupt` was triggered.
+
+**All** code from the beginning of the node to the `interrupt` will be re-executed.
+
+```python
+counter = 0
+def node(state: State):
+    # All the code from the beginning of the node to the interrupt will be re-executed
+    # when the graph resumes.
+    global counter
+    counter += 1
+    print(f"> Entered the node: {counter} # of times")
+    # Pause the graph and wait for user input.
+    answer = interrupt()
+    print("The value of counter is:", counter)
+    ...
+```
+
+Upon **resuming** the graph, the counter will be incremented a second time, resulting in the following output:
+
+```pycon
+> Entered the node: 2 # of times
+The value of counter is: 2
+```
+
+### Resuming multiple interrupts with one invocation
+
+If you have multiple interrupts in the task queue, you can use `Command.resume` with a dictionary mapping
+of interrupt ids to resume values to resume multiple interrupts with a single `invoke` / `stream` call.
+
+For example, once your graph has been interrupted (multiple times, theoretically) and is stalled:
+
+```python
+resume_map = {
+    i.interrupt_id: f"human input for prompt {i.value}"
+    for i in parent.get_state(thread_config).interrupts
+}
+
+parent_graph.invoke(Command(resume=resume_map), config=thread_config)
+```
+
+## Common pitfalls
+
+### Side-effects
+
+Place code with side effects, such as API calls, **after** the `interrupt` to avoid duplication, as these are re-triggered every time the node is resumed.
+
+=== "Side effects before interrupt (BAD)"
+
+    This code will re-execute the API call another time when the node is resumed from
+    the `interrupt`.
+
+    This can be problematic if the API call is not idempotent or is just expensive.
+
+    ```python
+    from langgraph.types import interrupt
+
+    def human_node(state: State):
+        """Human node with validation."""
+        api_call(...) # This code will be re-executed when the node is resumed.
+        answer = interrupt(question)
+    ```
+
+=== "Side effects after interrupt (OK)"
 
     ```python
     from langgraph.types import interrupt
@@ -733,7 +622,7 @@ Place code with side effects, such as API calls, after the `interrupt` or in a s
         api_call(answer) # OK as it's after the interrupt
     ```
 
-=== "Side effects in a separate node"
+=== "Side effects in a separate node (OK)"
 
     ```python
     from langgraph.types import interrupt
@@ -751,9 +640,11 @@ Place code with side effects, such as API calls, after the `interrupt` or in a s
         api_call(...) # OK as it's in a separate node
     ```
 
-### Using with subgraphs called as functions
+### Subgraphs called as functions
 
-When invoking a subgraph as a function, the parent graph will resume execution from the **beginning of the node** where the subgraph was invoked where the `interrupt` was triggered. Similarly, the **subgraph** will resume from the **beginning of the node** where the `interrupt()` function was called.
+When invoking a subgraph [as a function](../../how-tos/subgraph.ipynb#different-state-schemas), the **parent graph** will resume execution from the **beginning of the node** where the subgraph was invoked (and where an `interrupt` was triggered). Similarly, the **subgraph**, will resume from the **beginning of the node** where the `interrupt()` function was called.
+
+For example,
 
 ```python
 def node_in_parent_graph(state: State):
@@ -881,9 +772,11 @@ def node_in_parent_graph(state: State):
     {'parent_node': {'state_counter': 1}}
     ```
 
+
+
 ### Using multiple interrupts
 
-Using multiple interrupts within a **single** node can be helpful for patterns like [validating human input](#validate-human-input). However, using multiple interrupts in the same node can lead to unexpected behavior if not handled carefully.
+Using multiple interrupts within a **single** node can be helpful for patterns like [validating human input](#validating-human-input). However, using multiple interrupts in the same node can lead to unexpected behavior if not handled carefully.
 
 When a node contains multiple interrupt calls, LangGraph keeps a list of resume values specific to the task executing the node. Whenever execution resumes, it starts at the beginning of the node. For each interrupt encountered, LangGraph checks if a matching value exists in the task's resume list. Matching is **strictly index-based**, so the order of interrupt calls within the node is critical.
 
@@ -952,5 +845,4 @@ To avoid issues, refrain from dynamically changing the node's structure between
     {'__interrupt__': (Interrupt(value='what is your name?', resumable=True, ns=['human_node:3a007ef9-c30d-c357-1ec1-86a1a70d8fba'], when='during'),)}
     Name: N/A. Age: John
     {'human_node': {'age': 'John', 'name': 'N/A'}}
-    ```
-
+    ```

docs/docs/how-tos/human_in_the_loop/breakpoints.md

@@ -1,342 +0,0 @@
-# Set breakpoints
-
-There are two places where you can set breakpoints:
-
-1. **Before** or **after** a node executes by setting breakpoints at **compile time** or **run time**. We call these [**static breakpoints**](#static-breakpoints).
-2. **Inside** a node using the `NodeInterrupt` exception. We call these [**dynamic breakpoints**](#dynamic-breakpoints).
-
-To use breakpoints, you will need to:
-
-1. [**Specify a checkpointer**](../../concepts/persistence.md#checkpoints) to save the graph state after each step.
-2. **Set breakpoints** to specify where execution should pause.
-3. **Run the graph** with a [**thread ID**](../../concepts/persistence.md#threads) to pause execution at the breakpoint.
-4. **Resume execution** using `invoke`/`ainvoke`/`stream`/`astream` passing a `None` as the argument for the inputs.
-
-!!! tip
-
-    For a conceptual overview of breakpoints, see [Breakpoints](../../concepts/breakpoints.md).
-
-## Static breakpoints
-
-Static breakpoints are triggered either before or after a node executes. You can set static breakpoints by specifying `interrupt_before` and `interrupt_after` at compile time or run time.
-
-Static breakpoints can be especially useful for debugging if you want to step through the graph execution one
-node at a time or if you want to pause the graph execution at specific nodes.
-
-=== "Compile time"
-
-    ```python
-    # highlight-next-line
-    graph = graph_builder.compile( # (1)!
-        # highlight-next-line
-        interrupt_before=["node_a"], # (2)!
-        # highlight-next-line
-        interrupt_after=["node_b", "node_c"], # (3)!
-        checkpointer=checkpointer, # (4)!
-    )
-
-    config = {
-        "configurable": {
-            "thread_id": "some_thread"
-        }
-    }
-
-    # Run the graph until the breakpoint
-    graph.invoke(inputs, config=thread_config) # (5)!
-
-    # Resume the graph
-    graph.invoke(None, config=thread_config) # (6)!
-    ```
-
-    1. The breakpoints are set during `compile` time.
-    2. `interrupt_before` specifies the nodes where execution should pause before the node is executed.
-    3. `interrupt_after` specifies the nodes where execution should pause after the node is executed.
-    4. A checkpointer is required to enable breakpoints.
-    5. The graph is run until the first breakpoint is hit.
-    6. The graph is resumed by passing in `None` for the input. This will run the graph until the next breakpoint is hit.
-
-=== "Run time"
-
-    ```python
-    # highlight-next-line
-    graph.invoke( # (1)!
-        inputs, 
-        # highlight-next-line
-        interrupt_before=["node_a"], # (2)!
-        # highlight-next-line
-        interrupt_after=["node_b", "node_c"] # (3)!
-        config={
-            "configurable": {"thread_id": "some_thread"}
-        }, 
-    )
-
-    config = {
-        "configurable": {
-            "thread_id": "some_thread"
-        }
-    }
-
-    # Run the graph until the breakpoint
-    graph.invoke(inputs, config=config) # (4)!
-
-    # Resume the graph
-    graph.invoke(None, config=config) # (5)!
-    ```
-
-    1. `graph.invoke` is called with the `interrupt_before` and `interrupt_after` parameters. This is a run-time configuration and can be changed for every invocation.
-    2. `interrupt_before` specifies the nodes where execution should pause before the node is executed.
-    3. `interrupt_after` specifies the nodes where execution should pause after the node is executed.
-    4. The graph is run until the first breakpoint is hit.
-    5. The graph is resumed by passing in `None` for the input. This will run the graph until the next breakpoint is hit.
-
-    !!! note
-
-        You cannot set static breakpoints at runtime for **sub-graphs**.
-        If you have a sub-graph, you must set the breakpoints at compilation time.
-
-??? example "Setting static breakpoints"
-
-    ```python
-    from IPython.display import Image, display
-    from typing_extensions import TypedDict
-    
-    from langgraph.checkpoint.memory import InMemorySaver 
-    from langgraph.graph import StateGraph, START, END
-    
-    
-    class State(TypedDict):
-        input: str
-    
-    
-    def step_1(state):
-        print("---Step 1---")
-        pass
-    
-    
-    def step_2(state):
-        print("---Step 2---")
-        pass
-    
-    
-    def step_3(state):
-        print("---Step 3---")
-        pass
-    
-    
-    builder = StateGraph(State)
-    builder.add_node("step_1", step_1)
-    builder.add_node("step_2", step_2)
-    builder.add_node("step_3", step_3)
-    builder.add_edge(START, "step_1")
-    builder.add_edge("step_1", "step_2")
-    builder.add_edge("step_2", "step_3")
-    builder.add_edge("step_3", END)
-    
-    # Set up a checkpointer 
-    checkpointer = InMemorySaver() # (1)!
-    
-    graph = builder.compile(
-        checkpointer=checkpointer, # (2)!
-        interrupt_before=["step_3"] # (3)!
-    )
-    
-    # View
-    display(Image(graph.get_graph().draw_mermaid_png()))
-    
-    
-    # Input
-    initial_input = {"input": "hello world"}
-    
-    # Thread
-    thread = {"configurable": {"thread_id": "1"}}
-    
-    # Run the graph until the first interruption
-    for event in graph.stream(initial_input, thread, stream_mode="values"):
-        print(event)
-        
-    # This will run until the breakpoint
-    # You can get the state of the graph at this point
-    print(graph.get_state(config))
-    
-    # You can continue the graph execution by passing in `None` for the input
-    for event in graph.stream(None, thread, stream_mode="values"):
-        print(event)
-    ```
-
-## Dynamic breakpoints
-
-Use dynamic breakpoints if you need to interrupt the graph from inside a given node based on a condition.
-
-```python
-from langgraph.errors import NodeInterrupt
-
-def step_2(state: State) -> State:
-    # highlight-next-line
-    if len(state["input"]) > 5:
-        # highlight-next-line
-        raise NodeInterrupt( # (1)!
-            f"Received input that is longer than 5 characters: {state['foo']}"
-        )
-    return state
-```
-
-1. raise NodeInterrupt exception based on a some condition. In this example, we create a dynamic breakpoint if the length of the attribute `input` is longer than 5 characters.
-
-<details class="example"><summary>Using dynamic breakpoints</summary>
-
-```python
-from typing_extensions import TypedDict
-from IPython.display import Image, display
-
-from langgraph.graph import StateGraph, START, END
-from langgraph.checkpoint.memory import MemorySaver
-from langgraph.errors import NodeInterrupt
-
-
-class State(TypedDict):
-    input: str
-
-
-def step_1(state: State) -> State:
-    print("---Step 1---")
-    return state
-
-
-def step_2(state: State) -> State:
-    # Let's optionally raise a NodeInterrupt
-    # if the length of the input is longer than 5 characters
-    if len(state["input"]) > 5:
-        raise NodeInterrupt(
-            f"Received input that is longer than 5 characters: {state['input']}"
-        )
-    print("---Step 2---")
-    return state
-
-
-def step_3(state: State) -> State:
-    print("---Step 3---")
-    return state
-
-
-builder = StateGraph(State)
-builder.add_node("step_1", step_1)
-builder.add_node("step_2", step_2)
-builder.add_node("step_3", step_3)
-builder.add_edge(START, "step_1")
-builder.add_edge("step_1", "step_2")
-builder.add_edge("step_2", "step_3")
-builder.add_edge("step_3", END)
-
-# Set up memory
-memory = MemorySaver()
-
-# Compile the graph with memory
-graph = builder.compile(checkpointer=memory)
-
-# View
-display(Image(graph.get_graph().draw_mermaid_png()))
-```
-
-First, let's run the graph with an input that <= 5 characters long. This should safely ignore the interrupt condition we defined and return the original input at the end of the graph execution.
-
-```python
-initial_input = {"input": "hello"}
-thread_config = {"configurable": {"thread_id": "1"}}
-
-for event in graph.stream(initial_input, thread_config, stream_mode="values"):
-    print(event)
-```
-
-If we inspect the graph at this point, we can see that there are no more tasks left to run and that the graph indeed finished execution.
-
-```python
-state = graph.get_state(thread_config)
-print(state.next)
-print(state.tasks)
-```
-
-Now, let's run the graph with an input that's longer than 5 characters. This should trigger the dynamic interrupt we defined via raising a `NodeInterrupt` error inside the `step_2` node.
-
-```python
-initial_input = {"input": "hello world"}
-thread_config = {"configurable": {"thread_id": "2"}}
-
-# Run the graph until the first interruption
-for event in graph.stream(initial_input, thread_config, stream_mode="values"):
-    print(event)
-```
-
-We can see that the graph now stopped while executing `step_2`. If we inspect the graph state at this point, we can see the information on what node is set to execute next (`step_2`), as well as what node raised the interrupt (also `step_2`), and additional information about the interrupt.
-
-```python
-state = graph.get_state(thread_config)
-print(state.next)
-print(state.tasks)
-```
-
-If we try to resume the graph from the breakpoint, we will simply interrupt again as our inputs & graph state haven't changed.
-
-```python
-# NOTE: to resume the graph from a dynamic interrupt we use the same syntax as with regular interrupts -- we pass None as the input
-for event in graph.stream(None, thread_config, stream_mode="values"):
-    print(event)
-```
-
-```python
-state = graph.get_state(thread_config)
-print(state.next)
-print(state.tasks)
-```
-
-</details>
-
-## Use with subgraphs
-
-To add breakpoints to subgraph either:
-
-* Define [static breakpoints](#static-breakpoints) by specifying them when **compiling** the subgraph.
-* Define [dynamic breakpoints](#dynamic-breakpoints).
-
-<details class="example"><summary>Add breakpoints to subgraphs</summary>
-
-```python
-from typing_extensions import TypedDict
-
-from langgraph.graph import START, StateGraph
-from langgraph.checkpoint.memory import InMemorySaver
-from langgraph.types import interrupt
-
-
-class State(TypedDict):
-    foo: str
-
-
-def subgraph_node_1(state: State):
-    return {"foo": state["foo"]}
-
-
-subgraph_builder = StateGraph(State)
-subgraph_builder.add_node(subgraph_node_1)
-subgraph_builder.add_edge(START, "subgraph_node_1")
-
-subgraph = subgraph_builder.compile(interrupt_before=["subgraph_node_1"])
-
-builder = StateGraph(State)
-builder.add_node("node_1", subgraph)  # directly include subgraph as a node
-builder.add_edge(START, "node_1")
-
-checkpointer = InMemorySaver()
-graph = builder.compile(checkpointer=checkpointer)
-
-config = {"configurable": {"thread_id": "1"}}
-
-graph.invoke({"foo": ""}, config)
-
-# Fetch state including subgraph state.
-print(graph.get_state(config, subgraphs=True).tasks[0].state)
-
-# resume the subgraph
-graph.invoke(None, config)
-```
-
-</details> 

docs/docs/how-tos/human_in_the_loop/time-travel.md

@@ -1,190 +0,0 @@
-# Use time-travel
-
-To use [time-travel](../../concepts/time-travel.md) in LangGraph:
-
-1. [Run the graph](#1-run-the-graph) with initial inputs using [`invoke`][langgraph.graph.state.CompiledStateGraph.invoke] or [`stream`][langgraph.graph.state.CompiledStateGraph.stream] methods.
-2. [Identify a checkpoint in an existing thread](#2-identify-a-checkpoint): Use the [`get_state_history()`][langgraph.graph.state.CompiledStateGraph.get_state_history] method to retrieve the execution history for a specific `thread_id` and locate the desired `checkpoint_id`.  
-   Alternatively, set a [breakpoint](../../concepts/breakpoints.md) before the node(s) where you want execution to pause. You can then find the most recent checkpoint recorded up to that breakpoint.
-3. [Update the graph state (optional)](#3-update-the-state-optional): Use the [`update_state`][langgraph.graph.state.CompiledStateGraph.update_state] method to modify the graph's state at the checkpoint and resume execution from alternative state.
-4. [Resume execution from the checkpoint](#4-resume-execution-from-the-checkpoint): Use the `invoke` or `stream` methods with an input of `None` and a configuration containing the appropriate `thread_id` and `checkpoint_id`.
-
-!!! tip
-
-    For a conceptual overview of time-travel, see [Time travel](../../concepts/time-travel.md).
-
-## In a workflow
-
-This example builds a simple LangGraph workflow that generates a joke topic and writes a joke using an LLM. It demonstrates how to run the graph, retrieve past execution checkpoints, optionally modify the state, and resume execution from a chosen checkpoint to explore alternate outcomes.
-
-### Setup
-
-First we need to install the packages required
-
-```python
-%%capture --no-stderr
-%pip install --quiet -U langgraph langchain_anthropic
-```
-
-Next, we need to set API keys for Anthropic (the LLM we will use)
-
-```python
-import getpass
-import os
-
-
-def _set_env(var: str):
-    if not os.environ.get(var):
-        os.environ[var] = getpass.getpass(f"{var}: ")
-
-
-_set_env("ANTHROPIC_API_KEY")
-```
-
-<div class="admonition tip">
-    <p class="admonition-title">Set up <a href="https://smith.langchain.com">LangSmith</a> for LangGraph development</p>
-    <p style="padding-top: 5px;">
-        Sign up for LangSmith to quickly spot issues and improve the performance of your LangGraph projects. LangSmith lets you use trace data to debug, test, and monitor your LLM apps built with LangGraph — read more about how to get started <a href="https://docs.smith.langchain.com">here</a>. 
-    </p>
-</div>
-
-```python
-import uuid
-
-from typing_extensions import TypedDict, NotRequired
-from langgraph.graph import StateGraph, START, END
-from langchain.chat_models import init_chat_model
-from langgraph.checkpoint.memory import InMemorySaver
-
-
-class State(TypedDict):
-    topic: NotRequired[str]
-    joke: NotRequired[str]
-
-
-llm = init_chat_model(
-    "anthropic:claude-3-7-sonnet-latest",
-    temperature=0,
-)
-
-
-def generate_topic(state: State):
-    """LLM call to generate a topic for the joke"""
-    msg = llm.invoke("Give me a funny topic for a joke")
-    return {"topic": msg.content}
-
-
-def write_joke(state: State):
-    """LLM call to write a joke based on the topic"""
-    msg = llm.invoke(f"Write a short joke about {state['topic']}")
-    return {"joke": msg.content}
-
-
-# Build workflow
-workflow = StateGraph(State)
-
-# Add nodes
-workflow.add_node("generate_topic", generate_topic)
-workflow.add_node("write_joke", write_joke)
-
-# Add edges to connect nodes
-workflow.add_edge(START, "generate_topic")
-workflow.add_edge("generate_topic", "write_joke")
-workflow.add_edge("write_joke", END)
-
-# Compile
-checkpointer = InMemorySaver()
-graph = workflow.compile(checkpointer=checkpointer)
-graph
-```
-
-### 1. Run the graph
-
-```python
-config = {
-    "configurable": {
-        "thread_id": uuid.uuid4(),
-    }
-}
-state = graph.invoke({}, config)
-
-print(state["topic"])
-print()
-print(state["joke"])
-```
-
-**Output:**
-```
-How about "The Secret Life of Socks in the Dryer"? You know, exploring the mysterious phenomenon of how socks go into the laundry as pairs but come out as singles. Where do they go? Are they starting new lives elsewhere? Is there a sock paradise we don't know about? There's a lot of comedic potential in the everyday mystery that unites us all!
-
-# The Secret Life of Socks in the Dryer
-
-I finally discovered where all my missing socks go after the dryer. Turns out they're not missing at all—they've just eloped with someone else's socks from the laundromat to start new lives together.
-
-My blue argyle is now living in Bermuda with a red polka dot, posting vacation photos on Sockstagram and sending me lint as alimony.
-```
-
-### 2. Identify a checkpoint
-
-```python
-# The states are returned in reverse chronological order.
-states = list(graph.get_state_history(config))
-
-for state in states:
-    print(state.next)
-    print(state.config["configurable"]["checkpoint_id"])
-    print()
-```
-
-**Output:**
-```
-()
-1f02ac4a-ec9f-6524-8002-8f7b0bbeed0e
-
-('write_joke',)
-1f02ac4a-ce2a-6494-8001-cb2e2d651227
-
-('generate_topic',)
-1f02ac4a-a4e0-630d-8000-b73c254ba748
-
-('__start__',)
-1f02ac4a-a4dd-665e-bfff-e6c8c44315d9
-```
-
-```python
-# This is the state before last (states are listed in chronological order)
-selected_state = states[1]
-print(selected_state.next)
-print(selected_state.values)
-```
-
-**Output:**
-```
-('write_joke',)
-{'topic': 'How about "The Secret Life of Socks in the Dryer"? You know, exploring the mysterious phenomenon of how socks go into the laundry as pairs but come out as singles. Where do they go? Are they starting new lives elsewhere? Is there a sock paradise we don\\'t know about? There\\'s a lot of comedic potential in the everyday mystery that unites us all!'}
-```
-
-### 3. Update the state (optional)
-
-`update_state` will create a new checkpoint. The new checkpoint will be associated with the same thread, but a new checkpoint ID.
-
-```python
-new_config = graph.update_state(selected_state.config, values={"topic": "chickens"})
-print(new_config)
-```
-
-**Output:**
-```
-{'configurable': {'thread_id': 'c62e2e03-c27b-4cb6-8cea-ea9bfedae006', 'checkpoint_ns': '', 'checkpoint_id': '1f02ac4a-ecee-600b-8002-a1d21df32e4c'}}
-```
-
-### 4. Resume execution from the checkpoint
-
-```python
-graph.invoke(None, new_config)
-```
-
-**Output:**
-```python
-{'topic': 'chickens',
- 'joke': 'Why did the chicken join a band?\n\nBecause it had excellent drumsticks!'}
-``` 

docs/docs/how-tos/memory.ipynb

@@ -0,0 +1,415 @@
+{
+ "cells": [
+  {
+   "attachments": {},
+   "cell_type": "markdown",
+   "id": "15ed7413-c876-4d38-b080-79c71133549b",
+   "metadata": {},
+   "source": [
+    "# Manage memory\n",
+    "\n",
+    "Many AI applications need memory to share context across multiple interactions. LangGraph supports two types of memory essential for building conversational agents:\n",
+    "\n",
+    "- [Short-term memory](#add-short-term-memory): Tracks the ongoing conversation by maintaining message history within a session.\n",
+    "- [Long-term memory](#add-long-term-memory): Stores user-specific or application-level data across sessions.\n",
+    "\n",
+    "With [short-term memory](#add-short-term-memory) enabled, long conversations can exceed the LLM's context window. Common solutions are:\n",
+    "\n",
+    "* [Trimming](#trim-messages): Remove first or last N messages (before calling LLM)\n",
+    "* [Summarization](#summarize-messages): Summarize earlier messages in the history and replace them with a summary\n",
+    "* [Delete messages](#delete-messages) from LangGraph state permanently\n",
+    "* custom strategies (e.g., message filtering, etc.)\n",
+    "\n",
+    "This allows the agent to keep track of the conversation without exceeding the LLM's context window."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "db38b03c-5609-49e3-9b93-bad0aab47ffb",
+   "metadata": {},
+   "source": [
+    "## Add short-term memory\n",
+    "\n",
+    "Short-term memory enables agents to track multi-turn conversations:\n",
+    "\n",
+    "```python\n",
+    "# highlight-next-line\n",
+    "from langgraph.checkpoint.memory import InMemorySaver\n",
+    "from langgraph.graph import StateGraph\n",
+    "\n",
+    "# highlight-next-line\n",
+    "checkpointer = InMemorySaver()\n",
+    "\n",
+    "builder = StateGraph(...)\n",
+    "# highlight-next-line\n",
+    "graph = builder.compile(checkpointer=checkpointer)\n",
+    "\n",
+    "graph.invoke(\n",
+    "    {\"messages\": [{\"role\": \"user\", \"content\": \"hi! i am Bob\"}]},\n",
+    "    # highlight-next-line\n",
+    "    {\"configurable\": {\"thread_id\": \"1\"}},\n",
+    ")\n",
+    "```\n",
+    "\n",
+    "See the [persistence](../persistence#add-short-term-memory) guide to learn more about working with short-term memory."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "05bf55fd-b0b0-4fbf-9f15-aefac7f300bb",
+   "metadata": {},
+   "source": [
+    "## Add long-term memory\n",
+    "\n",
+    "Use long-term memory to store user-specific or application-specific data across conversations. This is useful for applications like chatbots, where you want to remember user preferences or other information.\n",
+    "\n",
+    "```python\n",
+    "# highlight-next-line\n",
+    "from langgraph.store.memory import InMemoryStore\n",
+    "from langgraph.graph import StateGraph\n",
+    "\n",
+    "# highlight-next-line\n",
+    "store = InMemoryStore()\n",
+    "\n",
+    "builder = StateGraph(...)\n",
+    "# highlight-next-line\n",
+    "graph = builder.compile(store=store)\n",
+    "```\n",
+    "\n",
+    "See the [persistence](../persistence#add-long-term-memory) guide to learn more about working with long-term memory."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "e109c1b2-a44e-4ec0-8a11-1377e59315c6",
+   "metadata": {},
+   "source": [
+    "## Trim messages\n",
+    "\n",
+    "To trim message history, you can use [`trim_messages`](https://python.langchain.com/api_reference/core/messages/langchain_core.messages.utils.trim_messages.html) function:\n",
+    "\n",
+    "```python\n",
+    "# highlight-next-line\n",
+    "from langchain_core.messages.utils import (\n",
+    "    # highlight-next-line\n",
+    "    trim_messages,\n",
+    "    # highlight-next-line\n",
+    "    count_tokens_approximately\n",
+    "# highlight-next-line\n",
+    ")\n",
+    "\n",
+    "def call_model(state: MessagesState):\n",
+    "    # highlight-next-line\n",
+    "    messages = trim_messages(\n",
+    "        state[\"messages\"],\n",
+    "        strategy=\"last\",\n",
+    "        token_counter=count_tokens_approximately,\n",
+    "        max_tokens=128,\n",
+    "        start_on=\"human\",\n",
+    "        end_on=(\"human\", \"tool\"),\n",
+    "    )\n",
+    "    response = model.invoke(messages)\n",
+    "    return {\"messages\": [response]}\n",
+    "\n",
+    "builder = StateGraph(MessagesState)\n",
+    "builder.add_node(call_model)\n",
+    "...\n",
+    "```\n",
+    "\n",
+    "??? example \"Full example: trim messages\"\n",
+    "\n",
+    "    ```python\n",
+    "    # highlight-next-line\n",
+    "    from langchain_core.messages.utils import (\n",
+    "        # highlight-next-line\n",
+    "        trim_messages,\n",
+    "        # highlight-next-line\n",
+    "        count_tokens_approximately\n",
+    "    # highlight-next-line\n",
+    "    )\n",
+    "    from langchain.chat_models import init_chat_model\n",
+    "    from langgraph.graph import StateGraph, START, MessagesState\n",
+    "    \n",
+    "    model = init_chat_model(\"anthropic:claude-3-7-sonnet-latest\")\n",
+    "    summarization_model = model.bind(max_tokens=128)\n",
+    "    \n",
+    "    def call_model(state: MessagesState):\n",
+    "        # highlight-next-line\n",
+    "        messages = trim_messages(\n",
+    "            state[\"messages\"],\n",
+    "            strategy=\"last\",\n",
+    "            token_counter=count_tokens_approximately,\n",
+    "            max_tokens=128,\n",
+    "            start_on=\"human\",\n",
+    "            end_on=(\"human\", \"tool\"),\n",
+    "        )\n",
+    "        response = model.invoke(messages)\n",
+    "        return {\"messages\": [response]}\n",
+    "    \n",
+    "    checkpointer = InMemorySaver()\n",
+    "    builder = StateGraph(MessagesState)\n",
+    "    builder.add_node(call_model)\n",
+    "    builder.add_edge(START, \"call_model\")\n",
+    "    graph = builder.compile(checkpointer=checkpointer)\n",
+    "    \n",
+    "    config = {\"configurable\": {\"thread_id\": \"1\"}}\n",
+    "    graph.invoke({\"messages\": \"hi, my name is bob\"}, config)\n",
+    "    graph.invoke({\"messages\": \"write a short poem about cats\"}, config)\n",
+    "    graph.invoke({\"messages\": \"now do the same but for dogs\"}, config)\n",
+    "    final_response = graph.invoke({\"messages\": \"what's my name?\"}, config)\n",
+    "\n",
+    "    final_response[\"messages\"][-1].pretty_print()\n",
+    "    ```\n",
+    "\n",
+    "    ```\n",
+    "    ================================== Ai Message ==================================\n",
+    "    \n",
+    "    Your name is Bob, as you mentioned when you first introduced yourself.\n",
+    "    ```"
+   ]
+  },
+  {
+   "attachments": {},
+   "cell_type": "markdown",
+   "id": "6676cd03-3e97-4550-ad4a-72d04f2cee7c",
+   "metadata": {},
+   "source": [
+    "## Summarize messages\n",
+    "\n",
+    "An effective strategy for handling long conversation history is to summarize earlier messages once they reach a certain threshold:\n",
+    "\n",
+    "```python\n",
+    "from typing import Any, TypedDict\n",
+    "\n",
+    "from langchain_core.messages import AnyMessage\n",
+    "from langchain_core.messages.utils import count_tokens_approximately\n",
+    "# highlight-next-line\n",
+    "from langmem.short_term import SummarizationNode\n",
+    "from langgraph.graph import StateGraph, START, MessagesState\n",
+    "\n",
+    "class State(MessagesState):\n",
+    "    # highlight-next-line\n",
+    "    context: dict[str, Any]  # (1)!\n",
+    "\n",
+    "class LLMInputState(TypedDict):  # (2)!\n",
+    "    summarized_messages: list[AnyMessage]\n",
+    "    context: dict[str, Any]\n",
+    "\n",
+    "# highlight-next-line\n",
+    "summarization_node = SummarizationNode(\n",
+    "    token_counter=count_tokens_approximately,\n",
+    "    model=summarization_model,\n",
+    "    max_tokens=512,\n",
+    "    max_tokens_before_summary=256,\n",
+    "    max_summary_tokens=256,\n",
+    ")\n",
+    "\n",
+    "# highlight-next-line\n",
+    "def call_model(state: LLMInputState):  # (3)!\n",
+    "    response = model.invoke(state[\"summarized_messages\"])\n",
+    "    return {\"messages\": [response]}\n",
+    "\n",
+    "builder = StateGraph(State)\n",
+    "builder.add_node(call_model)\n",
+    "# highlight-next-line\n",
+    "builder.add_node(\"summarize\", summarization_node)\n",
+    "builder.add_edge(START, \"summarize\")\n",
+    "builder.add_edge(\"summarize\", \"call_model\")\n",
+    "...\n",
+    "```\n",
+    "\n",
+    "1. We will keep track of our running summary in the `context` field\n",
+    "(expected by the `SummarizationNode`).\n",
+    "2. Define private state that will be used only for filtering\n",
+    "the inputs to `call_model` node.\n",
+    "3. We're passing a private input state here to isolate the messages returned by the summarization node\n",
+    "\n",
+    "??? example \"Full example: summarize messages\"\n",
+    "\n",
+    "    ```python\n",
+    "    from typing import Any, TypedDict\n",
+    "    \n",
+    "    from langchain.chat_models import init_chat_model\n",
+    "    from langchain_core.messages import AnyMessage\n",
+    "    from langchain_core.messages.utils import count_tokens_approximately\n",
+    "    from langgraph.graph import StateGraph, START, MessagesState\n",
+    "    from langgraph.checkpoint.memory import InMemorySaver\n",
+    "    # highlight-next-line\n",
+    "    from langmem.short_term import SummarizationNode\n",
+    "    \n",
+    "    model = init_chat_model(\"anthropic:claude-3-7-sonnet-latest\")\n",
+    "    summarization_model = model.bind(max_tokens=128)\n",
+    "    \n",
+    "    class State(MessagesState):\n",
+    "        # highlight-next-line\n",
+    "        context: dict[str, Any]  # (1)!\n",
+    "    \n",
+    "    class LLMInputState(TypedDict):  # (2)!\n",
+    "        summarized_messages: list[AnyMessage]\n",
+    "        context: dict[str, Any]\n",
+    "    \n",
+    "    # highlight-next-line\n",
+    "    summarization_node = SummarizationNode(\n",
+    "        token_counter=count_tokens_approximately,\n",
+    "        model=summarization_model,\n",
+    "        max_tokens=256,\n",
+    "        max_tokens_before_summary=256,\n",
+    "        max_summary_tokens=128,\n",
+    "    )\n",
+    "\n",
+    "    # highlight-next-line\n",
+    "    def call_model(state: LLMInputState):  # (3)!\n",
+    "        response = model.invoke(state[\"summarized_messages\"])\n",
+    "        return {\"messages\": [response]}\n",
+    "    \n",
+    "    checkpointer = InMemorySaver()\n",
+    "    builder = StateGraph(State)\n",
+    "    builder.add_node(call_model)\n",
+    "    # highlight-next-line\n",
+    "    builder.add_node(\"summarize\", summarization_node)\n",
+    "    builder.add_edge(START, \"summarize\")\n",
+    "    builder.add_edge(\"summarize\", \"call_model\")\n",
+    "    graph = builder.compile(checkpointer=checkpointer)\n",
+    "    \n",
+    "    # Invoke the graph\n",
+    "    config = {\"configurable\": {\"thread_id\": \"1\"}}\n",
+    "    graph.invoke({\"messages\": \"hi, my name is bob\"}, config)\n",
+    "    graph.invoke({\"messages\": \"write a short poem about cats\"}, config)\n",
+    "    graph.invoke({\"messages\": \"now do the same but for dogs\"}, config)\n",
+    "    final_response = graph.invoke({\"messages\": \"what's my name?\"}, config)\n",
+    "\n",
+    "    final_response[\"messages\"][-1].pretty_print()\n",
+    "    print(\"\\nSummary:\", final_response[\"context\"][\"running_summary\"].summary)\n",
+    "    ```\n",
+    "\n",
+    "    1. We will keep track of our running summary in the `context` field\n",
+    "    (expected by the `SummarizationNode`).\n",
+    "    2. Define private state that will be used only for filtering\n",
+    "    the inputs to `call_model` node.\n",
+    "    3. We're passing a private input state here to isolate the messages returned by the summarization node\n",
+    "\n",
+    "    ```\n",
+    "    ================================== Ai Message ==================================\n",
+    "\n",
+    "    From our conversation, I can see that you introduced yourself as Bob. That's the name you shared with me when we began talking.\n",
+    "    \n",
+    "    Summary: In this conversation, I was introduced to Bob, who then asked me to write a poem about cats. I composed a poem titled \"The Mystery of Cats\" that captured cats' graceful movements, independent nature, and their special relationship with humans. Bob then requested a similar poem about dogs, so I wrote \"The Joy of Dogs,\" which highlighted dogs' loyalty, enthusiasm, and loving companionship. Both poems were written in a similar style but emphasized the distinct characteristics that make each pet special.\n",
+    "    ```"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "361d880b-1258-4708-8f0e-5efc95031e78",
+   "metadata": {},
+   "source": [
+    "## Delete messages\n",
+    "\n",
+    "To delete messages from the graph state, you can use the `RemoveMessage`.\n",
+    "\n",
+    "* Remove specific messages:\n",
+    "\n",
+    "    ```python\n",
+    "    # highlight-next-line\n",
+    "    from langchain_core.messages import RemoveMessage\n",
+    "    \n",
+    "    def delete_messages(state):\n",
+    "        messages = state[\"messages\"]\n",
+    "        if len(messages) > 2:\n",
+    "            # remove the earliest two messages\n",
+    "            # highlight-next-line\n",
+    "            return {\"messages\": [RemoveMessage(id=m.id) for m in messages[:2]]}\n",
+    "    ```\n",
+    "\n",
+    "* Remove **all** messages:\n",
+    "    \n",
+    "    ```python\n",
+    "    # highlight-next-line\n",
+    "    from langgraph.graph.message import REMOVE_ALL_MESSAGES\n",
+    "    \n",
+    "    def delete_messages(state):\n",
+    "        # highlight-next-line\n",
+    "        return {\"messages\": [RemoveMessage(id=REMOVE_ALL_MESSAGES)]}\n",
+    "    ```\n",
+    "\n",
+    "!!! important \"`add_messages` reducer\"\n",
+    "\n",
+    "    For `RemoveMessage` to work, you need to use a state key with [`add_messages`][langgraph.graph.message.add_messages] [reducer](../../../concepts/low_level#reducers), like [`MessagesState`](../../../concepts/low_level#messagesstate)\n",
+    "\n",
+    "!!! warning \"Valid message history\"\n",
+    "\n",
+    "    When deleting messages, **make sure** that the resulting message history is valid. Check the limitations of the LLM provider you're using. For example:\n",
+    "    \n",
+    "    * some providers expect message history to start with a `user` message\n",
+    "    * most providers require `assistant` messages with tool calls to be followed by corresponding `tool` result messages.\n",
+    "\n",
+    "??? example \"Full example: delete messages\"\n",
+    "\n",
+    "    ```python\n",
+    "    # highlight-next-line\n",
+    "    from langchain_core.messages import RemoveMessage\n",
+    "    \n",
+    "    def delete_messages(state):\n",
+    "        messages = state[\"messages\"]\n",
+    "        if len(messages) > 2:\n",
+    "            # remove the earliest two messages\n",
+    "            # highlight-next-line\n",
+    "            return {\"messages\": [RemoveMessage(id=m.id) for m in messages[:2]]}\n",
+    "    \n",
+    "    def call_model(state: MessagesState):\n",
+    "        response = model.invoke(state[\"messages\"])\n",
+    "        return {\"messages\": response}\n",
+    "    \n",
+    "    builder = StateGraph(MessagesState)\n",
+    "    builder.add_sequence([call_model, delete_messages])\n",
+    "    builder.add_edge(START, \"call_model\")\n",
+    "    \n",
+    "    checkpointer = InMemorySaver()\n",
+    "    app = builder.compile(checkpointer=checkpointer)\n",
+    "    \n",
+    "    for event in app.stream(\n",
+    "        {\"messages\": [{\"role\": \"user\", \"content\": \"hi! I'm bob\"}]},\n",
+    "        config,\n",
+    "        stream_mode=\"values\"\n",
+    "    ):\n",
+    "        print([(message.type, message.content) for message in event[\"messages\"]])\n",
+    "    \n",
+    "    for event in app.stream(\n",
+    "        {\"messages\": [{\"role\": \"user\", \"content\": \"what's my name?\"}]},\n",
+    "        config,\n",
+    "        stream_mode=\"values\"\n",
+    "    ):\n",
+    "        print([(message.type, message.content) for message in event[\"messages\"]])\n",
+    "    ```\n",
+    "\n",
+    "    ```\n",
+    "    [('human', \"hi! I'm bob\")]\n",
+    "    [('human', \"hi! I'm bob\"), ('ai', 'Hi Bob! How are you doing today? Is there anything I can help you with?')]\n",
+    "    [('human', \"hi! I'm bob\"), ('ai', 'Hi Bob! How are you doing today? Is there anything I can help you with?'), ('human', \"what's my name?\")]\n",
+    "    [('human', \"hi! I'm bob\"), ('ai', 'Hi Bob! How are you doing today? Is there anything I can help you with?'), ('human', \"what's my name?\"), ('ai', 'Your name is Bob.')]\n",
+    "    [('human', \"what's my name?\"), ('ai', 'Your name is Bob.')]\n",
+    "    ```"
+   ]
+  }
+ ],
+ "metadata": {
+  "kernelspec": {
+   "display_name": "Python 3 (ipykernel)",
+   "language": "python",
+   "name": "python3"
+  },
+  "language_info": {
+   "codemirror_mode": {
+    "name": "ipython",
+    "version": 3
+   },
+   "file_extension": ".py",
+   "mimetype": "text/x-python",
+   "name": "python",
+   "nbconvert_exporter": "python",
+   "pygments_lexer": "ipython3",
+   "version": "3.12.3"
+  }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 5
+}

docs/docs/how-tos/review-tool-calls-functional.ipynb

@@ -0,0 +1,627 @@
+{
+ "cells": [
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "# How to review tool calls (Functional API)\n",
+    "\n",
+    "!!! info \"Prerequisites\"\n",
+    "    This guide assumes familiarity with the following:\n",
+    "\n",
+    "    - Implementing [human-in-the-loop](../../concepts/human_in_the_loop) workflows with [interrupt](../../concepts/human_in_the_loop/#interrupt)\n",
+    "    - [How to create a ReAct agent using the Functional API](../../how-tos/react-agent-from-scratch-functional)\n",
+    "\n",
+    "This guide demonstrates how to implement human-in-the-loop workflows in a ReAct agent using the LangGraph [Functional API](../../concepts/functional_api).\n",
+    "\n",
+    "We will build off of the agent created in the [How to create a ReAct agent using the Functional API](../../how-tos/react-agent-from-scratch-functional) guide.\n",
+    "\n",
+    "Specifically, we will demonstrate how to review [tool calls](https://python.langchain.com/docs/concepts/tool_calling/) generated by a [chat model](https://python.langchain.com/docs/concepts/chat_models/) prior to their execution. This can be accomplished through use of the [interrupt](../../concepts/human_in_the_loop/#interrupt) function at key points in our application.\n",
+    "\n",
+    "**Preview**:\n",
+    "\n",
+    "We will implement a simple function that reviews tool calls generated from our chat model and call it from inside our application's [entrypoint](../../concepts/functional_api/#entrypoint):\n",
+    "\n",
+    "```python\n",
+    "def review_tool_call(tool_call: ToolCall) -> Union[ToolCall, ToolMessage]:\n",
+    "    \"\"\"Review a tool call, returning a validated version.\"\"\"\n",
+    "    human_review = interrupt(\n",
+    "        {\n",
+    "            \"question\": \"Is this correct?\",\n",
+    "            \"tool_call\": tool_call,\n",
+    "        }\n",
+    "    )\n",
+    "    review_action = human_review[\"action\"]\n",
+    "    review_data = human_review.get(\"data\")\n",
+    "    if review_action == \"continue\":\n",
+    "        return tool_call\n",
+    "    elif review_action == \"update\":\n",
+    "        updated_tool_call = {**tool_call, **{\"args\": review_data}}\n",
+    "        return updated_tool_call\n",
+    "    elif review_action == \"feedback\":\n",
+    "        return ToolMessage(\n",
+    "            content=review_data, name=tool_call[\"name\"], tool_call_id=tool_call[\"id\"]\n",
+    "        )\n",
+    "```\n",
+    "\n",
+    "## Setup\n",
+    "\n",
+    "First, let's install the required packages and set our API keys:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 1,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "%%capture --no-stderr\n",
+    "%pip install -U langgraph langchain-openai"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 2,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "import getpass\n",
+    "import os\n",
+    "\n",
+    "\n",
+    "def _set_env(var: str):\n",
+    "    if not os.environ.get(var):\n",
+    "        os.environ[var] = getpass.getpass(f\"{var}: \")\n",
+    "\n",
+    "\n",
+    "_set_env(\"OPENAI_API_KEY\")"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "<div class=\"admonition tip\">\n",
+    "     <p class=\"admonition-title\">Set up <a href=\"https://smith.langchain.com\">LangSmith</a> for better debugging</p>\n",
+    "     <p style=\"padding-top: 5px;\">\n",
+    "         Sign up for LangSmith to quickly spot issues and improve the performance of your LangGraph projects. LangSmith lets you use trace data to debug, test, and monitor your LLM aps built with LangGraph — read more about how to get started in the <a href=\"https://docs.smith.langchain.com\">docs</a>. \n",
+    "     </p>\n",
+    " </div>"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## Define model and tools\n",
+    "\n",
+    "Let's first define the tools and model we will use for our example. As in the [ReAct agent guide](../../how-tos/react-agent-from-scratch-functional), we will use a single place-holder tool that gets a description of the weather for a location.\n",
+    "\n",
+    "We will use an [OpenAI](https://python.langchain.com/docs/integrations/providers/openai/) chat model for this example, but any model [supporting tool-calling](https://python.langchain.com/docs/integrations/chat/) will suffice."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 1,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langchain_openai import ChatOpenAI\n",
+    "from langchain_core.tools import tool\n",
+    "\n",
+    "model = ChatOpenAI(model=\"gpt-4o-mini\")\n",
+    "\n",
+    "\n",
+    "@tool\n",
+    "def get_weather(location: str):\n",
+    "    \"\"\"Call to get the weather from a specific location.\"\"\"\n",
+    "    # This is a placeholder for the actual implementation\n",
+    "    if any([city in location.lower() for city in [\"sf\", \"san francisco\"]]):\n",
+    "        return \"It's sunny!\"\n",
+    "    elif \"boston\" in location.lower():\n",
+    "        return \"It's rainy!\"\n",
+    "    else:\n",
+    "        return f\"I am not sure what the weather is in {location}\"\n",
+    "\n",
+    "\n",
+    "tools = [get_weather]"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## Define tasks\n",
+    "\n",
+    "Our [tasks](../../concepts/functional_api/#task) are unchanged from the [ReAct agent guide](../../how-tos/react-agent-from-scratch-functional):\n",
+    "\n",
+    "1. **Call model**: We want to query our chat model with a list of messages.\n",
+    "2. **Call tool**: If our model generates tool calls, we want to execute them."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 2,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langchain_core.messages import ToolCall, ToolMessage\n",
+    "from langgraph.func import entrypoint, task\n",
+    "\n",
+    "\n",
+    "tools_by_name = {tool.name: tool for tool in tools}\n",
+    "\n",
+    "\n",
+    "@task\n",
+    "def call_model(messages):\n",
+    "    \"\"\"Call model with a sequence of messages.\"\"\"\n",
+    "    response = model.bind_tools(tools).invoke(messages)\n",
+    "    return response\n",
+    "\n",
+    "\n",
+    "@task\n",
+    "def call_tool(tool_call):\n",
+    "    tool = tools_by_name[tool_call[\"name\"]]\n",
+    "    observation = tool.invoke(tool_call[\"args\"])\n",
+    "    return ToolMessage(content=observation, tool_call_id=tool_call[\"id\"])"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## Define entrypoint\n",
+    "\n",
+    "To review tool calls before execution, we add a `review_tool_call` function that calls [interrupt](../../concepts/human_in_the_loop/#interrupt). When this function is called, execution will be paused until we issue a command to resume it.\n",
+    "\n",
+    "Given a tool call, our function will `interrupt` for human review. At that point we can either:\n",
+    "\n",
+    "- Accept the tool call;\n",
+    "- Revise the tool call and continue;\n",
+    "- Generate a custom tool message (e.g., instructing the model to re-format its tool call).\n",
+    "\n",
+    "We will demonstrate these three cases in the [usage examples](#usage) below."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 3,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from typing import Union\n",
+    "\n",
+    "\n",
+    "def review_tool_call(tool_call: ToolCall) -> Union[ToolCall, ToolMessage]:\n",
+    "    \"\"\"Review a tool call, returning a validated version.\"\"\"\n",
+    "    human_review = interrupt(\n",
+    "        {\n",
+    "            \"question\": \"Is this correct?\",\n",
+    "            \"tool_call\": tool_call,\n",
+    "        }\n",
+    "    )\n",
+    "    review_action = human_review[\"action\"]\n",
+    "    review_data = human_review.get(\"data\")\n",
+    "    if review_action == \"continue\":\n",
+    "        return tool_call\n",
+    "    elif review_action == \"update\":\n",
+    "        updated_tool_call = {**tool_call, **{\"args\": review_data}}\n",
+    "        return updated_tool_call\n",
+    "    elif review_action == \"feedback\":\n",
+    "        return ToolMessage(\n",
+    "            content=review_data, name=tool_call[\"name\"], tool_call_id=tool_call[\"id\"]\n",
+    "        )"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "We can now update our [entrypoint](../../concepts/functional_api/#entrypoint) to review the generated tool calls. If a tool call is accepted or revised, we execute in the same way as before. Otherwise, we just append the `ToolMessage` supplied by the human.\n",
+    "\n",
+    "!!! tip\n",
+    "\n",
+    "    The results of prior tasks — in this case the initial model call — are persisted, so that they are not run again following the `interrupt`."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 4,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langgraph.checkpoint.memory import MemorySaver\n",
+    "from langgraph.graph.message import add_messages\n",
+    "from langgraph.types import Command, interrupt\n",
+    "\n",
+    "\n",
+    "checkpointer = MemorySaver()\n",
+    "\n",
+    "\n",
+    "@entrypoint(checkpointer=checkpointer)\n",
+    "def agent(messages, previous):\n",
+    "    if previous is not None:\n",
+    "        messages = add_messages(previous, messages)\n",
+    "\n",
+    "    llm_response = call_model(messages).result()\n",
+    "    while True:\n",
+    "        if not llm_response.tool_calls:\n",
+    "            break\n",
+    "\n",
+    "        # Review tool calls\n",
+    "        tool_results = []\n",
+    "        tool_calls = []\n",
+    "        for i, tool_call in enumerate(llm_response.tool_calls):\n",
+    "            review = review_tool_call(tool_call)\n",
+    "            if isinstance(review, ToolMessage):\n",
+    "                tool_results.append(review)\n",
+    "            else:  # is a validated tool call\n",
+    "                tool_calls.append(review)\n",
+    "                if review != tool_call:\n",
+    "                    llm_response.tool_calls[i] = review  # update message\n",
+    "\n",
+    "        # Execute remaining tool calls\n",
+    "        tool_result_futures = [call_tool(tool_call) for tool_call in tool_calls]\n",
+    "        remaining_tool_results = [fut.result() for fut in tool_result_futures]\n",
+    "\n",
+    "        # Append to message list\n",
+    "        messages = add_messages(\n",
+    "            messages,\n",
+    "            [llm_response, *tool_results, *remaining_tool_results],\n",
+    "        )\n",
+    "\n",
+    "        # Call model again\n",
+    "        llm_response = call_model(messages).result()\n",
+    "\n",
+    "    # Generate final response\n",
+    "    messages = add_messages(messages, llm_response)\n",
+    "    return entrypoint.final(value=llm_response, save=messages)"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### Usage\n",
+    "\n",
+    "Let's demonstrate some scenarios."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 5,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "def _print_step(step: dict) -> None:\n",
+    "    for task_name, result in step.items():\n",
+    "        if task_name == \"agent\":\n",
+    "            continue  # just stream from tasks\n",
+    "        print(f\"\\n{task_name}:\")\n",
+    "        if task_name in (\"__interrupt__\", \"review_tool_call\"):\n",
+    "            print(result)\n",
+    "        else:\n",
+    "            result.pretty_print()"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### Accept a tool call\n",
+    "\n",
+    "To accept a tool call, we just indicate in the data we provide in the `Command` that the tool call should pass through."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 6,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "config = {\"configurable\": {\"thread_id\": \"1\"}}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 7,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "{'role': 'user', 'content': \"What's the weather in san francisco?\"}\n",
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "Tool Calls:\n",
+      "  get_weather (call_Bh5cSwMqCpCxTjx7AjdrQTPd)\n",
+      " Call ID: call_Bh5cSwMqCpCxTjx7AjdrQTPd\n",
+      "  Args:\n",
+      "    location: San Francisco\n",
+      "\n",
+      "__interrupt__:\n",
+      "(Interrupt(value={'question': 'Is this correct?', 'tool_call': {'name': 'get_weather', 'args': {'location': 'San Francisco'}, 'id': 'call_Bh5cSwMqCpCxTjx7AjdrQTPd', 'type': 'tool_call'}}, resumable=True, ns=['agent:22fcc9cd-3573-b39b-eea7-272a025903e2'], when='during'),)\n"
+     ]
+    }
+   ],
+   "source": [
+    "user_message = {\"role\": \"user\", \"content\": \"What's the weather in san francisco?\"}\n",
+    "print(user_message)\n",
+    "\n",
+    "for step in agent.stream([user_message], config):\n",
+    "    _print_step(step)"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 8,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "\n",
+      "call_tool:\n",
+      "=================================\u001b[1m Tool Message \u001b[0m=================================\n",
+      "\n",
+      "It's sunny!\n",
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "\n",
+      "The weather in San Francisco is sunny!\n"
+     ]
+    }
+   ],
+   "source": [
+    "# highlight-next-line\n",
+    "human_input = Command(resume={\"action\": \"continue\"})\n",
+    "\n",
+    "for step in agent.stream(human_input, config):\n",
+    "    _print_step(step)"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### Revise a tool call\n",
+    "\n",
+    "To revise a tool call, we can supply updated arguments."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 9,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "config = {\"configurable\": {\"thread_id\": \"2\"}}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 10,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "{'role': 'user', 'content': \"What's the weather in san francisco?\"}\n",
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "Tool Calls:\n",
+      "  get_weather (call_b9h8e18FqH0IQm3NMoeYKz6N)\n",
+      " Call ID: call_b9h8e18FqH0IQm3NMoeYKz6N\n",
+      "  Args:\n",
+      "    location: san francisco\n",
+      "\n",
+      "__interrupt__:\n",
+      "(Interrupt(value={'question': 'Is this correct?', 'tool_call': {'name': 'get_weather', 'args': {'location': 'san francisco'}, 'id': 'call_b9h8e18FqH0IQm3NMoeYKz6N', 'type': 'tool_call'}}, resumable=True, ns=['agent:9559a81d-5720-dc19-a457-457bac7bdd83'], when='during'),)\n"
+     ]
+    }
+   ],
+   "source": [
+    "user_message = {\"role\": \"user\", \"content\": \"What's the weather in san francisco?\"}\n",
+    "print(user_message)\n",
+    "\n",
+    "for step in agent.stream([user_message], config):\n",
+    "    _print_step(step)"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 11,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "\n",
+      "call_tool:\n",
+      "=================================\u001b[1m Tool Message \u001b[0m=================================\n",
+      "\n",
+      "It's sunny!\n",
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "\n",
+      "The weather in San Francisco is sunny!\n"
+     ]
+    }
+   ],
+   "source": [
+    "# highlight-next-line\n",
+    "human_input = Command(resume={\"action\": \"update\", \"data\": {\"location\": \"SF, CA\"}})\n",
+    "\n",
+    "for step in agent.stream(human_input, config):\n",
+    "    _print_step(step)"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "The LangSmith traces for this run are particularly informative:\n",
+    "\n",
+    "- In the trace [before the interrupt](https://smith.langchain.com/public/c8b07579-5cf4-4adb-a849-282163bc9d99/r/b5b128d6-e715-480b-b58d-59e64f724275), we generate a tool call for location `\"San Francisco\"`.\n",
+    "- In the trace [after resuming](https://smith.langchain.com/public/b28b92e5-a555-482d-aa4d-c675a19f0eb5/r), we see that the tool call in the message has been updated to `\"SF, CA\"`."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### Generate a custom ToolMessage\n",
+    "\n",
+    "To Generate a custom `ToolMessage`, we supply the content of the message. In this case we will ask the model to reformat its tool call."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 12,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "config = {\"configurable\": {\"thread_id\": \"3\"}}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 13,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "{'role': 'user', 'content': \"What's the weather in san francisco?\"}\n",
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "Tool Calls:\n",
+      "  get_weather (call_VqGjKE7uu8HdWs9XuY1kMV18)\n",
+      " Call ID: call_VqGjKE7uu8HdWs9XuY1kMV18\n",
+      "  Args:\n",
+      "    location: San Francisco\n",
+      "\n",
+      "__interrupt__:\n",
+      "(Interrupt(value={'question': 'Is this correct?', 'tool_call': {'name': 'get_weather', 'args': {'location': 'San Francisco'}, 'id': 'call_VqGjKE7uu8HdWs9XuY1kMV18', 'type': 'tool_call'}}, resumable=True, ns=['agent:4b3b372b-9da3-70be-5c68-3d9317346070'], when='during'),)\n"
+     ]
+    }
+   ],
+   "source": [
+    "user_message = {\"role\": \"user\", \"content\": \"What's the weather in san francisco?\"}\n",
+    "print(user_message)\n",
+    "\n",
+    "for step in agent.stream([user_message], config):\n",
+    "    _print_step(step)"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 14,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "Tool Calls:\n",
+      "  get_weather (call_xoXkK8Cz0zIpvWs78qnXpvYp)\n",
+      " Call ID: call_xoXkK8Cz0zIpvWs78qnXpvYp\n",
+      "  Args:\n",
+      "    location: San Francisco, CA\n",
+      "\n",
+      "__interrupt__:\n",
+      "(Interrupt(value={'question': 'Is this correct?', 'tool_call': {'name': 'get_weather', 'args': {'location': 'San Francisco, CA'}, 'id': 'call_xoXkK8Cz0zIpvWs78qnXpvYp', 'type': 'tool_call'}}, resumable=True, ns=['agent:4b3b372b-9da3-70be-5c68-3d9317346070'], when='during'),)\n"
+     ]
+    }
+   ],
+   "source": [
+    "# highlight-next-line\n",
+    "human_input = Command(\n",
+    "    # highlight-next-line\n",
+    "    resume={\n",
+    "        # highlight-next-line\n",
+    "        \"action\": \"feedback\",\n",
+    "        # highlight-next-line\n",
+    "        \"data\": \"Please format as <City>, <State>.\",\n",
+    "        # highlight-next-line\n",
+    "    },\n",
+    "    # highlight-next-line\n",
+    ")\n",
+    "\n",
+    "for step in agent.stream(human_input, config):\n",
+    "    _print_step(step)"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "Once it is re-formatted, we can accept it:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 15,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "\n",
+      "call_tool:\n",
+      "=================================\u001b[1m Tool Message \u001b[0m=================================\n",
+      "\n",
+      "It's sunny!\n",
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "\n",
+      "The weather in San Francisco, CA is sunny!\n"
+     ]
+    }
+   ],
+   "source": [
+    "# highlight-next-line\n",
+    "human_input = Command(resume={\"action\": \"continue\"})\n",
+    "\n",
+    "for step in agent.stream(human_input, config):\n",
+    "    _print_step(step)"
+   ]
+  }
+ ],
+ "metadata": {
+  "kernelspec": {
+   "display_name": "Python 3 (ipykernel)",
+   "language": "python",
+   "name": "python3"
+  },
+  "language_info": {
+   "codemirror_mode": {
+    "name": "ipython",
+    "version": 3
+   },
+   "file_extension": ".py",
+   "mimetype": "text/x-python",
+   "name": "python",
+   "nbconvert_exporter": "python",
+   "pygments_lexer": "ipython3",
+   "version": "3.12.3"
+  }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}

docs/docs/how-tos/streaming.md

@@ -1,220 +1,11 @@
 # Stream outputs
 
-You can [stream outputs](../concepts/streaming.md) from a LangGraph agent or workflow.
-
-## Supported stream modes
-
-Pass one or more of the following stream modes as a list to the [`stream()`][langgraph.graph.state.CompiledStateGraph.stream] or [`astream()`][langgraph.graph.state.CompiledStateGraph.astream] methods:
-
-| Mode | Description |
-|------|-------------|
-| `values` | Streams the full value of the state after each step of the graph. |
-| `updates` | Streams the updates to the state after each step of the graph. If multiple updates are made in the same step (e.g., multiple nodes are run), those updates are streamed separately. |
-| `custom` | Streams custom data from inside your graph nodes. |
-| `messages` | Streams 2-tuples (LLM token, metadata) from any graph nodes where an LLM is invoked. |
-| `debug` | Streams as much information as possible throughout the execution of the graph.   
-
-## Stream from an agent
-
-### Agent progress
-
-To stream agent progress, use the [`stream()`][langgraph.graph.state.CompiledStateGraph.stream] or [`astream()`][langgraph.graph.state.CompiledStateGraph.astream] methods with `stream_mode="updates"`. This emits an event after every agent step.
-
-For example, if you have an agent that calls a tool once, you should see the following updates:
-
-* **LLM node**: AI message with tool call requests
-* **Tool node**: Tool message with execution result
-* **LLM node**: Final AI response
-
-=== "Sync"
-
-    ```python
-    agent = create_react_agent(
-        model="anthropic:claude-3-7-sonnet-latest",
-        tools=[get_weather],
-    )
-    # highlight-next-line
-    for chunk in agent.stream(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
-        # highlight-next-line
-        stream_mode="updates"
-    ):
-        print(chunk)
-        print("\n")
-    ```
-
-=== "Async"
-
-    ```python
-    agent = create_react_agent(
-        model="anthropic:claude-3-7-sonnet-latest",
-        tools=[get_weather],
-    )
-    # highlight-next-line
-    async for chunk in agent.astream(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
-        # highlight-next-line
-        stream_mode="updates"
-    ):
-        print(chunk)
-        print("\n")
-    ```
-
-### LLM tokens
-
-To stream tokens as they are produced by the LLM, use `stream_mode="messages"`:
-
-=== "Sync"
-
-    ```python
-    agent = create_react_agent(
-        model="anthropic:claude-3-7-sonnet-latest",
-        tools=[get_weather],
-    )
-    # highlight-next-line
-    for token, metadata in agent.stream(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
-        # highlight-next-line
-        stream_mode="messages"
-    ):
-        print("Token", token)
-        print("Metadata", metadata)
-        print("\n")
-    ```
-
-=== "Async"
-
-    ```python
-    agent = create_react_agent(
-        model="anthropic:claude-3-7-sonnet-latest",
-        tools=[get_weather],
-    )
-    # highlight-next-line
-    async for token, metadata in agent.astream(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
-        # highlight-next-line
-        stream_mode="messages"
-    ):
-        print("Token", token)
-        print("Metadata", metadata)
-        print("\n")
-    ```
-
-### Tool updates
-
-To stream updates from tools as they are executed, you can use [get_stream_writer][langgraph.config.get_stream_writer].
-
-=== "Sync"
-
-    ```python
-    # highlight-next-line
-    from langgraph.config import get_stream_writer
-
-    def get_weather(city: str) -> str:
-        """Get weather for a given city."""
-        # highlight-next-line
-        writer = get_stream_writer()
-        # stream any arbitrary data
-        # highlight-next-line
-        writer(f"Looking up data for city: {city}")
-        return f"It's always sunny in {city}!"
-
-    agent = create_react_agent(
-        model="anthropic:claude-3-7-sonnet-latest",
-        tools=[get_weather],
-    )
-
-    for chunk in agent.stream(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
-        # highlight-next-line
-        stream_mode="custom"
-    ):
-        print(chunk)
-        print("\n")
-    ```
-
-=== "Async"
-
-    ```python
-    # highlight-next-line
-    from langgraph.config import get_stream_writer
-
-    def get_weather(city: str) -> str:
-        """Get weather for a given city."""
-        # highlight-next-line
-        writer = get_stream_writer()
-        # stream any arbitrary data
-        # highlight-next-line
-        writer(f"Looking up data for city: {city}")
-        return f"It's always sunny in {city}!"
-
-    agent = create_react_agent(
-        model="anthropic:claude-3-7-sonnet-latest",
-        tools=[get_weather],
-    )
-
-    async for chunk in agent.astream(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
-        # highlight-next-line
-        stream_mode="custom"
-    ):
-        print(chunk)
-        print("\n")
-    ```
-
-!!! Note
-    If you add `get_stream_writer` inside your tool, you won't be able to invoke the tool outside of a LangGraph execution context. 
-
-### Stream multiple modes
-
-You can specify multiple streaming modes by passing stream mode as a list: `stream_mode=["updates", "messages", "custom"]`:
-
-=== "Sync"
-
-    ```python
-    agent = create_react_agent(
-        model="anthropic:claude-3-7-sonnet-latest",
-        tools=[get_weather],
-    )
-
-    for stream_mode, chunk in agent.stream(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
-        # highlight-next-line
-        stream_mode=["updates", "messages", "custom"]
-    ):
-        print(chunk)
-        print("\n")
-    ```
-
-=== "Async"
-
-    ```python
-    agent = create_react_agent(
-        model="anthropic:claude-3-7-sonnet-latest",
-        tools=[get_weather],
-    )
-
-    async for stream_mode, chunk in agent.astream(
-        {"messages": [{"role": "user", "content": "what is the weather in sf"}]},
-        # highlight-next-line
-        stream_mode=["updates", "messages", "custom"]
-    ):
-        print(chunk)
-        print("\n")
-    ```
-
-### Disable streaming
-
-In some applications you might need to disable streaming of individual tokens for a given model. This is useful in [multi-agent](../agents/multi-agent.md) systems to control which agents stream their output.
-
-See the [Models](../agents/models.md#disable-streaming) guide to learn how to disable streaming.
-
-## Stream from a workflow 
-
-### Basic usage example
+## Streaming API
 
 LangGraph graphs expose the [`.stream()`][langgraph.pregel.Pregel.stream] (sync) and [`.astream()`][langgraph.pregel.Pregel.astream] (async) methods to yield streamed outputs as iterators.
 
+Basic usage example:
+
 === "Sync"
 
     ```python
@@ -270,7 +61,18 @@ LangGraph graphs expose the [`.stream()`][langgraph.pregel.Pregel.stream] (sync)
       ```output
       {'refine_topic': {'topic': 'ice cream and cats'}}
       {'generate_joke': {'joke': 'This is a joke about ice cream and cats'}}
-      ```                                                                                                   |
+      ```
+
+
+### Supported stream modes
+
+| Mode                             | Description                                                                                                                                                                         |
+|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| [`values`](#stream-graph-state)  | Streams the full value of the state after each step of the graph.                                                                                                                   |
+| [`updates`](#stream-graph-state) | Streams the updates to the state after each step of the graph. If multiple updates are made in the same step (e.g., multiple nodes are run), those updates are streamed separately. |
+| [`custom`](#stream-custom-data)  | Streams custom data from inside your graph nodes.                                                                                                                                   |
+| [`messages`](#messages)          | Streams 2-tuples (LLM token, metadata) from any graph nodes where an LLM is invoked.                                                                                                        |
+| [`debug`](#debug)                | Streams as much information as possible throughout the execution of the graph.                                                                                                      |
 
 ### Stream multiple modes
 
@@ -292,7 +94,7 @@ The streamed outputs will be tuples of `(mode, chunk)` where `mode` is the name
         print(chunk)
     ```
 
-### Stream graph state
+## Stream graph state
 
 Use the stream modes `updates` and `values` to stream the state of the graph as it executes.
 
@@ -355,7 +157,7 @@ graph = (
     ```
 
 
-### Stream subgraph outputs
+## Subgraphs
 
 To include outputs from [subgraphs](../concepts/subgraphs.md) in the streamed outputs, you can set `subgraphs=True` in the `.stream()` method of the parent graph. This will stream outputs from both the parent graph and any subgraphs.
 
@@ -431,7 +233,7 @@ for chunk in graph.stream(
 
       **Note** that we are receiving not just the node updates, but we also the namespaces which tell us what graph (or subgraph) we are streaming from.
 
-### Debugging {#debug}
+## Debugging {#debug}
 
 Use the `debug` streaming mode to stream as much information as possible throughout the execution of the graph. The streamed outputs include the name of the node as well as the full state.
 
@@ -445,7 +247,7 @@ for chunk in graph.stream(
 ```
 
 
-### LLM tokens {#messages}
+## LLM tokens {#messages}
 
 Use the `messages` streaming mode to stream Large Language Model (LLM) outputs **token by token** from any part of your graph, including nodes, tools, subgraphs, or tasks.
 
@@ -505,7 +307,7 @@ for message_chunk, metadata in graph.stream( # (2)!
 2. The "messages" stream mode returns an iterator of tuples `(message_chunk, metadata)` where `message_chunk` is the token streamed by the LLM and `metadata` is a dictionary with information about the graph node where the LLM was called and other information.
 
 
-#### Filter by LLM invocation
+### Filter by LLM invocation
 
 You can associate `tags` with LLM invocations to filter the streamed tokens by LLM invocation.
 
@@ -589,7 +391,7 @@ async for msg, metadata in graph.astream(  # (3)!
       4. The `stream_mode` is set to "messages" to stream LLM tokens. The `metadata` contains information about the LLM invocation, including the tags.
 
 
-#### Filter by node
+### Filter by node
 
 To stream tokens only from specific nodes, use `stream_mode="messages"` and filter the outputs by the `langgraph_node` field in the streamed metadata:
 
@@ -662,7 +464,7 @@ for msg, metadata in graph.stream( # (1)!
       1. The "messages" stream mode returns a tuple of `(message_chunk, metadata)` where `message_chunk` is the token streamed by the LLM and `metadata` is a dictionary with information about the graph node where the LLM was called and other information.
       2. Filter the streamed tokens by the `langgraph_node` field in the metadata to only include the tokens from the `write_poem` node.
 
-### Stream custom data
+## Stream custom data
 
 To send **custom user-defined data** from inside a LangGraph node or tool, follow these steps:
 
@@ -739,7 +541,7 @@ To send **custom user-defined data** from inside a LangGraph node or tool, follo
       3. Emit another custom key-value pair.
       4. Set `stream_mode="custom"` to receive the custom data in the stream.
 
-### Use with any LLM
+## Use with any LLM
 
 You can use `stream_mode="custom"` to stream data from **any LLM API**  — even if that API does **not** implement the LangChain chat model interface.
 
@@ -899,7 +701,7 @@ for chunk in graph.stream(
       ```
 
 
-### Disable streaming for specific chat models
+## Disable streaming for specific chat models
 
 If your application mixes models that support streaming with those that do not, you may need to explicitly disable streaming for 
 models that do not support it.
@@ -931,7 +733,7 @@ Set `disable_streaming=True` when initializing the model.
       1. Set `disable_streaming=True` to disable streaming for the chat model.
 
 
-### Async with Python < 3.11 { #async }
+## Async with Python < 3.11 { #async }
 
 In Python versions < 3.11, [asyncio tasks](https://docs.python.org/3/library/asyncio-task.html#asyncio.create_task) do not support the `context` parameter.  
 This limits LangGraph ability to automatically propagate context, and affects LangGraph’s streaming mechanisms in two key ways:

docs/docs/how-tos/use-functional-api.md

@@ -1,12 +1,5 @@
 # Use the functional API
 
-The [**Functional API**](../concepts/functional_api.md) allows you to add LangGraph's key features — [persistence](../concepts/persistence.md), [memory](../how-tos/memory/add-memory.md), [human-in-the-loop](../concepts/human_in_the_loop.md), and [streaming](../concepts/streaming.md) — to your applications with minimal changes to your existing code.
-
-!!! tip
-
-    For conceptual information on the functional API, see [Functional API](../concepts/functional_api.md).
-
-
 ## Creating a simple workflow
 
 When defining an `entrypoint`, input is restricted to the first argument of the function. To pass multiple inputs, you can use a dictionary.
@@ -469,284 +462,15 @@ main.invoke(None, config=config)
 
 The functional API supports [human-in-the-loop](../concepts/human_in_the_loop.md) workflows using the `interrupt` function and the `Command` primitive.
 
-### Basic human-in-the-loop workflow
+Please see the following examples for more details:
 
-We will create three [tasks](../concepts/functional_api.md#task):
-
-1. Append `"bar"`.
-2. Pause for human input. When resuming, append human input.
-3. Append `"qux"`.
-
-```python
-from langgraph.func import entrypoint, task
-from langgraph.types import Command, interrupt
-
-
-@task
-def step_1(input_query):
-    """Append bar."""
-    return f"{input_query} bar"
-
-
-@task
-def human_feedback(input_query):
-    """Append user input."""
-    feedback = interrupt(f"Please provide feedback: {input_query}")
-    return f"{input_query} {feedback}"
-
-
-@task
-def step_3(input_query):
-    """Append qux."""
-    return f"{input_query} qux"
-``` 
-
-We can now compose these tasks in an [entrypoint](../concepts/functional_api.md#entrypoint):
-
-```python
-from langgraph.checkpoint.memory import MemorySaver
-
-checkpointer = MemorySaver()
-
-
-@entrypoint(checkpointer=checkpointer)
-def graph(input_query):
-    result_1 = step_1(input_query).result()
-    result_2 = human_feedback(result_1).result()
-    result_3 = step_3(result_2).result()
-
-    return result_3
-```
-
-[interrupt()](../how-tos/human_in_the_loop/add-human-in-the-loop.md#pause-using-interrupt) is called inside a task, enabling a human to review and edit the output of the previous task. The results of prior tasks-- in this case `step_1`-- are persisted, so that they are not run again following the `interrupt`.
-
-Let's send in a query string:
-
-```python
-config = {"configurable": {"thread_id": "1"}}
-
-for event in graph.stream("foo", config):
-    print(event)
-    print("\n")
-```
-
-Note that we've paused with an `interrupt` after `step_1`. The interrupt provides instructions to resume the run. To resume, we issue a [Command](../how-tos/human_in_the_loop/add-human-in-the-loop.md#resume-using-the-command-primitive) containing the data expected by the `human_feedback` task.
-
-```python
-# Continue execution
-for event in graph.stream(Command(resume="baz"), config):
-    print(event)
-    print("\n")
-```
-After resuming, the run proceeds through the remaining step and terminates as expected.
-
-### Review tool calls
-
-To review tool calls before execution, we add a `review_tool_call` function that calls [`interrupt`](../how-tos/human_in_the_loop/add-human-in-the-loop.md#pause-using-interrupt). When this function is called, execution will be paused until we issue a command to resume it.
-
-Given a tool call, our function will `interrupt` for human review. At that point we can either:
-
-- Accept the tool call
-- Revise the tool call and continue
-- Generate a custom tool message (e.g., instructing the model to re-format its tool call)
-
-```python
-from typing import Union
-
-def review_tool_call(tool_call: ToolCall) -> Union[ToolCall, ToolMessage]:
-    """Review a tool call, returning a validated version."""
-    human_review = interrupt(
-        {
-            "question": "Is this correct?",
-            "tool_call": tool_call,
-        }
-    )
-    review_action = human_review["action"]
-    review_data = human_review.get("data")
-    if review_action == "continue":
-        return tool_call
-    elif review_action == "update":
-        updated_tool_call = {**tool_call, **{"args": review_data}}
-        return updated_tool_call
-    elif review_action == "feedback":
-        return ToolMessage(
-            content=review_data, name=tool_call["name"], tool_call_id=tool_call["id"]
-        )
-```
-
-We can now update our [entrypoint](../concepts/functional_api.md#entrypoint) to review the generated tool calls. If a tool call is accepted or revised, we execute in the same way as before. Otherwise, we just append the `ToolMessage` supplied by the human. The results of prior tasks — in this case the initial model call — are persisted, so that they are not run again following the `interrupt`.
-
-```python
-from langgraph.checkpoint.memory import MemorySaver
-from langgraph.graph.message import add_messages
-from langgraph.types import Command, interrupt
-
-
-checkpointer = MemorySaver()
-
-
-@entrypoint(checkpointer=checkpointer)
-def agent(messages, previous):
-    if previous is not None:
-        messages = add_messages(previous, messages)
-
-    llm_response = call_model(messages).result()
-    while True:
-        if not llm_response.tool_calls:
-            break
-
-        # Review tool calls
-        tool_results = []
-        tool_calls = []
-        for i, tool_call in enumerate(llm_response.tool_calls):
-            review = review_tool_call(tool_call)
-            if isinstance(review, ToolMessage):
-                tool_results.append(review)
-            else:  # is a validated tool call
-                tool_calls.append(review)
-                if review != tool_call:
-                    llm_response.tool_calls[i] = review  # update message
-
-        # Execute remaining tool calls
-        tool_result_futures = [call_tool(tool_call) for tool_call in tool_calls]
-        remaining_tool_results = [fut.result() for fut in tool_result_futures]
-
-        # Append to message list
-        messages = add_messages(
-            messages,
-            [llm_response, *tool_results, *remaining_tool_results],
-        )
-
-        # Call model again
-        llm_response = call_model(messages).result()
-
-    # Generate final response
-    messages = add_messages(messages, llm_response)
-    return entrypoint.final(value=llm_response, save=messages)
-```
+* [How to wait for user input (Functional API)](./wait-user-input-functional.ipynb): Shows how to implement a simple human-in-the-loop workflow using the functional API.
+* [How to review tool calls (Functional API)](./review-tool-calls-functional.ipynb): Guide demonstrates how to implement human-in-the-loop workflows in a ReAct agent using the LangGraph Functional API.
 
 ## Short-term memory
 
 Short-term memory allows storing information across different **invocations** of the same **thread id**. See [short-term memory](../concepts/functional_api.md#short-term-memory) for more details.
 
-### Manage checkpoints
-
-You can view and delete the information stored by the checkpointer.
-
-#### View thread state (checkpoint)
-
-```python
-config = {
-    "configurable": {
-        # highlight-next-line
-        "thread_id": "1",
-        # optionally provide an ID for a specific checkpoint,
-        # otherwise the latest checkpoint is shown
-        # highlight-next-line
-        # "checkpoint_id": "1f029ca3-1f5b-6704-8004-820c16b69a5a"
-            
-    }
-}
-# highlight-next-line
-graph.get_state(config)
-```
-
-```
-StateSnapshot(
-    values={'messages': [HumanMessage(content="hi! I'm bob"), AIMessage(content='Hi Bob! How are you doing today?), HumanMessage(content="what's my name?"), AIMessage(content='Your name is Bob.')]}, next=(), 
-    config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1f029ca3-1f5b-6704-8004-820c16b69a5a'}},
-    metadata={
-        'source': 'loop',
-        'writes': {'call_model': {'messages': AIMessage(content='Your name is Bob.')}},
-        'step': 4,
-        'parents': {},
-        'thread_id': '1'
-    },
-    created_at='2025-05-05T16:01:24.680462+00:00',
-    parent_config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1f029ca3-1790-6b0a-8003-baf965b6a38f'}}, 
-    tasks=(),
-    interrupts=()
-)
-```
-
-#### View the history of the thread (checkpoints)
-
-```python
-config = {
-    "configurable": {
-        # highlight-next-line
-        "thread_id": "1"
-    }
-}
-# highlight-next-line
-list(graph.get_state_history(config))
-```
-
-```
-[
-    StateSnapshot(
-        values={'messages': [HumanMessage(content="hi! I'm bob"), AIMessage(content='Hi Bob! How are you doing today? Is there anything I can help you with?'), HumanMessage(content="what's my name?"), AIMessage(content='Your name is Bob.')]}, 
-        next=(), 
-        config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1f029ca3-1f5b-6704-8004-820c16b69a5a'}}, 
-        metadata={'source': 'loop', 'writes': {'call_model': {'messages': AIMessage(content='Your name is Bob.')}}, 'step': 4, 'parents': {}, 'thread_id': '1'},
-        created_at='2025-05-05T16:01:24.680462+00:00',
-        parent_config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1f029ca3-1790-6b0a-8003-baf965b6a38f'}},
-        tasks=(),
-        interrupts=()
-    ),
-    StateSnapshot(
-        values={'messages': [HumanMessage(content="hi! I'm bob"), AIMessage(content='Hi Bob! How are you doing today? Is there anything I can help you with?'), HumanMessage(content="what's my name?")]}, 
-        next=('call_model',), 
-        config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1f029ca3-1790-6b0a-8003-baf965b6a38f'}},
-        metadata={'source': 'loop', 'writes': None, 'step': 3, 'parents': {}, 'thread_id': '1'},
-        created_at='2025-05-05T16:01:23.863421+00:00',
-        parent_config={...}
-        tasks=(PregelTask(id='8ab4155e-6b15-b885-9ce5-bed69a2c305c', name='call_model', path=('__pregel_pull', 'call_model'), error=None, interrupts=(), state=None, result={'messages': AIMessage(content='Your name is Bob.')}),),
-        interrupts=()
-    ),
-    StateSnapshot(
-        values={'messages': [HumanMessage(content="hi! I'm bob"), AIMessage(content='Hi Bob! How are you doing today? Is there anything I can help you with?')]}, 
-        next=('__start__',), 
-        config={...}, 
-        metadata={'source': 'input', 'writes': {'__start__': {'messages': [{'role': 'user', 'content': "what's my name?"}]}}, 'step': 2, 'parents': {}, 'thread_id': '1'},
-        created_at='2025-05-05T16:01:23.863173+00:00',
-        parent_config={...}
-        tasks=(PregelTask(id='24ba39d6-6db1-4c9b-f4c5-682aeaf38dcd', name='__start__', path=('__pregel_pull', '__start__'), error=None, interrupts=(), state=None, result={'messages': [{'role': 'user', 'content': "what's my name?"}]}),),
-        interrupts=()
-    ),
-    StateSnapshot(
-        values={'messages': [HumanMessage(content="hi! I'm bob"), AIMessage(content='Hi Bob! How are you doing today? Is there anything I can help you with?')]}, 
-        next=(), 
-        config={...}, 
-        metadata={'source': 'loop', 'writes': {'call_model': {'messages': AIMessage(content='Hi Bob! How are you doing today? Is there anything I can help you with?')}}, 'step': 1, 'parents': {}, 'thread_id': '1'},
-        created_at='2025-05-05T16:01:23.862295+00:00',
-        parent_config={...}
-        tasks=(),
-        interrupts=()
-    ),
-    StateSnapshot(
-        values={'messages': [HumanMessage(content="hi! I'm bob")]}, 
-        next=('call_model',), 
-        config={...}, 
-        metadata={'source': 'loop', 'writes': None, 'step': 0, 'parents': {}, 'thread_id': '1'}, 
-        created_at='2025-05-05T16:01:22.278960+00:00', 
-        parent_config={...}
-        tasks=(PregelTask(id='8cbd75e0-3720-b056-04f7-71ac805140a0', name='call_model', path=('__pregel_pull', 'call_model'), error=None, interrupts=(), state=None, result={'messages': AIMessage(content='Hi Bob! How are you doing today? Is there anything I can help you with?')}),), 
-        interrupts=()
-    ),
-    StateSnapshot(
-        values={'messages': []}, 
-        next=('__start__',), 
-        config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1f029ca3-0870-6ce2-bfff-1f3f14c3e565'}},
-        metadata={'source': 'input', 'writes': {'__start__': {'messages': [{'role': 'user', 'content': "hi! I'm bob"}]}}, 'step': -1, 'parents': {}, 'thread_id': '1'}, 
-        created_at='2025-05-05T16:01:22.277497+00:00', 
-        parent_config=None,
-        tasks=(PregelTask(id='d458367b-8265-812c-18e2-33001d199ce6', name='__start__', path=('__pregel_pull', '__start__'), error=None, interrupts=(), state=None, result={'messages': [{'role': 'user', 'content': "hi! I'm bob"}]}),), 
-        interrupts=()
-    )
-]       
-```
-
 ### Decouple return value from saved value
 
 Use `entrypoint.final` to decouple what is returned to the caller from what is persisted in the checkpoint. This is useful when:
@@ -839,4 +563,4 @@ for chunk in workflow.stream([input_message], config, stream_mode="values"):
 
 ## Integrate with other libraries
 
-* [Add LangGraph's features to other frameworks using the functional API](./autogen-integration-functional.ipynb): Add LangGraph features like persistence, memory and streaming to other agent frameworks that do not provide them out of the box.
+* [Add LangGraph's features to other frameworks using the functional API](./autogen-integration-functional.ipynb): Add LangGraph features like persistence, memory and streaming to other agent frameworks that do not provide them out of the box.

docs/docs/how-tos/wait-user-input-functional.ipynb

@@ -0,0 +1,561 @@
+{
+ "cells": [
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "# How to wait for user input (Functional API)\n",
+    "\n",
+    "!!! info \"Prerequisites\"\n",
+    "    This guide assumes familiarity with the following:\n",
+    "\n",
+    "    - Implementing [human-in-the-loop](../../concepts/human_in_the_loop) workflows with [interrupt](../../concepts/human_in_the_loop/#interrupt)\n",
+    "    - [How to create a ReAct agent using the Functional API](../../how-tos/react-agent-from-scratch-functional)\n",
+    "\n",
+    "**Human-in-the-loop (HIL)** interactions are crucial for [agentic systems](../../concepts/agentic_concepts/#human-in-the-loop). Waiting for human input is a common HIL interaction pattern, allowing the agent to ask the user clarifying questions and await input before proceeding. \n",
+    "\n",
+    "We can implement this in LangGraph using the [interrupt()][langgraph.types.interrupt] function. `interrupt` allows us to stop graph execution to collect input from a user and continue execution with collected input.\n",
+    "\n",
+    "This guide demonstrates how to implement human-in-the-loop workflows using LangGraph's [Functional API](../../concepts/functional_api). Specifically, we will demonstrate:\n",
+    "\n",
+    "1. [A simple usage example](#simple-usage)\n",
+    "2. [How to use with a ReAct agent](#agent)\n",
+    "\n",
+    "## Setup\n",
+    "\n",
+    "First, let's install the required packages and set our API keys:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 1,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "%%capture --no-stderr\n",
+    "%pip install -U langgraph langchain-openai"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 2,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "import getpass\n",
+    "import os\n",
+    "\n",
+    "\n",
+    "def _set_env(var: str):\n",
+    "    if not os.environ.get(var):\n",
+    "        os.environ[var] = getpass.getpass(f\"{var}: \")\n",
+    "\n",
+    "\n",
+    "_set_env(\"OPENAI_API_KEY\")"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "<div class=\"admonition tip\">\n",
+    "     <p class=\"admonition-title\">Set up <a href=\"https://smith.langchain.com\">LangSmith</a> for better debugging</p>\n",
+    "     <p style=\"padding-top: 5px;\">\n",
+    "         Sign up for LangSmith to quickly spot issues and improve the performance of your LangGraph projects. LangSmith lets you use trace data to debug, test, and monitor your LLM aps built with LangGraph — read more about how to get started in the <a href=\"https://docs.smith.langchain.com\">docs</a>. \n",
+    "     </p>\n",
+    " </div>"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## Simple usage\n",
+    "\n",
+    "Let's demonstrate a simple usage example. We will create three [tasks](../../concepts/functional_api/#task):\n",
+    "\n",
+    "1. Append `\"bar\"`.\n",
+    "2. Pause for human input. When resuming, append human input.\n",
+    "3. Append `\"qux\"`."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 2,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langgraph.func import entrypoint, task\n",
+    "from langgraph.types import Command, interrupt\n",
+    "\n",
+    "\n",
+    "@task\n",
+    "def step_1(input_query):\n",
+    "    \"\"\"Append bar.\"\"\"\n",
+    "    return f\"{input_query} bar\"\n",
+    "\n",
+    "\n",
+    "@task\n",
+    "def human_feedback(input_query):\n",
+    "    \"\"\"Append user input.\"\"\"\n",
+    "    feedback = interrupt(f\"Please provide feedback: {input_query}\")\n",
+    "    return f\"{input_query} {feedback}\"\n",
+    "\n",
+    "\n",
+    "@task\n",
+    "def step_3(input_query):\n",
+    "    \"\"\"Append qux.\"\"\"\n",
+    "    return f\"{input_query} qux\""
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "We can now compose these tasks in a simple [entrypoint](../../concepts/functional_api/#entrypoint):"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 3,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langgraph.checkpoint.memory import MemorySaver\n",
+    "\n",
+    "checkpointer = MemorySaver()\n",
+    "\n",
+    "\n",
+    "@entrypoint(checkpointer=checkpointer)\n",
+    "def graph(input_query):\n",
+    "    result_1 = step_1(input_query).result()\n",
+    "    result_2 = human_feedback(result_1).result()\n",
+    "    result_3 = step_3(result_2).result()\n",
+    "\n",
+    "    return result_3"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "All we have done to enable human-in-the-loop workflows is called [interrupt()](../../concepts/human_in_the_loop/#interrupt) inside a task.\n",
+    "\n",
+    "!!! tip\n",
+    "\n",
+    "    The results of prior tasks-- in this case `step_1`-- are persisted, so that they are not run again following the `interrupt`.\n",
+    "\n",
+    "\n",
+    "Let's send in a query string:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 4,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "config = {\"configurable\": {\"thread_id\": \"1\"}}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 5,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "{'step_1': 'foo bar'}\n",
+      "\n",
+      "\n",
+      "{'__interrupt__': (Interrupt(value='Please provide feedback: foo bar', resumable=True, ns=['graph:d66b2e35-0ee3-d8d6-1a22-aec9d58f13b9', 'human_feedback:e0cd4ee2-b874-e1d2-8bc4-3f7ddc06bcc2'], when='during'),)}\n",
+      "\n",
+      "\n"
+     ]
+    }
+   ],
+   "source": [
+    "for event in graph.stream(\"foo\", config):\n",
+    "    print(event)\n",
+    "    print(\"\\n\")"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "Note that we've paused with an `interrupt` after `step_1`. The interrupt provides instructions to resume the run. To resume, we issue a [Command](../../concepts/human_in_the_loop/#the-command-primitive) containing the data expected by the `human_feedback` task."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 6,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "{'human_feedback': 'foo bar baz'}\n",
+      "\n",
+      "\n",
+      "{'step_3': 'foo bar baz qux'}\n",
+      "\n",
+      "\n",
+      "{'graph': 'foo bar baz qux'}\n",
+      "\n",
+      "\n"
+     ]
+    }
+   ],
+   "source": [
+    "# Continue execution\n",
+    "for event in graph.stream(Command(resume=\"baz\"), config):\n",
+    "    print(event)\n",
+    "    print(\"\\n\")"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "After resuming, the run proceeds through the remaining step and terminates as expected."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## Agent\n",
+    "\n",
+    "We will build off of the agent created in the [How to create a ReAct agent using the Functional API](../../how-tos/react-agent-from-scratch-functional) guide.\n",
+    "\n",
+    "Here we will extend the agent by allowing it to reach out to a human for assistance when needed.\n",
+    "\n",
+    "### Define model and tools\n",
+    "\n",
+    "Let's first define the tools and model we will use for our example. As in the [ReAct agent guide](../../how-tos/react-agent-from-scratch-functional), we will use a single place-holder tool that gets a description of the weather for a location.\n",
+    "\n",
+    "We will use an [OpenAI](https://python.langchain.com/docs/integrations/providers/openai/) chat model for this example, but any model [supporting tool-calling](https://python.langchain.com/docs/integrations/chat/) will suffice."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 7,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langchain_openai import ChatOpenAI\n",
+    "from langchain_core.tools import tool\n",
+    "\n",
+    "model = ChatOpenAI(model=\"gpt-4o-mini\")\n",
+    "\n",
+    "\n",
+    "@tool\n",
+    "def get_weather(location: str):\n",
+    "    \"\"\"Call to get the weather from a specific location.\"\"\"\n",
+    "    # This is a placeholder for the actual implementation\n",
+    "    if any([city in location.lower() for city in [\"sf\", \"san francisco\"]]):\n",
+    "        return \"It's sunny!\"\n",
+    "    elif \"boston\" in location.lower():\n",
+    "        return \"It's rainy!\"\n",
+    "    else:\n",
+    "        return f\"I am not sure what the weather is in {location}\""
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "To reach out to a human for assistance, we can simply add a tool that calls [interrupt](../../concepts/human_in_the_loop/#interrupt):"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 8,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langgraph.types import Command, interrupt\n",
+    "\n",
+    "\n",
+    "@tool\n",
+    "def human_assistance(query: str) -> str:\n",
+    "    \"\"\"Request assistance from a human.\"\"\"\n",
+    "    human_response = interrupt({\"query\": query})\n",
+    "    return human_response[\"data\"]\n",
+    "\n",
+    "\n",
+    "tools = [get_weather, human_assistance]"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### Define tasks\n",
+    "\n",
+    "Our tasks are otherwise unchanged from the [ReAct agent guide](../../how-tos/react-agent-from-scratch-functional):\n",
+    "\n",
+    "1. **Call model**: We want to query our chat model with a list of messages.\n",
+    "2. **Call tool**: If our model generates tool calls, we want to execute them.\n",
+    "\n",
+    "We just have one more tool accessible to the model."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 9,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langchain_core.messages import ToolMessage\n",
+    "from langgraph.func import entrypoint, task\n",
+    "\n",
+    "tools_by_name = {tool.name: tool for tool in tools}\n",
+    "\n",
+    "\n",
+    "@task\n",
+    "def call_model(messages):\n",
+    "    \"\"\"Call model with a sequence of messages.\"\"\"\n",
+    "    response = model.bind_tools(tools).invoke(messages)\n",
+    "    return response\n",
+    "\n",
+    "\n",
+    "@task\n",
+    "def call_tool(tool_call):\n",
+    "    tool = tools_by_name[tool_call[\"name\"]]\n",
+    "    observation = tool.invoke(tool_call)\n",
+    "    return ToolMessage(content=observation, tool_call_id=tool_call[\"id\"])"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### Define entrypoint\n",
+    "\n",
+    "Our [entrypoint](../../concepts/functional_api/#entrypoint) is also unchanged from the [ReAct agent guide](../../how-tos/react-agent-from-scratch-functional):"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 10,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from langgraph.checkpoint.memory import MemorySaver\n",
+    "from langgraph.graph.message import add_messages\n",
+    "\n",
+    "checkpointer = MemorySaver()\n",
+    "\n",
+    "\n",
+    "@entrypoint(checkpointer=checkpointer)\n",
+    "def agent(messages, previous):\n",
+    "    if previous is not None:\n",
+    "        messages = add_messages(previous, messages)\n",
+    "\n",
+    "    llm_response = call_model(messages).result()\n",
+    "    while True:\n",
+    "        if not llm_response.tool_calls:\n",
+    "            break\n",
+    "\n",
+    "        # Execute tools\n",
+    "        tool_result_futures = [\n",
+    "            call_tool(tool_call) for tool_call in llm_response.tool_calls\n",
+    "        ]\n",
+    "        tool_results = [fut.result() for fut in tool_result_futures]\n",
+    "\n",
+    "        # Append to message list\n",
+    "        messages = add_messages(messages, [llm_response, *tool_results])\n",
+    "\n",
+    "        # Call model again\n",
+    "        llm_response = call_model(messages).result()\n",
+    "\n",
+    "    # Generate final response\n",
+    "    messages = add_messages(messages, llm_response)\n",
+    "    return entrypoint.final(value=llm_response, save=messages)"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### Usage\n",
+    "\n",
+    "Let's invoke our model with a question that requires human assistance. Our question will also require an invocation of the `get_weather` tool:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 11,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "def _print_step(step: dict) -> None:\n",
+    "    for task_name, result in step.items():\n",
+    "        if task_name == \"agent\":\n",
+    "            continue  # just stream from tasks\n",
+    "        print(f\"\\n{task_name}:\")\n",
+    "        if task_name == \"__interrupt__\":\n",
+    "            print(result)\n",
+    "        else:\n",
+    "            result.pretty_print()"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 12,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "config = {\"configurable\": {\"thread_id\": \"1\"}}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 13,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "{'role': 'user', 'content': 'Can you reach out for human assistance: what should I feed my cat? Separately, can you check the weather in San Francisco?'}\n",
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "Tool Calls:\n",
+      "  human_assistance (call_joAEBVX7Abfm7TsZ0k95ZkVx)\n",
+      " Call ID: call_joAEBVX7Abfm7TsZ0k95ZkVx\n",
+      "  Args:\n",
+      "    query: What should I feed my cat?\n",
+      "  get_weather (call_ut7zfHFCcms63BOZLrRHszGH)\n",
+      " Call ID: call_ut7zfHFCcms63BOZLrRHszGH\n",
+      "  Args:\n",
+      "    location: San Francisco\n",
+      "\n",
+      "call_tool:\n",
+      "=================================\u001b[1m Tool Message \u001b[0m=================================\n",
+      "\n",
+      "content=\"It's sunny!\" name='get_weather' tool_call_id='call_ut7zfHFCcms63BOZLrRHszGH'\n",
+      "\n",
+      "__interrupt__:\n",
+      "(Interrupt(value={'query': 'What should I feed my cat?'}, resumable=True, ns=['agent:aa676ccc-b038-25e3-9c8a-18e81d4e1372', 'call_tool:059d53d2-3344-13bc-e170-48b632c2dd97'], when='during'),)\n"
+     ]
+    }
+   ],
+   "source": [
+    "user_message = {\n",
+    "    \"role\": \"user\",\n",
+    "    \"content\": (\n",
+    "        \"Can you reach out for human assistance: what should I feed my cat? \"\n",
+    "        \"Separately, can you check the weather in San Francisco?\"\n",
+    "    ),\n",
+    "}\n",
+    "print(user_message)\n",
+    "\n",
+    "for step in agent.stream([user_message], config):\n",
+    "    _print_step(step)"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "Note that we generate two tool calls, and although our run is interrupted, we did not block the execution of the `get_weather` tool.\n",
+    "\n",
+    "Let's inspect where we're interrupted:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 14,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "{'__interrupt__': (Interrupt(value={'query': 'What should I feed my cat?'}, resumable=True, ns=['agent:aa676ccc-b038-25e3-9c8a-18e81d4e1372', 'call_tool:059d53d2-3344-13bc-e170-48b632c2dd97'], when='during'),)}\n"
+     ]
+    }
+   ],
+   "source": [
+    "print(step)"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "We can resume execution by issuing a [Command](../../concepts/human_in_the_loop/#the-command-primitive). Note that the data we supply in the `Command` can be customized to your needs based on the implementation of `human_assistance`."
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 15,
+   "metadata": {},
+   "outputs": [
+    {
+     "name": "stdout",
+     "output_type": "stream",
+     "text": [
+      "\n",
+      "call_tool:\n",
+      "=================================\u001b[1m Tool Message \u001b[0m=================================\n",
+      "\n",
+      "content='You should feed your cat a fish.' name='human_assistance' tool_call_id='call_joAEBVX7Abfm7TsZ0k95ZkVx'\n",
+      "\n",
+      "call_model:\n",
+      "==================================\u001b[1m Ai Message \u001b[0m==================================\n",
+      "\n",
+      "For human assistance, you should feed your cat fish. \n",
+      "\n",
+      "Regarding the weather in San Francisco, it's sunny!\n"
+     ]
+    }
+   ],
+   "source": [
+    "human_response = \"You should feed your cat a fish.\"\n",
+    "human_command = Command(resume={\"data\": human_response})\n",
+    "\n",
+    "for step in agent.stream(human_command, config):\n",
+    "    _print_step(step)"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "Above, when we resume we provide the final tool message, allowing the model to generate its response. Check out the LangSmith traces to see a full breakdown of the runs:\n",
+    "\n",
+    "1. [Trace from initial query](https://smith.langchain.com/public/c3d8879d-4d01-41be-807e-6d9eed15df99/r)\n",
+    "2. [Trace after resuming](https://smith.langchain.com/public/97c05ef9-8b4c-428e-8826-3fd417c8c75f/r)"
+   ]
+  }
+ ],
+ "metadata": {
+  "kernelspec": {
+   "display_name": "Python 3 (ipykernel)",
+   "language": "python",
+   "name": "python3"
+  },
+  "language_info": {
+   "codemirror_mode": {
+    "name": "ipython",
+    "version": 3
+   },
+   "file_extension": ".py",
+   "mimetype": "text/x-python",
+   "name": "python",
+   "nbconvert_exporter": "python",
+   "pygments_lexer": "ipython3",
+   "version": "3.12.3"
+  }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}

docs/docs/tutorials/deployment.md

@@ -0,0 +1,22 @@
+---
+search:
+  boost: 2
+---
+
+# Deployment 🚀
+
+There are two free options for deploying LangGraph applications via the LangGraph Server:
+
+- [Local](./langgraph-platform/local-server.md): Deploy for local testing and development. 
+- [Standalone Container (Lite)](../concepts/langgraph_standalone_container.md): A limited version of Standalone Container for deployments unlikely to see more that 1 million node executions per year and that do not need crons and other enterprise features. Standalone Container (Lite) deployment option is free with a LangSmith API key.
+
+## Other deployment options
+
+Additionally, you can deploy to production with [LangGraph Platform](../concepts/langgraph_platform.md):
+
+- [Cloud SaaS](../concepts/langgraph_cloud.md): Connect your GitHub repositories and deploy LangGraph Servers within LangChain's cloud. *We manage everything.*
+- [Self-Hosted Data Plane<sup>(Beta)</sup>](../concepts/langgraph_self_hosted_data_plane.md): Create deployments from the [Control Plane UI](../concepts/langgraph_control_plane.md#control-plane-ui) and deploy LangGraph Servers to **your** cloud. *We manage the [control plane](../concepts/langgraph_control_plane.md). You manage the deployments.*
+- [Self-Hosted Control Plane<sup>(Beta)</sup>](../concepts/langgraph_self_hosted_control_plane.md): Create deployments from a self-hosted [Control Plane UI](../concepts/langgraph_control_plane.md#control-plane-ui) and deploy LangGraph Servers to **your** cloud. *You manage everything.*
+- [Standalone Container](../concepts/langgraph_standalone_container.md): Deploy LangGraph Server Docker images however you like.
+
+For more information, see [Deployment options](../concepts/deployment_options.md).

docs/docs/tutorials/extraction/retries.ipynb

@@ -89,7 +89,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 2,
+   "execution_count": null,
    "id": "baf669a0-04ee-492d-80d8-8fcb658ed128",
    "metadata": {},
    "outputs": [],
@@ -313,8 +313,8 @@
     "\n",
     "    builder.add_edge(\"finalizer\", END)\n",
     "\n",
-    "    # These functions let the step be used in a MessageGraph\n",
-    "    # or a StateGraph with 'messages' as the key.\n",
+    "    # These functions let the step be used in a\n",
+    "    # StateGraph with 'messages' as the key.\n",
     "    def encode(x: Union[Sequence[AnyMessage], PromptValue]) -> dict:\n",
     "        \"\"\"Ensure the input is the correct format.\"\"\"\n",
     "        if isinstance(x, PromptValue):\n",

docs/docs/tutorials/get-started/1-build-basic-chatbot.md

@@ -1,6 +1,6 @@
 # Build a basic chatbot
 
-In this tutorial, you will build a basic chatbot. This chatbot is the basis for the following series of tutorials where you will progressively add more sophisticated capabilities, and be introduced to key LangGraph concepts along the way. Let’s dive in! 🌟
+In this tutorial, you will build a basic chatbot. This chatbot is the basis for the following series of tutorials where you will progressively add more sophisticated capabilities, and be introduced to key LangGraph concepts along the way. Let's dive in! 🌟
 
 ## Prerequisites
 
@@ -13,9 +13,17 @@ tool-calling features, such as [OpenAI](https://platform.openai.com/api-keys),
 
 Install the required packages:
 
+:::python
 ```bash
 pip install -U langgraph langsmith
 ```
+:::
+
+:::js
+```bash
+npm install @langchain/langgraph @langchain/core langsmith
+```
+:::
 
 !!! tip
 
@@ -27,6 +35,7 @@ Now you can create a basic chatbot using LangGraph. This chatbot will respond di
 
 Start by creating a `StateGraph`. A `StateGraph` object defines the structure of our chatbot as a "state machine". We'll add `nodes` to represent the llm and functions our chatbot can call and `edges` to specify how the bot should transition between these functions.
 
+:::python
 ```python
 from typing import Annotated
 
@@ -45,24 +54,53 @@ class State(TypedDict):
 
 graph_builder = StateGraph(State)
 ```
+:::
+
+:::js
+```typescript
+import { Annotation } from "@langchain/langgraph";
+import { BaseMessage } from "@langchain/core/messages";
+import { StateGraph, START, END } from "@langchain/langgraph";
+
+const StateAnnotation = Annotation.Root({
+  // Messages have the type "BaseMessage[]". The messagesStateReducer function
+  // defines how this state key should be updated
+  // (in this case, it appends messages to the list, rather than overwriting them)
+  messages: Annotation<BaseMessage[]>({
+    reducer: (x, y) => x.concat(y),
+  }),
+});
+
+const graphBuilder = new StateGraph(StateAnnotation);
+```
+:::
 
 Our graph can now handle two key tasks:
 
 1. Each `node` can receive the current `State` as input and output an update to the state.
-2. Updates to `messages` will be appended to the existing list rather than overwriting it, thanks to the prebuilt [`add_messages`](https://langchain-ai.github.io/langgraph/reference/graphs/?h=add+messages#add_messages) function used with the `Annotated` syntax.
+2. Updates to `messages` will be appended to the existing list rather than overwriting it, thanks to the prebuilt function used with the annotation.
 
 ------
 
 !!! tip "Concept"
 
-    When defining a graph, the first step is to define its `State`. The `State` includes the graph's schema and [reducer functions](https://langchain-ai.github.io/langgraph/concepts/low_level/#reducers) that handle state updates. In our example, `State` is a `TypedDict` with one key: `messages`. The [`add_messages`](https://langchain-ai.github.io/langgraph/reference/graphs/#langgraph.graph.message.add_messages) reducer function is used to append new messages to the list instead of overwriting it. Keys without a reducer annotation will overwrite previous values. To learn more about state, reducers, and related concepts, see [LangGraph reference docs](https://langchain-ai.github.io/langgraph/reference/graphs/#langgraph.graph.message.add_messages).
+    When defining a graph, the first step is to define its `State`. The `State` includes the graph's schema and [reducer functions](https://langchain-ai.github.io/langgraph/concepts/low_level/#reducers) that handle state updates. Keys without a reducer annotation will overwrite previous values. To learn more about state, reducers, and related concepts, see [LangGraph reference docs](https://langchain-ai.github.io/langgraph/reference/graphs/#langgraph.graph.message.add_messages).
+
+    :::python
+    In our example, `State` is a `TypedDict` with one key: `messages`. The [`add_messages`](https://langchain-ai.github.io/langgraph/reference/graphs/#langgraph.graph.message.add_messages) reducer function is used to append new messages to the list instead of overwriting it.
+    :::
+
+    :::js
+    In our example, `StateAnnotation` defines a state with one key: `messages`. The reducer function is used to append new messages to the list instead of overwriting it.
+    :::
 
 ## 3. Add a node
 
-Next, add a "`chatbot`" node. **Nodes** represent units of work and are typically regular Python functions.
+Next, add a "`chatbot`" node. **Nodes** represent units of work and are typically regular functions.
 
 Let's first select a chat model:
 
+:::python
 {!snippets/chat_model_tabs.md!}
 
 <!---
@@ -72,10 +110,21 @@ from langchain.chat_models import init_chat_model
 llm = init_chat_model("anthropic:claude-3-5-sonnet-latest")
 ```
 -->
+:::
 
+:::js
+```typescript
+import { ChatAnthropic } from "@langchain/anthropic";
+
+const llm = new ChatAnthropic({
+  model: "claude-3-5-sonnet-latest",
+});
+```
+:::
 
 We can now incorporate the chat model into a simple node:
 
+:::python
 ```python
 
 def chatbot(state: State):
@@ -87,26 +136,63 @@ def chatbot(state: State):
 # the node is used.
 graph_builder.add_node("chatbot", chatbot)
 ```
+:::
+
+:::js
+```typescript
+const chatbot = async (state: typeof StateAnnotation.State) => {
+  return { messages: [await llm.invoke(state.messages)] };
+};
+
+// The first argument is the unique node name
+// The second argument is the function or object that will be called whenever
+// the node is used.
+graphBuilder.addNode("chatbot", chatbot);
+```
+:::
 
 **Notice** how the `chatbot` node function takes the current `State` as input and returns a dictionary containing an updated `messages` list under the key "messages". This is the basic pattern for all LangGraph node functions.
 
+:::python
 The `add_messages` function in our `State` will append the LLM's response messages to whatever messages are already in the state.
+:::
+
+:::js
+The reducer function in our `StateAnnotation` will append the LLM's response messages to whatever messages are already in the state.
+:::
 
 ## 4. Add an `entry` point
 
 Add an `entry` point to tell the graph **where to start its work** each time it is run:
 
+:::python
 ```python
 graph_builder.add_edge(START, "chatbot")
 ```
+:::
+
+:::js
+```typescript
+graphBuilder.addEdge(START, "chatbot");
+```
+:::
 
 ## 5. Add an `exit` point
 
 Add an `exit` point to indicate **where the graph should finish execution**. This is helpful for more complex flows, but even in a simple graph like this, adding an end node improves clarity.
 
+:::python
 ```python
 graph_builder.add_edge("chatbot", END)
 ```
+:::
+
+:::js
+```typescript
+graphBuilder.addEdge("chatbot", END);
+```
+:::
+
 This tells the graph to terminate after running the chatbot node.
 
 ## 6. Compile the graph
@@ -114,14 +200,23 @@ This tells the graph to terminate after running the chatbot node.
 Before running the graph, we'll need to compile it. We can do so by calling `compile()`
 on the graph builder. This creates a `CompiledGraph` we can invoke on our state.
 
+:::python
 ```python
 graph = graph_builder.compile()
 ```
+:::
+
+:::js
+```typescript
+const graph = graphBuilder.compile();
+```
+:::
 
 ## 7. Visualize the graph (optional)
 
 You can visualize the graph using the `get_graph` method and one of the "draw" methods, like `draw_ascii` or `draw_png`. The `draw` methods each require additional dependencies.
 
+:::python
 ```python
 from IPython.display import Image, display
 
@@ -131,14 +226,31 @@ except Exception:
     # This requires some extra dependencies and is optional
     pass
 ```
+:::
+
+:::js
+```typescript
+import * as tslab from "tslab";
+
+try {
+  const drawableGraph = graph.getGraph();
+  const image = await drawableGraph.drawMermaidPng();
+  const arrayBuffer = await image.arrayBuffer();
+  await tslab.display.png(new Uint8Array(arrayBuffer));
+} catch (error) {
+  // This requires some extra dependencies and is optional
+  console.log("Graph visualization not available");
+}
+```
+:::
 
 ![basic chatbot diagram](basic-chatbot.png)
 
-
 ## 8. Run the chatbot
 
 Now run the chatbot! 
 
+:::python
 !!! tip
 
     You can exit the chat loop at any time by typing `quit`, `exit`, or `q`.
@@ -169,11 +281,41 @@ while True:
 Assistant: LangGraph is a library designed to help build stateful multi-agent applications using language models. It provides tools for creating workflows and state machines to coordinate multiple AI agents or language model interactions. LangGraph is built on top of LangChain, leveraging its components while adding graph-based coordination capabilities. It's particularly useful for developing more complex, stateful AI applications that go beyond simple query-response interactions.
 Goodbye!
 ```
+:::
+
+:::js
+```typescript
+import { HumanMessage } from "@langchain/core/messages";
+
+async function streamGraphUpdates(userInput: string) {
+  const stream = await graph.stream({
+    messages: [new HumanMessage(userInput)]
+  });
+  
+  for await (const event of stream) {
+    for (const value of Object.values(event)) {
+      console.log("Assistant:", value.messages[value.messages.length - 1].content);
+    }
+  }
+}
+
+// Example usage
+const userInput = "What do you know about LangGraph?";
+console.log("User:", userInput);
+await streamGraphUpdates(userInput);
+```
+
+```
+User: What do you know about LangGraph?
+Assistant: LangGraph is a library designed to help build stateful multi-agent applications using language models. It provides tools for creating workflows and state machines to coordinate multiple AI agents or language model interactions. LangGraph is built on top of LangChain, leveraging its components while adding graph-based coordination capabilities. It's particularly useful for developing more complex, stateful AI applications that go beyond simple query-response interactions.
+```
+:::
 
 **Congratulations!** You've built your first chatbot using LangGraph. This bot can engage in basic conversation by taking user input and generating responses using an LLM. You can inspect a [LangSmith Trace](https://smith.langchain.com/public/7527e308-9502-4894-b347-f34385740d5a/r) for the call above.
 
 Below is the full code for this tutorial:
 
+:::python
 ```python
 from typing import Annotated
 
@@ -206,9 +348,41 @@ graph_builder.add_edge(START, "chatbot")
 graph_builder.add_edge("chatbot", END)
 graph = graph_builder.compile()
 ```
+:::
+
+:::js
+```typescript
+import { Annotation } from "@langchain/langgraph";
+import { BaseMessage, HumanMessage } from "@langchain/core/messages";
+import { StateGraph, START, END } from "@langchain/langgraph";
+import { ChatAnthropic } from "@langchain/anthropic";
+
+const StateAnnotation = Annotation.Root({
+  messages: Annotation<BaseMessage[]>({
+    reducer: (x, y) => x.concat(y),
+  }),
+});
+
+const graphBuilder = new StateGraph(StateAnnotation);
+
+const llm = new ChatAnthropic({
+  model: "claude-3-5-sonnet-latest",
+});
+
+const chatbot = async (state: typeof StateAnnotation.State) => {
+  return { messages: [await llm.invoke(state.messages)] };
+};
+
+// The first argument is the unique node name
+// The second argument is the function or object that will be called whenever
+// the node is used.
+graphBuilder.addNode("chatbot", chatbot);
+graphBuilder.addEdge(START, "chatbot");
+graphBuilder.addEdge("chatbot", END);
+const graph = graphBuilder.compile();
+```
+:::
 
 ## Next steps
 
-You may have noticed that the bot's knowledge is limited to what's in its training data. In the next part, we'll [add a web search tool](./2-add-tools.md) to expand the bot's knowledge and make it more capable.
-
-
+You may have noticed that the bot's knowledge is limited to what's in its training data. In the next part, we'll [add a web search tool](./2-add-tools.md) to expand the bot's knowledge and make it more capable.

docs/docs/tutorials/get-started/2-add-tools.md

@@ -8,19 +8,39 @@ To handle queries that your chatbot can't answer "from memory", integrate a web
 
 ## Prerequisites
 
+:::python
 Before you start this tutorial, ensure you have the following:
 
 - An API key for the [Tavily Search Engine](https://python.langchain.com/docs/integrations/tools/tavily_search/).
+:::
+
+:::js
+Before you start this tutorial, ensure you have the following:
+
+- An API key for the [Tavily Search Engine](https://js.langchain.com/docs/integrations/tools/tavily_search/).
+:::
 
 ## 1. Install the search engine
 
+:::python
 Install the requirements to use the [Tavily Search Engine](https://python.langchain.com/docs/integrations/tools/tavily_search/):
 
 ```bash
 pip install -U langchain-tavily
 ```
+:::
+
+:::js
+Install the requirements to use the [Tavily Search Engine](https://js.langchain.com/docs/integrations/tools/tavily_search/):
+
+```bash
+npm install @langchain/community
+```
+:::
+
 ## 2. Configure your environment
 
+:::python
 Configure your environment with your search engine API key:
 
 ```bash
@@ -30,11 +50,21 @@ _set_env("TAVILY_API_KEY")
 ```
 TAVILY_API_KEY:  ········
 ```
+:::
+
+:::js
+Configure your environment with your search engine API key:
+
+```typescript
+process.env.TAVILY_API_KEY = "tvly-...";
+```
+:::
 
 ## 3. Define the tool
 
 Define the web search tool:
 
+:::python
 ```python
 from langchain_tavily import TavilySearch
 
@@ -42,9 +72,21 @@ tool = TavilySearch(max_results=2)
 tools = [tool]
 tool.invoke("What's a 'node' in LangGraph?")
 ```
+:::
+
+:::js
+```typescript
+import { TavilySearchResults } from "@langchain/community/tools/tavily_search";
+
+const tool = new TavilySearchResults({ maxResults: 2 });
+const tools = [tool];
+await tool.invoke("What's a 'node' in LangGraph?");
+```
+:::
 
 The results are page summaries our chat bot can use to answer questions:
 
+:::python
 ```
 {'query': "What's a 'node' in LangGraph?",
 'follow_up_questions': None,
@@ -62,9 +104,17 @@ The results are page summaries our chat bot can use to answer questions:
 'raw_content': None}],
 'response_time': 1.38}
 ```
+:::
+
+:::js
+```
+'[{"title":"Introduction to LangGraph: A Beginner\'s Guide - Medium","url":"https://medium.com/@cplog/introduction-to-langgraph-a-beginners-guide-14f9be027141","content":"Stateful Graph: LangGraph revolves around the concept of a stateful graph, where each node in the graph represents a step in your computation, and the graph maintains a state that is passed around and updated as the computation progresses. LangGraph supports conditional edges, allowing you to dynamically determine the next node to execute based on the current state of the graph. We define nodes for classifying the input, handling greetings, and handling search queries. def classify_input_node(state): LangGraph is a versatile tool for building complex, stateful applications with LLMs. By understanding its core concepts and working through simple examples, beginners can start to leverage its power for their projects. Remember to pay attention to state management, conditional edges, and ensuring there are no dead-end nodes in your graph.","score":0.7065353,"raw_content":null},{"title":"LangGraph Tutorial: What Is LangGraph and How to Use It?","url":"https://www.datacamp.com/tutorial/langgraph-tutorial","content":"LangGraph is a library within the LangChain ecosystem that provides a framework for defining, coordinating, and executing multiple LLM agents (or chains) in a structured and efficient manner. By managing the flow of data and the sequence of operations, LangGraph allows developers to focus on the high-level logic of their applications rather than the intricacies of agent coordination. Whether you need a chatbot that can handle various types of user requests or a multi-agent system that performs complex tasks, LangGraph provides the tools to build exactly what you need. LangGraph significantly simplifies the development of complex LLM applications by providing a structured framework for managing state and coordinating agent interactions.","score":0.5008063,"raw_content":null}]'
+```
+:::
 
 ## 4. Define the graph
 
+:::python
 For the `StateGraph` you created in the [first tutorial](./1-build-basic-chatbot.md), add `bind_tools` on the LLM. This lets the LLM know the correct JSON format to use if it wants to use the search engine.
 
 Let's first select our LLM:
@@ -103,9 +153,52 @@ def chatbot(state: State):
 
 graph_builder.add_node("chatbot", chatbot)
 ```
+:::
+
+:::js
+For the `StateGraph` you created in the [first tutorial](./1-build-basic-chatbot.md), add `bindTools` on the LLM. This lets the LLM know the correct JSON format to use if it wants to use the search engine.
+
+Let's first select our LLM:
+
+```typescript
+import { ChatOpenAI } from "@langchain/openai";
+
+const llm = new ChatOpenAI({
+  model: "gpt-4o",
+  temperature: 0,
+});
+```
+
+We can now incorporate it into a `StateGraph`:
+
+```typescript hl_lines="15"
+import { Annotation } from "@langchain/langgraph";
+import { BaseMessage } from "@langchain/core/messages";
+
+const StateAnnotation = Annotation.Root({
+  messages: Annotation<BaseMessage[]>({
+    reducer: (x, y) => x.concat(y),
+  }),
+});
+
+import { StateGraph, START, END } from "@langchain/langgraph";
+
+const graphBuilder = new StateGraph(StateAnnotation);
+
+// Modification: tell the LLM which tools it can call
+const llmWithTools = llm.bindTools(tools);
+
+const chatbot = async (state: typeof StateAnnotation.State) => {
+  return { messages: [await llmWithTools.invoke(state.messages)] };
+};
+
+graphBuilder.addNode("chatbot", chatbot);
+```
+:::
 
 ## 5. Create a function to run the tools
 
+:::python
 Now, create a function to run the tools if they are called. Do this by adding the tools to a new node called`BasicToolNode` that checks the most recent message in the state and calls tools if the message contains `tool_calls`. It relies on the LLM's `tool_calling` support, which is available in Anthropic, OpenAI, Google Gemini, and a number of other LLM providers.
 
 ```python
@@ -143,6 +236,50 @@ class BasicToolNode:
 tool_node = BasicToolNode(tools=[tool])
 graph_builder.add_node("tools", tool_node)
 ```
+:::
+
+:::js
+Now, create a function to run the tools if they are called. Do this by adding the tools to a new node called `BasicToolNode` that checks the most recent message in the state and calls tools if the message contains `tool_calls`. It relies on the LLM's `tool_calling` support, which is available in Anthropic, OpenAI, Google Gemini, and a number of other LLM providers.
+
+```typescript
+import { ToolMessage } from "@langchain/core/messages";
+
+class BasicToolNode {
+  private toolsByName: Record<string, any>;
+
+  constructor(tools: any[]) {
+    this.toolsByName = {};
+    for (const tool of tools) {
+      this.toolsByName[tool.name] = tool;
+    }
+  }
+
+  async __call__(inputs: Record<string, any>): Promise<{ messages: ToolMessage[] }> {
+    const messages = inputs.messages || [];
+    if (messages.length === 0) {
+      throw new Error("No message found in input");
+    }
+    const message = messages[messages.length - 1];
+    const outputs: ToolMessage[] = [];
+    
+    for (const toolCall of message.tool_calls || []) {
+      const toolResult = await this.toolsByName[toolCall.name].invoke(toolCall.args);
+      outputs.push(
+        new ToolMessage({
+          content: JSON.stringify(toolResult),
+          name: toolCall.name,
+          tool_call_id: toolCall.id,
+        })
+      );
+    }
+    return { messages: outputs };
+  }
+}
+
+const toolNode = new BasicToolNode([tool]);
+graphBuilder.addNode("tools", async (state) => toolNode.__call__(state));
+```
+:::
 
 !!! note
 
@@ -154,6 +291,7 @@ With the tool node added, now you can define the `conditional_edges`.
 
 **Edges** route the control flow from one node to the next. **Conditional edges** start from a single node and usually contain "if" statements to route to different nodes depending on the current graph state. These functions receive the current graph `state` and return a string or list of strings indicating which node(s) to call next.
 
+:::python
 Next, define a router function called `route_tools` that checks for `tool_calls` in the chatbot's output. Provide this function to the graph by calling `add_conditional_edges`, which tells the graph that whenever the `chatbot` node completes to check this function to see where to go next. 
 
 The condition will route to `tools` if tool calls are present and `END` if not. Because the condition can return `END`, you do not need to explicitly set a `finish_point` this time.
@@ -194,6 +332,51 @@ graph_builder.add_edge("tools", "chatbot")
 graph_builder.add_edge(START, "chatbot")
 graph = graph_builder.compile()
 ```
+:::
+
+:::js
+Next, define a router function called `routeTools` that checks for `tool_calls` in the chatbot's output. Provide this function to the graph by calling `addConditionalEdges`, which tells the graph that whenever the `chatbot` node completes to check this function to see where to go next.
+
+The condition will route to `tools` if tool calls are present and `END` if not. Because the condition can return `END`, you do not need to explicitly set a `finish_point` this time.
+
+```typescript
+import { AIMessage } from "@langchain/core/messages";
+
+const routeTools = (state: typeof StateAnnotation.State) => {
+  /**
+   * Use in the conditional_edge to route to the ToolNode if the last message
+   * has tool calls. Otherwise, route to the end.
+   */
+  const messages = state.messages;
+  const lastMessage = messages[messages.length - 1] as AIMessage;
+  
+  if (lastMessage.tool_calls && lastMessage.tool_calls.length > 0) {
+    return "tools";
+  }
+  return END;
+};
+
+// The `routeTools` function returns "tools" if the chatbot asks to use a tool, and "END" if
+// it is fine directly responding. This conditional routing defines the main agent loop.
+graphBuilder.addConditionalEdges(
+  "chatbot",
+  routeTools,
+  // The following dictionary lets you tell the graph to interpret the condition's outputs as a specific node
+  // It defaults to the identity function, but if you
+  // want to use a node named something else apart from "tools",
+  // You can update the value of the dictionary to something else
+  // e.g., "tools": "my_tools"
+  {
+    tools: "tools",
+    [END]: END,
+  }
+);
+// Any time a tool is called, we return to the chatbot to decide the next step
+graphBuilder.addEdge("tools", "chatbot");
+graphBuilder.addEdge(START, "chatbot");
+const graph = graphBuilder.compile();
+```
+:::
 
 !!! note
 
@@ -201,6 +384,7 @@ graph = graph_builder.compile()
 
 ## 7. Visualize the graph (optional)
 
+:::python
 You can visualize the graph using the `get_graph` method and one of the "draw" methods, like `draw_ascii` or `draw_png`. The `draw` methods each require additional dependencies.
 
 ```python
@@ -212,6 +396,26 @@ except Exception:
     # This requires some extra dependencies and is optional
     pass
 ```
+:::
+
+:::js
+You can visualize the graph using the `getGraph` method and one of the "draw" methods, like `drawAscii` or `drawMermaidPng`. The `draw` methods each require additional dependencies.
+
+```typescript
+import * as tslab from "tslab";
+
+try {
+  const representation = graph.getGraph();
+  const image = await representation.drawMermaidPng();
+  const arrayBuffer = await image.arrayBuffer();
+  
+  await tslab.display.png(new Uint8Array(arrayBuffer));
+} catch (error) {
+  // This requires some extra dependencies and is optional
+  console.log("Graph visualization not available");
+}
+```
+:::
 
 ![chatbot-with-tools-diagram](chatbot-with-tools.png)
 
@@ -219,6 +423,7 @@ except Exception:
 
 Now you can ask the chatbot questions outside its training data:
 
+:::python
 ```python
 def stream_graph_updates(user_input: str):
     for event in graph.stream({"messages": [{"role": "user", "content": user_input}]}):
@@ -274,11 +479,71 @@ LangGraph appears to be a significant tool in the evolving landscape of LLM-base
 Goodbye!
 Output is truncated. View as a scrollable element or open in a text editor. Adjust cell output settings...
 ```
+:::
+
+:::js
+```typescript
+import { HumanMessage } from "@langchain/core/messages";
+
+const streamGraphUpdates = async (userInput: string) => {
+  const stream = await graph.stream(
+    { messages: [new HumanMessage(userInput)] },
+    { streamMode: "values" }
+  );
+  
+  for await (const event of stream) {
+    const messages = event.messages;
+    const lastMessage = messages[messages.length - 1];
+    console.log("Assistant:", lastMessage.content);
+  }
+};
+
+// Example usage
+const userInput = "What do you know about LangGraph?";
+console.log("User:", userInput);
+await streamGraphUpdates(userInput);
+```
+
+```
+Assistant: I'll search for information about LangGraph to provide you with accurate details.
+Assistant: [{"title": "Introduction to LangGraph: A Beginner's Guide - Medium", "url": "https://medium.com/@cplog/introduction-to-langgraph-a-beginners-guide-14f9be027141", "content": "Stateful Graph: LangGraph revolves around the concept of a stateful graph, where each node in the graph represents a step in your computation, and the graph maintains a state that is passed around and updated as the computation progresses. LangGraph supports conditional edges, allowing you to dynamically determine the next node to execute based on the current state of the graph. We define nodes for classifying the input, handling greetings, and handling search queries. def classify_input_node(state): LangGraph is a versatile tool for building complex, stateful applications with LLMs. By understanding its core concepts and working through simple examples, beginners can start to leverage its power for their projects. Remember to pay attention to state management, conditional edges, and ensuring there are no dead-end nodes in your graph.", "score": 0.7065353, "raw_content": null}, {"title": "LangGraph Tutorial: What Is LangGraph and How to Use It?", "url": "https://www.datacamp.com/tutorial/langgraph-tutorial", "content": "LangGraph is a library within the LangChain ecosystem that provides a framework for defining, coordinating, and executing multiple LLM agents or chains in a structured and efficient manner. By managing the flow of data and the sequence of operations, LangGraph allows developers to focus on the high-level logic of their applications rather than the intricacies of agent coordination. Whether you need a chatbot that can handle various types of user requests or a multi-agent system that performs complex tasks, LangGraph provides the tools to build exactly what you need. LangGraph significantly simplifies the development of complex LLM applications by providing a structured framework for managing state and coordinating agent interactions.", "score": 0.5008063, "raw_content": null}]
+Assistant: Based on the search results, I can provide you with comprehensive information about LangGraph:
+
+## What is LangGraph?
+
+LangGraph is a library within the LangChain ecosystem designed for building stateful, multi-actor applications with Large Language Models (LLMs). It provides a framework for defining, coordinating, and executing multiple LLM agents or chains in a structured and efficient manner.
+
+## Key Features:
+
+1. **Stateful Graph Architecture**: LangGraph revolves around the concept of a stateful graph where each node represents a step in your computation, and the graph maintains state that is passed around and updated as the computation progresses.
+
+2. **Conditional Edges**: It supports conditional edges, allowing you to dynamically determine the next node to execute based on the current state of the graph.
+
+3. **Multi-Agent Coordination**: LangGraph manages the flow of data and sequence of operations, allowing developers to focus on high-level logic rather than the intricacies of agent coordination.
+
+## Use Cases:
+
+- Building conversational agents
+- Creating chatbots that can handle various types of user requests
+- Developing multi-agent systems that perform complex tasks
+- Complex task automation
+- Custom LLM-backed experiences
+
+## Benefits:
+
+- **Simplified Development**: LangGraph significantly simplifies the development of complex LLM applications by providing a structured framework for managing state and coordinating agent interactions.
+- **Flexibility**: It's a versatile tool for building complex, stateful applications with LLMs.
+- **Focus on Logic**: Developers can focus on the high-level logic of their applications rather than coordination details.
+
+LangGraph is particularly valuable for projects that require sophisticated AI workflows with multiple steps, decision points, and state management across different components.
+```
+:::
 
 ## 9. Use prebuilts
 
 For ease of use, adjust your code to replace the following with LangGraph prebuilt components. These have built in functionality like parallel API execution.
 
+:::python
 - `BasicToolNode` is replaced with the prebuilt [ToolNode](https://langchain-ai.github.io/langgraph/reference/prebuilt/#toolnode)
 - `route_tools` is replaced with the prebuilt [tools_condition](https://langchain-ai.github.io/langgraph/reference/prebuilt/#tools_condition)
 
@@ -322,9 +587,56 @@ graph_builder.add_edge("tools", "chatbot")
 graph_builder.add_edge(START, "chatbot")
 graph = graph_builder.compile()
 ```
+:::
+
+:::js
+- `BasicToolNode` is replaced with the prebuilt [ToolNode](https://langchain-ai.github.io/langgraph/reference/prebuilt/#toolnode)
+- `routeTools` is replaced with the prebuilt [tools_condition](https://langchain-ai.github.io/langgraph/reference/prebuilt/#tools_condition)
+
+```typescript hl_lines="25 30"
+import { Annotation } from "@langchain/langgraph";
+import { BaseMessage } from "@langchain/core/messages";
+import { TavilySearchResults } from "@langchain/community/tools/tavily_search";
+import { ChatOpenAI } from "@langchain/openai";
+
+import { StateGraph, START, END } from "@langchain/langgraph";
+import { ToolNode, toolsCondition } from "@langchain/langgraph/prebuilt";
+
+const StateAnnotation = Annotation.Root({
+  messages: Annotation<BaseMessage[]>({
+    reducer: (x, y) => x.concat(y),
+  }),
+});
+
+const graphBuilder = new StateGraph(StateAnnotation);
+
+const tool = new TavilySearchResults({ maxResults: 2 });
+const tools = [tool];
+const llm = new ChatOpenAI({ model: "gpt-4o", temperature: 0 });
+const llmWithTools = llm.bindTools(tools);
+
+const chatbot = async (state: typeof StateAnnotation.State) => {
+  return { messages: [await llmWithTools.invoke(state.messages)] };
+};
+
+graphBuilder.addNode("chatbot", chatbot);
+
+const toolNode = new ToolNode(tools);
+graphBuilder.addNode("tools", toolNode);
+
+graphBuilder.addConditionalEdges(
+  "chatbot",
+  toolsCondition,
+);
+// Any time a tool is called, we return to the chatbot to decide the next step
+graphBuilder.addEdge("tools", "chatbot");
+graphBuilder.addEdge(START, "chatbot");
+const graph = graphBuilder.compile();
+```
+:::
 
 **Congratulations!** You've created a conversational agent in LangGraph that can use a search engine to retrieve updated information when needed. Now it can handle a wider range of user queries. To inspect all the steps your agent just took, check out this [LangSmith trace](https://smith.langchain.com/public/4fbd7636-25af-4638-9587-5a02fdbb0172/r).
 
 ## Next steps
 
-The chatbot cannot remember past interactions on its own, which limits its ability to have coherent, multi-turn conversations. In the next part, you will [add **memory**](./3-add-memory.md) to address this.
+The chatbot cannot remember past interactions on its own, which limits its ability to have coherent, multi-turn conversations. In the next part, you will [add **memory**](./3-add-memory.md) to address this.

docs/docs/tutorials/get-started/3-add-memory.md

@@ -14,11 +14,21 @@ We will see later that **checkpointing** is _much_ more powerful than simple cha
 
 Create a `MemorySaver` checkpointer:
 
+:::python
 ``` python
 from langgraph.checkpoint.memory import MemorySaver
 
 memory = MemorySaver()
 ```
+:::
+
+:::js
+```typescript
+import { MemorySaver } from "@langchain/langgraph";
+
+const memory = new MemorySaver();
+```
+:::
 
 This is in-memory checkpointer, which is convenient for the tutorial. However, in a production application, you would likely change this to use `SqliteSaver` or `PostgresSaver` and connect a database.
 
@@ -26,6 +36,7 @@ This is in-memory checkpointer, which is convenient for the tutorial. However, i
 
 Compile the graph with the provided checkpointer, which will checkpoint the `State` as the graph works through each node:
 
+:::python
 ``` python
 graph = graph_builder.compile(checkpointer=memory)
 ```
@@ -39,6 +50,27 @@ except Exception:
     # This requires some extra dependencies and is optional
     pass
 ```
+:::
+
+:::js
+```typescript
+const graph = graphBuilder.compile({ checkpointer: memory });
+```
+
+```typescript
+import * as tslab from "tslab";
+
+try {
+    const representation = graph.getGraph();
+    const image = await representation.drawMermaidPng();
+    const arrayBuffer = await image.arrayBuffer();
+    
+    await tslab.display.png(new Uint8Array(arrayBuffer));
+} catch (e) {
+    // This requires some extra dependencies and is optional
+}
+```
+:::
 
 ## 3. Interact with your chatbot
 
@@ -46,12 +78,21 @@ Now you can interact with your bot!
 
 1. Pick a thread to use as the key for this conversation.
 
+    :::python
     ```python
     config = {"configurable": {"thread_id": "1"}}
     ```
+    :::
+
+    :::js
+    ```typescript
+    const config = { configurable: { thread_id: "1" } };
+    ```
+    :::
 
 2. Call your chatbot:
 
+    :::python
     ```python
     user_input = "Hi there! My name is Will."
 
@@ -64,6 +105,24 @@ Now you can interact with your bot!
     for event in events:
         event["messages"][-1].pretty_print()
     ```
+    :::
+
+    :::js
+    ```typescript
+    const userInput = "Hi there! My name is Will.";
+
+    // The config is the **second positional argument** to stream() or invoke()!
+    const events = await graph.stream(
+        { messages: [{ role: "user", content: userInput }] },
+        { ...config, streamMode: "values" }
+    );
+    
+    for await (const event of events) {
+        const messages = event.messages;
+        console.log(messages[messages.length - 1]);
+    }
+    ```
+    :::
 
     ```
     ================================ Human Message =================================
@@ -74,14 +133,23 @@ Now you can interact with your bot!
     Hello Will! It's nice to meet you. How can I assist you today? Is there anything specific you'd like to know or discuss?
     ```
 
+    :::python
     !!! note 
 
         The config was provided as the **second positional argument** when calling our graph. It importantly is _not_ nested within the graph inputs (`{'messages': []}`).
+    :::
+
+    :::js
+    !!! note 
+
+        The config was provided as the **second positional argument** when calling our graph. It importantly is _not_ nested within the graph inputs (`{ messages: [] }`).
+    :::
 
 ## 4. Ask a follow up question
 
 Ask a follow up question:
 
+:::python
 ```python
 user_input = "Remember my name?"
 
@@ -94,6 +162,24 @@ events = graph.stream(
 for event in events:
     event["messages"][-1].pretty_print()
 ```
+:::
+
+:::js
+```typescript
+const userInput2 = "Remember my name?";
+
+// The config is the **second positional argument** to stream() or invoke()!
+const events2 = await graph.stream(
+    { messages: [{ role: "user", content: userInput2 }] },
+    { ...config, streamMode: "values" }
+);
+
+for await (const event of events2) {
+    const messages = event.messages;
+    console.log(messages[messages.length - 1]);
+}
+```
+:::
 
 ```
 ================================ Human Message =================================
@@ -108,6 +194,7 @@ Of course, I remember your name, Will. I always try to pay attention to importan
 
 Don't believe me? Try this using a different config.
 
+:::python
 ```python
 # The only difference is we change the `thread_id` here to "2" instead of "1"
 events = graph.stream(
@@ -119,6 +206,23 @@ events = graph.stream(
 for event in events:
     event["messages"][-1].pretty_print()
 ```
+:::
+
+:::js
+```typescript
+// The only difference is we change the `thread_id` here to "2" instead of "1"
+const events3 = await graph.stream(
+    { messages: [{ role: "user", content: userInput2 }] },
+    // highlight-next-line
+    { configurable: { thread_id: "2" }, streamMode: "values" }
+);
+
+for await (const event of events3) {
+    const messages = event.messages;
+    console.log(messages[messages.length - 1]);
+}
+```
+:::
 
 ```
 ================================ Human Message =================================
@@ -133,8 +237,15 @@ I apologize, but I don't have any previous context or memory of your name. As an
 
 ## 5. Inspect the state
 
+:::python
 By now, we have made a few checkpoints across two different threads. But what goes into a checkpoint? To inspect a graph's `state` for a given config at any time, call `get_state(config)`.
+:::
 
+:::js
+By now, we have made a few checkpoints across two different threads. But what goes into a checkpoint? To inspect a graph's `state` for a given config at any time, call `getState(config)`.
+:::
+
+:::python
 ```python
 snapshot = graph.get_state(config)
 snapshot
@@ -147,6 +258,75 @@ StateSnapshot(values={'messages': [HumanMessage(content='Hi there! My name is Wi
 ```
 snapshot.next  # (since the graph ended this turn, `next` is empty. If you fetch a state from within a graph invocation, next tells which node will execute next)
 ```
+:::
+
+:::js
+```typescript
+const snapshot = await graph.getState(config);
+console.log(snapshot);
+```
+
+```
+StateSnapshot {
+  values: {
+    messages: [
+      HumanMessage {
+        content: 'Hi there! My name is Will.',
+        id: '8c1ca919-c553-4ebf-95d4-b59a2d61e078'
+      },
+      AIMessage {
+        content: "Hello Will! It's nice to meet you. How can I assist you today? Is there anything specific you'd like to know or discuss?",
+        id: 'run-58587b77-8c82-41e6-8a90-d62c444a261d-0'
+      },
+      HumanMessage {
+        content: 'Remember my name?',
+        id: 'daba7df6-ad75-4d6b-8057-745881cea1ca'
+      },
+      AIMessage {
+        content: "Of course, I remember your name, Will. I always try to pay attention to important details that users share with me. Is there anything else you'd like to talk about or any questions you have? I'm here to help with a wide range of topics or tasks.",
+        id: 'run-ffeaae5c-4d2d-4ddb-bd59-5d5cbf2a5af8-0'
+      }
+    ]
+  },
+  next: [],
+  config: {
+    configurable: {
+      thread_id: '1',
+      checkpoint_ns: '',
+      checkpoint_id: '1ef7d06e-93e0-6acc-8004-f2ac846575d2'
+    }
+  },
+  metadata: {
+    source: 'loop',
+    writes: {
+      chatbot: {
+        messages: [
+          AIMessage {
+            content: "Of course, I remember your name, Will. I always try to pay attention to important details that users share with me. Is there anything else you'd like to talk about or any questions you have? I'm here to help with a wide range of topics or tasks.",
+            id: 'run-ffeaae5c-4d2d-4ddb-bd59-5d5cbf2a5af8-0'
+          }
+        ]
+      }
+    },
+    step: 4,
+    parents: {}
+  },
+  createdAt: '2024-09-27T19:30:10.820758+00:00',
+  parentConfig: {
+    configurable: {
+      thread_id: '1',
+      checkpoint_ns: '',
+      checkpoint_id: '1ef7d06e-859f-6206-8003-e1bd3c264b8f'
+    }
+  },
+  tasks: []
+}
+```
+
+```typescript
+console.log(snapshot.next);  // (since the graph ended this turn, `next` is empty. If you fetch a state from within a graph invocation, next tells which node will execute next)
+```
+:::
 
 The snapshot above contains the current state values, corresponding config, and the `next` node to process. In our case, the graph has reached an `END` state, so `next` is empty.
 
@@ -157,13 +337,24 @@ Check out the code snippet below to review the graph from this tutorial:
 {!snippets/chat_model_tabs.md!}
 
 <!---
+:::python
 ```python
 from langchain.chat_models import init_chat_model
 
 llm = init_chat_model("anthropic:claude-3-5-sonnet-latest")
 ```
+:::
+
+:::js
+```typescript
+import { ChatOpenAI } from "@langchain/openai";
+
+const llm = new ChatOpenAI({ model: "gpt-4" });
+```
+:::
 -->
 
+:::python
 ```python hl_lines="36 37"
 from typing import Annotated
 
@@ -203,7 +394,51 @@ graph_builder.set_entry_point("chatbot")
 memory = MemorySaver()
 graph = graph_builder.compile(checkpointer=memory)
 ```
+:::
+
+:::js
+```typescript hl_lines="36 37"
+import { Annotation } from "@langchain/langgraph";
+import { ChatOpenAI } from "@langchain/openai";
+import { TavilySearchResults } from "@langchain/community/tools/tavily_search";
+import { BaseMessage } from "@langchain/core/messages";
+import { MemorySaver, StateGraph } from "@langchain/langgraph";
+import { ToolNode, toolsCondition } from "@langchain/langgraph/prebuilt";
+
+const StateAnnotation = Annotation.Root({
+    messages: Annotation<BaseMessage[]>({
+        reducer: (x, y) => x.concat(y),
+    }),
+});
+
+const graphBuilder = new StateGraph(StateAnnotation);
+
+const tool = new TavilySearchResults({ maxResults: 2 });
+const tools = [tool];
+const llm = new ChatOpenAI({ model: "gpt-4" });
+const llmWithTools = llm.bindTools(tools);
+
+function chatbot(state: typeof StateAnnotation.State) {
+    return { messages: [llmWithTools.invoke(state.messages)] };
+}
+
+graphBuilder.addNode("chatbot", chatbot);
+
+const toolNode = new ToolNode(tools);
+graphBuilder.addNode("tools", toolNode);
+
+graphBuilder.addConditionalEdges(
+    "chatbot",
+    toolsCondition,
+);
+graphBuilder.addEdge("tools", "chatbot");
+graphBuilder.addEdge("__start__", "chatbot");
+
+const memory = new MemorySaver();
+const graph = graphBuilder.compile({ checkpointer: memory });
+```
+:::
 
 ## Next steps
 
-In the next tutorial, you will [add human-in-the-loop to the chatbot](./4-human-in-the-loop.md) to handle situations where it may need guidance or verification before proceeding.
+In the next tutorial, you will [add human-in-the-loop to the chatbot](./4-human-in-the-loop.md) to handle situations where it may need guidance or verification before proceeding.

docs/docs/tutorials/get-started/4-human-in-the-loop.md

@@ -14,6 +14,7 @@ Starting with the existing code from the [Add memory to the chatbot](./3-add-mem
 
 Let's first select a chat model:
 
+:::python
 {!snippets/chat_model_tabs.md!}
 
 <!---
@@ -23,9 +24,21 @@ from langchain.chat_models import init_chat_model
 llm = init_chat_model("anthropic:claude-3-5-sonnet-latest")
 ```
 -->
+:::
+
+:::js
+```typescript
+import { ChatAnthropic } from "@langchain/anthropic";
+
+const llm = new ChatAnthropic({
+  model: "claude-3-5-sonnet-latest",
+});
+```
+:::
 
 We can now incorporate it into our `StateGraph` with an additional tool:
 
+:::python
 ``` python hl_lines="12 19 20 21 22 23"
 from typing import Annotated
 
@@ -75,25 +88,90 @@ graph_builder.add_conditional_edges(
 graph_builder.add_edge("tools", "chatbot")
 graph_builder.add_edge(START, "chatbot")
 ```
+:::
+
+:::js
+```typescript hl_lines="12 19 20 21 22 23"
+import { tool } from "@langchain/core/tools";
+import { TavilySearchResults } from "@langchain/community/tools/tavily_search";
+import { z } from "zod";
+
+import { MemorySaver } from "@langchain/langgraph";
+import { StateGraph, START, END, MessagesAnnotation } from "@langchain/langgraph";
+import { ToolNode, toolsCondition } from "@langchain/langgraph/prebuilt";
+
+import { interrupt, Command } from "@langchain/langgraph";
+
+const humanAssistance = tool(async ({ query }) => {
+  const humanResponse = interrupt({ query });
+  return humanResponse.data;
+}, {
+  name: "human_assistance",
+  description: "Request assistance from a human.",
+  schema: z.object({
+    query: z.string().describe("Human readable question for the human")
+  })
+});
+
+const searchTool = new TavilySearchResults({ maxResults: 2 });
+const tools = [searchTool, humanAssistance];
+const llmWithTools = llm.bindTools(tools);
+
+const chatbot = async (state: typeof MessagesAnnotation.State) => {
+  const message = await llmWithTools.invoke(state.messages);
+  // Because we will be interrupting during tool execution,
+  // we disable parallel tool calling to avoid repeating any
+  // tool invocations when we resume.
+  if (message.tool_calls && message.tool_calls.length > 1) {
+    throw new Error("Multiple tool calls not supported for this example");
+  }
+  return { messages: [message] };
+};
+
+const graphBuilder = new StateGraph(MessagesAnnotation)
+  .addNode("chatbot", chatbot);
+
+const toolNode = new ToolNode(tools);
+graphBuilder.addNode("tools", toolNode);
+
+graphBuilder.addConditionalEdges(
+  "chatbot",
+  toolsCondition,
+);
+graphBuilder.addEdge("tools", "chatbot");
+graphBuilder.addEdge(START, "chatbot");
+```
+:::
 
 !!! tip
 
-    For more information and examples of human-in-the-loop workflows, see [Human-in-the-loop](../../concepts/human_in_the_loop.md).
+    For more information and examples of human-in-the-loop workflows, see [Human-in-the-loop](../../concepts/human_in_the_loop.md). This includes how to [review and edit tool calls](../../how-tos/human_in_the_loop/review-tool-calls.ipynb) before they are executed.
 
 ## 2. Compile the graph
 
 We compile the graph with a checkpointer, as before:
 
+:::python
 ```python
 memory = MemorySaver()
 
 graph = graph_builder.compile(checkpointer=memory)
 ```
+:::
+
+:::js
+```typescript
+const memory = new MemorySaver();
+
+const graph = graphBuilder.compile({ checkpointer: memory });
+```
+:::
 
 ## 3. Visualize the graph (optional)
 
 Visualizing the graph, you get the same layout as before – just with the added tool!
 
+:::python
 ``` python
 from IPython.display import Image, display
 
@@ -103,6 +181,19 @@ except Exception:
     # This requires some extra dependencies and is optional
     pass
 ```
+:::
+
+:::js
+```typescript
+import * as tslab from "tslab";
+
+const drawableGraph = graph.getGraph();
+const image = await drawableGraph.drawMermaidPng();
+const arrayBuffer = await image.arrayBuffer();
+
+await tslab.display.png(new Uint8Array(arrayBuffer));
+```
+:::
 
 ![chatbot-with-tools-diagram](chatbot-with-tools.png)
 
@@ -110,6 +201,7 @@ except Exception:
 
 Now, prompt the chatbot with a question that will engage the new `human_assistance` tool:
 
+:::python
 ```python
 user_input = "I need some expert guidance for building an AI agent. Could you request assistance for me?"
 config = {"configurable": {"thread_id": "1"}}
@@ -137,9 +229,49 @@ Tool Calls:
   Args:
     query: A user is requesting expert guidance for building an AI agent. Could you please provide some expert advice or resources on this topic?
 ```
+:::
+
+:::js
+```typescript
+const userInput = "I need some expert guidance for building an AI agent. Could you request assistance for me?";
+const config = { configurable: { thread_id: "1" }, streamMode: "values" as const };
+
+const events = graph.stream(
+  { messages: [{ role: "user", content: userInput }] },
+  config,
+);
+
+for await (const event of events) {
+  if (event.messages) {
+    const lastMessage = event.messages[event.messages.length - 1];
+    console.log(`================================ ${lastMessage.getType()} Message =================================`);
+    console.log(lastMessage.content);
+    if (lastMessage.tool_calls?.length) {
+      console.log("Tool Calls:");
+      lastMessage.tool_calls.forEach((call) => {
+        console.log(`  ${call.name} (${call.id})`);
+        console.log(`  Args: ${JSON.stringify(call.args)}`);
+      });
+    }
+  }
+}
+```
+
+```
+================================ Human Message =================================
+I need some expert guidance for building an AI agent. Could you request assistance for me?
+================================== Ai Message ==================================
+I'd be happy to request expert assistance for you regarding building an AI agent. Let me use the human assistance function to get you some expert guidance.
+
+Tool Calls:
+  human_assistance (toolu_01ABUqneqnuHNuo1vhfDFQCW)
+  Args: {"query":"A user is requesting expert guidance for building an AI agent. Could you please provide some expert advice or resources on this topic?"}
+```
+:::
 
 The chatbot generated a tool call, but then execution has been interrupted. If you inspect the graph state, you see that it stopped at the tools node:
 
+:::python
 ```python
 snapshot = graph.get_state(config)
 snapshot.next
@@ -148,7 +280,20 @@ snapshot.next
 ```
 ('tools',)
 ```
+:::
 
+:::js
+```typescript
+const snapshot = await graph.getState(config);
+console.log(snapshot.next);
+```
+
+```
+['tools']
+```
+:::
+
+:::python
 !!! info Additional information
 
     Take a closer look at the `human_assistance` tool:
@@ -162,11 +307,34 @@ snapshot.next
     ```
 
     Similar to Python's built-in `input()` function, calling `interrupt` inside the tool will pause execution. Progress is persisted based on the [checkpointer](../../concepts/persistence.md#checkpointer-libraries); so if it is persisting with Postgres, it can resume at any time as long as the database is alive. In this example, it is persisting with the in-memory checkpointer and can resume any time if the Python kernel is running.
+:::
+
+:::js
+!!! info Additional information
+
+    Take a closer look at the `human_assistance` tool:
+
+    ```typescript
+    const humanAssistance = tool(async ({ query }) => {
+      const humanResponse = interrupt({ query });
+      return humanResponse.data;
+    }, {
+      name: "human_assistance",
+      description: "Request assistance from a human.",
+      schema: z.object({
+        query: z.string().describe("Human readable question for the human")
+      })
+    });
+    ```
+
+    Similar to Python's built-in `input()` function, calling `interrupt` inside the tool will pause execution. Progress is persisted based on the [checkpointer](../../concepts/persistence.md#checkpointer-libraries); so if it is persisting with Postgres, it can resume at any time as long as the database is alive. In this example, it is persisting with the in-memory checkpointer and can resume any time if the JavaScript runtime is running.
+:::
 
 ## 5. Resume execution
 
 To resume execution, pass a [`Command`](../../concepts/low_level.md#command) object containing data expected by the tool. The format of this data can be customized based on needs. For this example, use a dict with a key `"data"`:
 
+:::python
 ``` python
 human_response = (
     "We, the experts are here to help! We'd recommend you check out LangGraph to build your agent."
@@ -214,6 +382,47 @@ LangGraph is likely a framework or library designed specifically for creating AI
 If you'd like more specific information about LangGraph or have any questions about this recommendation, please feel free to ask, and I can request further assistance from the experts.
 Output is truncated. View as a scrollable element or open in a text editor. Adjust cell output settings...
 ```
+:::
+
+:::js
+```typescript
+const humanResponse = 
+  "We, the experts are here to help! We'd recommend you check out LangGraph to build your agent." +
+  " It's much more reliable and extensible than simple autonomous agents.";
+
+const humanCommand = new Command({ resume: { data: humanResponse } });
+
+const resumeEvents = graph.stream(humanCommand, config);
+
+for await (const event of resumeEvents) {
+  if (event.messages) {
+    const lastMessage = event.messages[event.messages.length - 1];
+    console.log(`================================ ${lastMessage.getType()} Message =================================`);
+    console.log(lastMessage.content);
+  }
+}
+```
+
+```
+================================== Ai Message ==================================
+I'd be happy to request expert assistance for you regarding building an AI agent. Let me use the human assistance function to get you some expert guidance.
+================================= Tool Message =================================
+We, the experts are here to help! We'd recommend you check out LangGraph to build your agent. It's much more reliable and extensible than simple autonomous agents.
+================================== Ai Message ==================================
+Thank you for your patience. I've received some expert advice regarding your request for guidance on building an AI agent. Here's what the experts have suggested:
+
+The experts recommend that you look into LangGraph for building your AI agent. They mention that LangGraph is a more reliable and extensible option compared to simple autonomous agents.
+
+LangGraph is likely a framework or library designed specifically for creating AI agents with advanced capabilities. Here are a few points to consider based on this recommendation:
+
+1. Reliability: The experts emphasize that LangGraph is more reliable than simpler autonomous agent approaches. This could mean it has better stability, error handling, or consistent performance.
+
+2. Extensibility: LangGraph is described as more extensible, which suggests that it probably offers a flexible architecture that allows you to easily add new features or modify existing ones as your agent's requirements evolve.
+
+3. Advanced capabilities: Given that it's recommended over "simple autonomous agents," LangGraph likely provides more sophisticated tools and techniques for building complex AI agents.
+...
+```
+:::
 
 The input has been received and processed as a tool message. Review this call's [LangSmith trace](https://smith.langchain.com/public/9f0f87e3-56a7-4dde-9c76-b71675624e91/r) to see the exact work that was done in the above call. Notice that the state is loaded in the first step so that our chatbot can continue where it left off.
 
@@ -221,6 +430,7 @@ The input has been received and processed as a tool message. Review this call's
 
 Check out the code snippet below to review the graph from this tutorial:
 
+:::python
 {!snippets/chat_model_tabs.md!}
 
 ```python
@@ -271,6 +481,64 @@ graph_builder.add_edge(START, "chatbot")
 memory = MemorySaver()
 graph = graph_builder.compile(checkpointer=memory)
 ```
+:::
+
+:::js
+```typescript
+import { tool } from "@langchain/core/tools";
+import { TavilySearchResults } from "@langchain/community/tools/tavily_search";
+import { z } from "zod";
+import { ChatAnthropic } from "@langchain/anthropic";
+
+import { MemorySaver } from "@langchain/langgraph";
+import { StateGraph, START, END, MessagesAnnotation } from "@langchain/langgraph";
+import { ToolNode, toolsCondition } from "@langchain/langgraph/prebuilt";
+import { interrupt, Command } from "@langchain/langgraph";
+
+const llm = new ChatAnthropic({
+  model: "claude-3-5-sonnet-latest",
+});
+
+const humanAssistance = tool(async ({ query }) => {
+  const humanResponse = interrupt({ query });
+  return humanResponse.data;
+}, {
+  name: "human_assistance",
+  description: "Request assistance from a human.",
+  schema: z.object({
+    query: z.string().describe("Human readable question for the human")
+  })
+});
+
+const searchTool = new TavilySearchResults({ maxResults: 2 });
+const tools = [searchTool, humanAssistance];
+const llmWithTools = llm.bindTools(tools);
+
+const chatbot = async (state: typeof MessagesAnnotation.State) => {
+  const message = await llmWithTools.invoke(state.messages);
+  if (message.tool_calls && message.tool_calls.length > 1) {
+    throw new Error("Multiple tool calls not supported for this example");
+  }
+  return { messages: [message] };
+};
+
+const graphBuilder = new StateGraph(MessagesAnnotation)
+  .addNode("chatbot", chatbot);
+
+const toolNode = new ToolNode(tools);
+graphBuilder.addNode("tools", toolNode);
+
+graphBuilder.addConditionalEdges(
+  "chatbot",
+  toolsCondition,
+);
+graphBuilder.addEdge("tools", "chatbot");
+graphBuilder.addEdge(START, "chatbot");
+
+const memory = new MemorySaver();
+const graph = graphBuilder.compile({ checkpointer: memory });
+```
+:::
 
 ## Next steps
 

docs/docs/tutorials/get-started/5-customize-state.md

@@ -10,6 +10,7 @@ In this tutorial, you will add additional fields to the state to define complex
 
 Update the chatbot to research the birthday of an entity by adding `name` and `birthday` keys to the state:
 
+:::python
 ```python
 from typing import Annotated
 
@@ -25,11 +26,30 @@ class State(TypedDict):
     # highlight-next-line
     birthday: str
 ```
+:::
+
+:::js
+```typescript
+import { Annotation } from "@langchain/langgraph";
+import { BaseMessage } from "@langchain/core/messages";
+
+const StateAnnotation = Annotation.Root({
+  messages: Annotation<BaseMessage[]>({
+    reducer: (x, y) => x.concat(y),
+  }),
+  // highlight-next-line
+  name: Annotation<string>,
+  // highlight-next-line
+  birthday: Annotation<string>,
+});
+```
+:::
 
 Adding this information to the state makes it easily accessible by other graph nodes (like a downstream node that stores or processes the information), as well as the graph's persistence layer.
 
 ## 2. Update the state inside the tool
 
+:::python
 Now, populate the state keys inside of the `human_assistance` tool. This allows a human to review the information before it is stored in the state. Use [`Command`](../../concepts/low_level.md#using-inside-tools) to issue a state update from inside the tool.
 
 ``` python
@@ -75,11 +95,73 @@ def human_assistance(
     # We return a Command object in the tool to update our state.
     return Command(update=state_update)
 ```
+:::
+
+:::js
+Now, populate the state keys inside of the `humanAssistance` tool. This allows a human to review the information before it is stored in the state. Use [`Command`](../../concepts/low_level.md#using-inside-tools) to issue a state update from inside the tool.
+
+```typescript
+import { tool } from "@langchain/core/tools";
+import { ToolMessage } from "@langchain/core/messages";
+import { z } from "zod";
+import { Command, interrupt } from "@langchain/langgraph";
+
+const humanAssistance = tool(async (input, config) => {
+  const { name, birthday } = input;
+  // Note that because we are generating a ToolMessage for a state update, we
+  // generally require the ID of the corresponding tool call. We can access this
+  // from the tool's config when it's called by a model.
+  const toolCallId = config?.toolCall?.id;
+  
+  const humanResponse = interrupt({
+    question: "Is this correct?",
+    name: name,
+    birthday: birthday,
+  });
+  
+  let verifiedName, verifiedBirthday, response;
+  
+  // If the information is correct, update the state as-is.
+  if (humanResponse?.correct?.toLowerCase().startsWith("y")) {
+    verifiedName = name;
+    verifiedBirthday = birthday;
+    response = "Correct";
+  } else {
+    // Otherwise, receive information from the human reviewer.
+    verifiedName = humanResponse?.name || name;
+    verifiedBirthday = humanResponse?.birthday || birthday;
+    response = `Made a correction: ${JSON.stringify(humanResponse)}`;
+  }
+  
+  // This time we explicitly update the state with a ToolMessage inside
+  // the tool.
+  const stateUpdate = {
+    name: verifiedName,
+    birthday: verifiedBirthday,
+    messages: [new ToolMessage({
+      content: response,
+      tool_call_id: toolCallId!
+    })],
+  };
+  
+  // We return a Command object in the tool to update our state.
+  return new Command({ update: stateUpdate });
+}, {
+  name: "humanAssistance",
+  description: "Request assistance from a human.",
+  schema: z.object({
+    name: z.string(),
+    birthday: z.string(),
+  }),
+});
+```
+:::
 
 The rest of the graph stays the same.
 
 ## 3. Prompt the chatbot
 
+:::python
 Prompt the chatbot to look up the "birthday" of the LangGraph library and direct the chatbot to reach out to the `human_assistance` tool once it has the required information. By setting `name` and `birthday` in the arguments for the tool, you force the chatbot to generate proposals for these fields.
 
 ```python
@@ -98,6 +180,30 @@ for event in events:
     if "messages" in event:
         event["messages"][-1].pretty_print()
 ```
+:::
+
+:::js
+Prompt the chatbot to look up the "birthday" of the LangGraph library and direct the chatbot to reach out to the `humanAssistance` tool once it has the required information. By setting `name` and `birthday` in the arguments for the tool, you force the chatbot to generate proposals for these fields.
+
+```typescript
+const userInput = "Can you look up when LangGraph was released? " +
+  "When you have the answer, use the humanAssistance tool for review.";
+const config = { configurable: { thread_id: "1" } };
+
+const events = graph.stream(
+  { messages: [{ role: "user", content: userInput }] },
+  { ...config, streamMode: "values" }
+);
+
+for await (const event of events) {
+  if (event.messages) {
+    const lastMessage = event.messages[event.messages.length - 1];
+    console.log(`================================ ${lastMessage._getType()} Message =================================`);
+    console.log(lastMessage.content);
+  }
+}
+```
+:::
 
 ```
 ================================ Human Message =================================
@@ -130,6 +236,7 @@ We've hit the `interrupt` in the `human_assistance` tool again.
 
 ## 4. Add human assistance
 
+:::python
 The chatbot failed to identify the correct date, so supply it with information:
 
 ```python
@@ -145,6 +252,32 @@ for event in events:
     if "messages" in event:
         event["messages"][-1].pretty_print()
 ```
+:::
+
+:::js
+The chatbot failed to identify the correct date, so supply it with information:
+
+```typescript
+import { Command } from "@langchain/langgraph";
+
+const humanCommand = new Command({
+  resume: {
+    name: "LangGraph",
+    birthday: "Jan 17, 2024",
+  },
+});
+
+const resumeEvents = graph.stream(humanCommand, { ...config, streamMode: "values" });
+
+for await (const event of resumeEvents) {
+  if (event.messages) {
+    const lastMessage = event.messages[event.messages.length - 1];
+    console.log(`================================ ${lastMessage._getType()} Message =================================`);
+    console.log(lastMessage.content);
+  }
+}
+```
+:::
 
 ```
 ================================== Ai Message ==================================
@@ -175,11 +308,25 @@ It's worth noting that LangGraph had been in development and use for some time b
 
 Note that these fields are now reflected in the state:
 
+:::python
 ```python
 snapshot = graph.get_state(config)
 
 {k: v for k, v in snapshot.values.items() if k in ("name", "birthday")}
 ```
+:::
+
+:::js
+```typescript
+const snapshot = await graph.getState(config);
+
+const relevantState = {
+  name: snapshot.values.name,
+  birthday: snapshot.values.birthday
+};
+console.log(relevantState);
+```
+:::
 
 ```
 {'name': 'LangGraph', 'birthday': 'Jan 17, 2024'}
@@ -189,11 +336,21 @@ This makes them easily accessible to downstream nodes (e.g., a node that further
 
 ## 5. Manually update the state
 
+:::python
 LangGraph gives a high degree of control over the application state. For instance, at any point (including when interrupted), you can manually override a key using `graph.update_state`:
 
 ``` python
 graph.update_state(config, {"name": "LangGraph (library)"})
 ```
+:::
+
+:::js
+LangGraph gives a high degree of control over the application state. For instance, at any point (including when interrupted), you can manually override a key using `graph.updateState`:
+
+```typescript
+await graph.updateState(config, { name: "LangGraph (library)" });
+```
+:::
 
 ```
 {'configurable': {'thread_id': '1',
@@ -203,6 +360,7 @@ graph.update_state(config, {"name": "LangGraph (library)"})
 
 ## 6. View the new value
 
+:::python
 If you call `graph.get_state`, you can see the new value is reflected:
 
 ``` python
@@ -210,12 +368,27 @@ snapshot = graph.get_state(config)
 
 {k: v for k, v in snapshot.values.items() if k in ("name", "birthday")}
 ```
+:::
+
+:::js
+If you call `graph.getState`, you can see the new value is reflected:
+
+```typescript
+const updatedSnapshot = await graph.getState(config);
+
+const updatedState = {
+  name: updatedSnapshot.values.name,
+  birthday: updatedSnapshot.values.birthday
+};
+console.log(updatedState);
+```
+:::
 
 ```
 {'name': 'LangGraph (library)', 'birthday': 'Jan 17, 2024'}
 ```
 
-Manual state updates will [generate a trace](https://smith.langchain.com/public/7ebb7827-378d-49fe-9f6c-5df0e90086c8/r) in LangSmith. If desired, they can also be used to [control human-in-the-loop workflows](../../how-tos/human_in_the_loop/add-human-in-the-loop.md). Use of the `interrupt` function is generally recommended instead, as it allows data to be transmitted in a human-in-the-loop interaction independently of state updates.
+Manual state updates will [generate a trace](https://smith.langchain.com/public/7ebb7827-378d-49fe-9f6c-5df0e90086c8/r) in LangSmith. If desired, they can also be used to [control human-in-the-loop workflows](../../how-tos/human_in_the_loop/edit-graph-state.md). Use of the `interrupt` function is generally recommended instead, as it allows data to be transmitted in a human-in-the-loop interaction independently of state updates.
 
 **Congratulations!** You've added custom keys to the state to facilitate a more complex workflow, and learned how to generate state updates from inside tools.
 
@@ -231,6 +404,7 @@ llm = init_chat_model("anthropic:claude-3-5-sonnet-latest")
 ```
 -->
 
+:::python
 ```python
 from typing import Annotated
 
@@ -304,8 +478,106 @@ graph_builder.add_edge(START, "chatbot")
 memory = MemorySaver()
 graph = graph_builder.compile(checkpointer=memory)
 ```
+:::
+
+:::js
+```typescript
+import { ChatAnthropic } from "@langchain/anthropic";
+import { TavilySearchResults } from "@langchain/community/tools/tavily_search";
+import { tool } from "@langchain/core/tools";
+import { ToolMessage, BaseMessage } from "@langchain/core/messages";
+import { z } from "zod";
+
+import { MemorySaver } from "@langchain/langgraph";
+import { StateGraph, START, Annotation } from "@langchain/langgraph";
+import { ToolNode } from "@langchain/langgraph/prebuilt";
+import { Command, interrupt } from "@langchain/langgraph";
+
+const llm = new ChatAnthropic({
+  model: "claude-3-5-sonnet-latest",
+});
+
+const StateAnnotation = Annotation.Root({
+  messages: Annotation<BaseMessage[]>({
+    reducer: (x, y) => x.concat(y),
+  }),
+  name: Annotation<string>,
+  birthday: Annotation<string>,
+});
+
+const humanAssistance = tool(async (input, config) => {
+  const { name, birthday } = input;
+  const toolCallId = config?.toolCall?.id;
+  
+  const humanResponse = interrupt({
+    question: "Is this correct?",
+    name: name,
+    birthday: birthday,
+  });
+  
+  let verifiedName, verifiedBirthday, response;
+  
+  if (humanResponse?.correct?.toLowerCase().startsWith("y")) {
+    verifiedName = name;
+    verifiedBirthday = birthday;
+    response = "Correct";
+  } else {
+    verifiedName = humanResponse?.name || name;
+    verifiedBirthday = humanResponse?.birthday || birthday;
+    response = `Made a correction: ${JSON.stringify(humanResponse)}`;
+  }
+  
+  const stateUpdate = {
+    name: verifiedName,
+    birthday: verifiedBirthday,
+    messages: [new ToolMessage({
+      content: response,
+      tool_call_id: toolCallId!
+    })],
+  };
+  
+  return new Command({ update: stateUpdate });
+}, {
+  name: "humanAssistance",
+  description: "Request assistance from a human.",
+  schema: z.object({
+    name: z.string(),
+    birthday: z.string(),
+  }),
+});
+
+const searchTool = new TavilySearchResults({ maxResults: 2 });
+const tools = [searchTool, humanAssistance];
+const llmWithTools = llm.bindTools(tools);
+
+const chatbot = async (state: typeof StateAnnotation.State) => {
+  const message = await llmWithTools.invoke(state.messages);
+  return { messages: [message] };
+};
+
+const shouldContinue = (state: typeof StateAnnotation.State) => {
+  const lastMessage = state.messages[state.messages.length - 1];
+  if ("tool_calls" in lastMessage && lastMessage.tool_calls?.length) {
+    return "tools";
+  }
+  return "__end__";
+};
+
+const graphBuilder = new StateGraph(StateAnnotation);
+graphBuilder.addNode("chatbot", chatbot);
+
+const toolNode = new ToolNode(tools);
+graphBuilder.addNode("tools", toolNode);
+
+graphBuilder.addConditionalEdges("chatbot", shouldContinue);
+graphBuilder.addEdge("tools", "chatbot");
+graphBuilder.addEdge(START, "chatbot");
+
+const memory = new MemorySaver();
+const graph = graphBuilder.compile({ checkpointer: memory });
+```
+:::
 
 ## Next steps
 
-There's one more concept to review before finishing the LangGraph basics tutorials: connecting `checkpointing` and `state updates` to [time travel](./6-time-travel.md). 
-
+There's one more concept to review before finishing the LangGraph basics tutorials: connecting `checkpointing` and `state updates` to [time travel](./6-time-travel.md).

docs/docs/tutorials/get-started/6-time-travel.md

@@ -12,18 +12,35 @@ You can create these types of experiences using LangGraph's built-in **time trav
 
 ## 1. Rewind your graph
 
+:::python
 Rewind your graph by fetching a checkpoint using the graph's `get_state_history` method. You can then resume execution at this previous point in time.
+:::
+
+:::js
+Rewind your graph by fetching a checkpoint using the graph's `getStateHistory` method. You can then resume execution at this previous point in time.
+:::
 
 {!snippets/chat_model_tabs.md!}
 
 <!---
+:::python
 ```python
 from langchain.chat_models import init_chat_model
 
 llm = init_chat_model("anthropic:claude-3-5-sonnet-latest")
 ```
+:::
+
+:::js
+```typescript
+import { initChatModel } from "langchain/chat_models/init";
+
+const llm = initChatModel("anthropic:claude-3-5-sonnet-latest");
+```
+:::
 -->
 
+:::python
 ```python
 from typing import Annotated
 
@@ -63,11 +80,62 @@ graph_builder.add_edge(START, "chatbot")
 memory = MemorySaver()
 graph = graph_builder.compile(checkpointer=memory)
 ```
+:::
+
+:::js
+```typescript
+import { TavilySearchResults } from "@langchain/community/tools/tavily_search";
+import { ChatAnthropic } from "@langchain/anthropic";
+import { BaseMessage } from "@langchain/core/messages";
+import { Annotation, StateGraph, START, END } from "@langchain/langgraph";
+import { MemorySaver } from "@langchain/langgraph";
+import { ToolNode } from "@langchain/langgraph/prebuilt";
+import { messagesStateReducer } from "@langchain/langgraph";
+
+const StateAnnotation = Annotation.Root({
+  messages: Annotation<BaseMessage[]>({
+    reducer: messagesStateReducer,
+  }),
+});
+
+const graphBuilder = new StateGraph(StateAnnotation);
+
+const tool = new TavilySearchResults({ maxResults: 2 });
+const tools = [tool];
+const llm = new ChatAnthropic({ model: "claude-3-5-sonnet-latest" });
+const llmWithTools = llm.bindTools(tools);
+
+const chatbot = async (state: typeof StateAnnotation.State) => {
+  return { messages: [await llmWithTools.invoke(state.messages)] };
+};
+
+graphBuilder.addNode("chatbot", chatbot);
+
+const toolNode = new ToolNode(tools);
+graphBuilder.addNode("tools", toolNode);
+
+const toolsCondition = (state: typeof StateAnnotation.State) => {
+  const lastMessage = state.messages[state.messages.length - 1];
+  if ("tool_calls" in lastMessage && lastMessage.tool_calls?.length) {
+    return "tools";
+  }
+  return END;
+};
+
+graphBuilder.addConditionalEdges("chatbot", toolsCondition);
+graphBuilder.addEdge("tools", "chatbot");
+graphBuilder.addEdge(START, "chatbot");
+
+const memory = new MemorySaver();
+const graph = graphBuilder.compile({ checkpointer: memory });
+```
+:::
 
 ## 2. Add steps
 
 Add steps to your graph. Every step will be checkpointed in its state history:
 
+:::python
 ``` python
 config = {"configurable": {"thread_id": "1"}}
 events = graph.stream(
@@ -89,6 +157,42 @@ for event in events:
     if "messages" in event:
         event["messages"][-1].pretty_print()
 ```
+:::
+
+:::js
+```typescript
+const config = { configurable: { thread_id: "1" } };
+const events = await graph.stream(
+  {
+    messages: [
+      {
+        role: "user",
+        content: (
+          "I'm learning LangGraph. " +
+          "Could you do some research on it for me?"
+        ),
+      },
+    ],
+  },
+  { ...config, streamMode: "values" }
+);
+
+for await (const event of events) {
+  if ("messages" in event) {
+    const lastMessage = event.messages[event.messages.length - 1];
+    console.log(`================================ ${lastMessage._getType()} Message =================================`);
+    console.log(lastMessage.content);
+    if ("tool_calls" in lastMessage && lastMessage.tool_calls?.length) {
+      console.log("Tool Calls:");
+      for (const toolCall of lastMessage.tool_calls) {
+        console.log(`  ${toolCall.name} (${toolCall.id})`);
+        console.log(`  Args: ${JSON.stringify(toolCall.args)}`);
+      }
+    }
+  }
+}
+```
+:::
 
 ```
 ================================ Human Message =================================
@@ -123,6 +227,7 @@ Is there any specific aspect of LangGraph you'd like to know more about? I'd be
 Output is truncated. View as a scrollable element or open in a text editor. Adjust cell output settings...
 ```
 
+:::python
 ```python
 events = graph.stream(
     {
@@ -143,6 +248,41 @@ for event in events:
     if "messages" in event:
         event["messages"][-1].pretty_print()
 ```
+:::
+
+:::js
+```typescript
+const events2 = await graph.stream(
+  {
+    messages: [
+      {
+        role: "user",
+        content: (
+          "Ya that's helpful. Maybe I'll " +
+          "build an autonomous agent with it!"
+        ),
+      },
+    ],
+  },
+  { ...config, streamMode: "values" }
+);
+
+for await (const event of events2) {
+  if ("messages" in event) {
+    const lastMessage = event.messages[event.messages.length - 1];
+    console.log(`================================ ${lastMessage._getType()} Message =================================`);
+    console.log(lastMessage.content);
+    if ("tool_calls" in lastMessage && lastMessage.tool_calls?.length) {
+      console.log("Tool Calls:");
+      for (const toolCall of lastMessage.tool_calls) {
+        console.log(`  ${toolCall.name} (${toolCall.id})`);
+        console.log(`  Args: ${JSON.stringify(toolCall.args)}`);
+      }
+    }
+  }
+}
+```
+:::
 
 ```
 ================================ Human Message =================================
@@ -159,7 +299,7 @@ Tool Calls:
 ================================= Tool Message =================================
 Name: tavily_search_results_json
 
-[{"url": "https://towardsdatascience.com/building-autonomous-multi-tool-agents-with-gemini-2-0-and-langgraph-ad3d7bd5e79d", "content": "Building Autonomous Multi-Tool Agents with Gemini 2.0 and LangGraph | by Youness Mansar | Jan, 2025 | Towards Data Science Building Autonomous Multi-Tool Agents with Gemini 2.0 and LangGraph A practical tutorial with full code examples for building and running multi-tool agents Towards Data Science LLMs are remarkable — they can memorize vast amounts of information, answer general knowledge questions, write code, generate stories, and even fix your grammar. In this tutorial, we are going to build a simple LLM agent that is equipped with four tools that it can use to answer a user’s question. This Agent will have the following specifications: Follow Published in Towards Data Science --------------------------------- Your home for data science and AI. Follow Follow Follow"}, {"url": "https://github.com/anmolaman20/Tools_and_Agents", "content": "GitHub - anmolaman20/Tools_and_Agents: This repository provides resources for building AI agents using Langchain and Langgraph. This repository provides resources for building AI agents using Langchain and Langgraph. This repository provides resources for building AI agents using Langchain and Langgraph. This repository serves as a comprehensive guide for building AI-powered agents using Langchain and Langgraph. It provides hands-on examples, practical tutorials, and resources for developers and AI enthusiasts to master building intelligent systems and workflows. AI Agent Development: Gain insights into creating intelligent systems that think, reason, and adapt in real time. This repository is ideal for AI practitioners, developers exploring language models, or anyone interested in building intelligent systems. This repository provides resources for building AI agents using Langchain and Langgraph."}]
+[{"url": "https://towardsdatascience.com/building-autonomous-multi-tool-agents-with-gemini-2-0-and-langgraph-ad3d7bd5e79d", "content": "Building Autonomous Multi-Tool Agents with Gemini 2.0 and LangGraph | by Youness Mansar | Jan, 2025 | Towards Data Science Building Autonomous Multi-Tool Agents with Gemini 2.0 and LangGraph A practical tutorial with full code examples for building and running multi-tool agents Towards Data Science LLMs are remarkable — they can memorize vast amounts of information, answer general knowledge questions, write code, generate stories, and even fix your grammar. In this tutorial, we are going to build a simple LLM agent that is equipped with four tools that it can use to answer a user's question. This Agent will have the following specifications: Follow Published in Towards Data Science --------------------------------- Your home for data science and AI. Follow Follow Follow"}, {"url": "https://github.com/anmolaman20/Tools_and_Agents", "content": "GitHub - anmolaman20/Tools_and_Agents: This repository provides resources for building AI agents using Langchain and Langgraph. This repository provides resources for building AI agents using Langchain and Langgraph. This repository provides resources for building AI agents using Langchain and Langgraph. This repository serves as a comprehensive guide for building AI-powered agents using Langchain and Langgraph. It provides hands-on examples, practical tutorials, and resources for developers and AI enthusiasts to master building intelligent systems and workflows. AI Agent Development: Gain insights into creating intelligent systems that think, reason, and adapt in real time. This repository is ideal for AI practitioners, developers exploring language models, or anyone interested in building intelligent systems. This repository provides resources for building AI agents using Langchain and Langgraph."}]
 ================================== Ai Message ==================================
 
 Great idea! Building an autonomous agent with LangGraph is definitely an exciting project. Based on the latest information I've found, here are some insights and tips for building autonomous agents with LangGraph:
@@ -181,6 +321,7 @@ Output is truncated. View as a scrollable element or open in a text editor. Adju
 
 Now that you have added steps to the chatbot, you can `replay` the full state history to see everything that occurred.
 
+:::python
 ``` python
 to_replay = None
 for state in graph.get_state_history(config):
@@ -190,7 +331,24 @@ for state in graph.get_state_history(config):
         # We are somewhat arbitrarily selecting a specific state based on the number of chat messages in the state.
         to_replay = state
 ```
+:::
 
+:::js
+```typescript
+let toReplay = null;
+const stateHistory = await graph.getStateHistory(config);
+for await (const state of stateHistory) {
+  console.log("Num Messages: ", state.values.messages.length, "Next: ", state.next);
+  console.log("-".repeat(80));
+  if (state.values.messages.length === 6) {
+    // We are somewhat arbitrarily selecting a specific state based on the number of chat messages in the state.
+    toReplay = state;
+  }
+}
+```
+:::
+
+:::python
 ```
 Num Messages:  8 Next:  ()
 --------------------------------------------------------------------------------
@@ -213,6 +371,32 @@ Num Messages:  1 Next:  ('chatbot',)
 Num Messages:  0 Next:  ('__start__',)
 --------------------------------------------------------------------------------
 ```
+:::
+
+:::js
+```
+Num Messages:  8 Next:  []
+--------------------------------------------------------------------------------
+Num Messages:  7 Next:  ["chatbot"]
+--------------------------------------------------------------------------------
+Num Messages:  6 Next:  ["tools"]
+--------------------------------------------------------------------------------
+Num Messages:  5 Next:  ["chatbot"]
+--------------------------------------------------------------------------------
+Num Messages:  4 Next:  ["__start__"]
+--------------------------------------------------------------------------------
+Num Messages:  4 Next:  []
+--------------------------------------------------------------------------------
+Num Messages:  3 Next:  ["chatbot"]
+--------------------------------------------------------------------------------
+Num Messages:  2 Next:  ["tools"]
+--------------------------------------------------------------------------------
+Num Messages:  1 Next:  ["chatbot"]
+--------------------------------------------------------------------------------
+Num Messages:  0 Next:  ["__start__"]
+--------------------------------------------------------------------------------
+```
+:::
 
 Checkpoints are saved for every step of the graph. This __spans invocations__ so you can rewind across a full thread's history.
 
@@ -220,27 +404,74 @@ Checkpoints are saved for every step of the graph. This __spans invocations__ so
 
 Resume from the `to_replay` state, which is after the `chatbot` node in the second graph invocation. Resuming from this point will call the **action** node next.
 
+:::python
 ```python
 print(to_replay.next)
 print(to_replay.config)
 ```
+:::
 
+:::js
+```typescript
+console.log(toReplay.next);
+console.log(toReplay.config);
+```
+:::
+
+:::python
 ```
 ('tools',)
 {'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1efd43e3-0c1f-6c4e-8006-891877d65740'}}
 ```
+:::
+
+:::js
+```
+["tools"]
+{
+  "configurable": {
+    "thread_id": "1",
+    "checkpoint_ns": "",
+    "checkpoint_id": "1efd43e3-0c1f-6c4e-8006-891877d65740"
+  }
+}
+```
+:::
 
 ## 4. Load a state from a moment-in-time
 
 The checkpoint's `to_replay.config` contains a `checkpoint_id` timestamp. Providing this `checkpoint_id` value tells LangGraph's checkpointer to **load** the state from that moment in time.
 
-
+:::python
 ``` python
 # The `checkpoint_id` in the `to_replay.config` corresponds to a state we've persisted to our checkpointer.
 for event in graph.stream(None, to_replay.config, stream_mode="values"):
     if "messages" in event:
         event["messages"][-1].pretty_print()
 ```
+:::
+
+:::js
+```typescript
+// The `checkpoint_id` in the `toReplay.config` corresponds to a state we've persisted to our checkpointer.
+const timeTravel = await graph.stream(null, { ...toReplay.config, streamMode: "values" });
+
+for await (const event of timeTravel) {
+  if ("messages" in event) {
+    const lastMessage = event.messages[event.messages.length - 1];
+    console.log(`================================ ${lastMessage._getType()} Message =================================`);
+    console.log(lastMessage.content);
+    if ("tool_calls" in lastMessage && lastMessage.tool_calls?.length) {
+      console.log("Tool Calls:");
+      for (const toolCall of lastMessage.tool_calls) {
+        console.log(`  ${toolCall.name} (${toolCall.id})`);
+        console.log(`  Args: ${JSON.stringify(toolCall.args)}`);
+      }
+    }
+  }
+}
+```
+:::
 
 ```
 ================================== Ai Message ==================================
@@ -254,7 +485,7 @@ Tool Calls:
 ================================= Tool Message =================================
 Name: tavily_search_results_json
 
-[{"url": "https://towardsdatascience.com/building-autonomous-multi-tool-agents-with-gemini-2-0-and-langgraph-ad3d7bd5e79d", "content": "Building Autonomous Multi-Tool Agents with Gemini 2.0 and LangGraph | by Youness Mansar | Jan, 2025 | Towards Data Science Building Autonomous Multi-Tool Agents with Gemini 2.0 and LangGraph A practical tutorial with full code examples for building and running multi-tool agents Towards Data Science LLMs are remarkable — they can memorize vast amounts of information, answer general knowledge questions, write code, generate stories, and even fix your grammar. In this tutorial, we are going to build a simple LLM agent that is equipped with four tools that it can use to answer a user’s question. This Agent will have the following specifications: Follow Published in Towards Data Science --------------------------------- Your home for data science and AI. Follow Follow Follow"}, {"url": "https://github.com/anmolaman20/Tools_and_Agents", "content": "GitHub - anmolaman20/Tools_and_Agents: This repository provides resources for building AI agents using Langchain and Langgraph. This repository provides resources for building AI agents using Langchain and Langgraph. This repository provides resources for building AI agents using Langchain and Langgraph. This repository serves as a comprehensive guide for building AI-powered agents using Langchain and Langgraph. It provides hands-on examples, practical tutorials, and resources for developers and AI enthusiasts to master building intelligent systems and workflows. AI Agent Development: Gain insights into creating intelligent systems that think, reason, and adapt in real time. This repository is ideal for AI practitioners, developers exploring language models, or anyone interested in building intelligent systems. This repository provides resources for building AI agents using Langchain and Langgraph."}]
+[{"url": "https://towardsdatascience.com/building-autonomous-multi-tool-agents-with-gemini-2-0-and-langgraph-ad3d7bd5e79d", "content": "Building Autonomous Multi-Tool Agents with Gemini 2.0 and LangGraph | by Youness Mansar | Jan, 2025 | Towards Data Science Building Autonomous Multi-Tool Agents with Gemini 2.0 and LangGraph A practical tutorial with full code examples for building and running multi-tool agents Towards Data Science LLMs are remarkable — they can memorize vast amounts of information, answer general knowledge questions, write code, generate stories, and even fix your grammar. In this tutorial, we are going to build a simple LLM agent that is equipped with four tools that it can use to answer a user's question. This Agent will have the following specifications: Follow Published in Towards Data Science --------------------------------- Your home for data science and AI. Follow Follow Follow"}, {"url": "https://github.com/anmolaman20/Tools_and_Agents", "content": "GitHub - anmolaman20/Tools_and_Agents: This repository provides resources for building AI agents using Langchain and Langgraph. This repository provides resources for building AI agents using Langchain and Langgraph. This repository provides resources for building AI agents using Langchain and Langgraph. This repository serves as a comprehensive guide for building AI-powered agents using Langchain and Langgraph. It provides hands-on examples, practical tutorials, and resources for developers and AI enthusiasts to master building intelligent systems and workflows. AI Agent Development: Gain insights into creating intelligent systems that think, reason, and adapt in real time. This repository is ideal for AI practitioners, developers exploring language models, or anyone interested in building intelligent systems. This repository provides resources for building AI agents using Langchain and Langgraph."}]
 ================================== Ai Message ==================================
 
 Great idea! Building an autonomous agent with LangGraph is indeed an excellent way to apply and deepen your understanding of the technology. Based on the search results, I can provide you with some insights and resources to help you get started:

docs/docs/tutorials/langgraph-platform/local-server.md

@@ -1,4 +1,4 @@
-# Run a local server
+# LangGraph Platform quickstart
 
 This guide shows you how to run a LangGraph application locally.
 

docs/docs/tutorials/rag/langgraph_adaptive_rag.ipynb

@@ -336,8 +336,7 @@
     "rag_chain = prompt | llm | StrOutputParser()\n",
     "\n",
     "# Run\n",
-    "docs_txt = format_docs(docs)\n",
-    "generation = rag_chain.invoke({\"context\": docs_txt, \"question\": question})\n",
+    "generation = rag_chain.invoke({\"context\": docs, \"question\": question})\n",
     "print(generation)"
    ]
   },
@@ -626,8 +625,7 @@
     "    documents = state[\"documents\"]\n",
     "\n",
     "    # RAG generation\n",
-    "    docs_txt = format_docs(documents)\n",
-    "    generation = rag_chain.invoke({\"context\": docs_txt, \"question\": question})\n",
+    "    generation = rag_chain.invoke({\"context\": documents, \"question\": question})\n",
     "    return {\"documents\": documents, \"question\": question, \"generation\": generation}\n",
     "\n",
     "\n",

docs/docs/tutorials/workflows.md

@@ -648,7 +648,7 @@ With orchestrator-worker, an orchestrator breaks down a task and delegates each
     Because orchestrator-worker workflows are common, LangGraph **has the `Send` API to support this**. It lets you dynamically create worker nodes and send each one a specific input. Each worker has its own state, and all worker outputs are written to a *shared state key* that is accessible to the orchestrator graph. This gives the orchestrator access to all worker output and allows it to synthesize them into a final output. As you can see below, we iterate over a list of sections and `Send` each to a worker node. See further documentation [here](https://langchain-ai.github.io/langgraph/how-tos/map-reduce/) and [here](https://langchain-ai.github.io/langgraph/concepts/low_level/#send).
 
     ```python
-    from langgraph.types import Send
+    from langgraph.constants import Send
 
 
     # Graph state

docs/mkdocs.yml

@@ -89,154 +89,162 @@ plugins:
                 - "!^_"
 
 nav:
-  - Get started:
-    - index.md
-    - Quickstarts:
-      - Start with a prebuilt agent: agents/agents.md
-      - Build a custom workflow:
-          -  concepts/why-langgraph.md
-          -  1. Build a basic chatbot: tutorials/get-started/1-build-basic-chatbot.md
-          -  2. Add tools: tutorials/get-started/2-add-tools.md
-          -  3. Add memory: tutorials/get-started/3-add-memory.md
-          -  4. Add human-in-the-loop: tutorials/get-started/4-human-in-the-loop.md
-          -  5. Customize state: tutorials/get-started/5-customize-state.md
-          -  6. Time travel: tutorials/get-started/6-time-travel.md
-      - Run a local server: tutorials/langgraph-platform/local-server.md
-    - Agent development:
-      - Workflows & agents: tutorials/workflows.md
-      - Prebuilt components: agents/overview.md
-      - Run an agent: agents/run_agents.md
-      - Agent architectures: concepts/agentic_concepts.md
-
   - Guides:
-    - LangGraph APIs:
-      - Graph API:
-          - Overview: concepts/low_level.md
-          - Use the Graph API: how-tos/graph-api.ipynb
-      - Functional API:
-          - Overview: concepts/functional_api.md
-          - Use the Functional API: how-tos/use-functional-api.md
-      - Runtime: concepts/pregel.md
-    - Core capabilities:
+    - index.md
+    - Get started:
+      - Quickstart: agents/agents.md
+      - LangGraph basics:
+        -  concepts/why-langgraph.md
+        -  Build a basic chatbot: tutorials/get-started/1-build-basic-chatbot.md
+        -  tutorials/get-started/2-add-tools.md
+        -  tutorials/get-started/3-add-memory.md
+        -  Add human-in-the-loop: tutorials/get-started/4-human-in-the-loop.md
+        -  tutorials/get-started/5-customize-state.md
+        -  tutorials/get-started/6-time-travel.md
+      - Deployment: tutorials/deployment.md
+    - Prebuilt agents:
+      - Overview: agents/overview.md
+      - agents/run_agents.md
+      - agents/streaming.md
+      - agents/models.md
+      - agents/tools.md
+      - agents/mcp.md
+      - agents/context.md
+      - agents/memory.md
+      - agents/human-in-the-loop.md
+      - agents/multi-agent.md
+      - agents/evals.md
+      - agents/deployment.md
+      - agents/ui.md
+    - LangGraph framework:
+      - Agent architectures:
+        - Overview: concepts/agentic_concepts.md
+        - Workflows & agents: tutorials/workflows.md
+      - Graphs:
+        - Overview: concepts/low_level.md
+        - Runtime overview: concepts/pregel.md
+        - Use the Graph API: how-tos/graph-api.ipynb
       - Streaming:
           - Overview: concepts/streaming.md
-          - Stream outputs: how-tos/streaming.md
-          - Use Server API: cloud/how-tos/streaming.md
+          - "Stream outputs": how-tos/streaming.md
       - Persistence:
-          - Overview: concepts/persistence.md
-      - Durable execution:
-          - Overview: concepts/durable_execution.md
+        - Overview: concepts/persistence.md
+        - concepts/durable_execution.md
+        - how-tos/persistence.ipynb
       - Memory:
-          - Overview: concepts/memory.md
-          - Add memory: how-tos/memory/add-memory.md
-      - Context:
-          - Add context: agents/context.md
-      - Models:
-          - Configure model: agents/models.md
-      - Tools:
-          - Overview: concepts/tools.md
-          - Call tools: how-tos/tool-calling.md
+        - Overview: concepts/memory.md
+        - Manage memory: how-tos/memory.ipynb
       - Human-in-the-loop:
-          - Overview: concepts/human_in_the_loop.md
-          - Add human intervention: how-tos/human_in_the_loop/add-human-in-the-loop.md
-          - Use Server API: cloud/how-tos/add-human-in-the-loop.md
+        - Overview: concepts/human_in_the_loop.md
+        - how-tos/human_in_the_loop/add-human-in-the-loop.md
       - Breakpoints:
-          - Overview: concepts/breakpoints.md
-          - Set breakpoints: how-tos/human_in_the_loop/breakpoints.md
-          - Use Server API: cloud/how-tos/human_in_the_loop_breakpoint.md
+        - Overview: concepts/breakpoints.md
+        - how-tos/human_in_the_loop/breakpoints.ipynb
       - Time travel:
-          - Overview: concepts/time-travel.md
-          - Use time travel: how-tos/human_in_the_loop/time-travel.md
-          - Use Server API: cloud/how-tos/human_in_the_loop_time_travel.md
+        - Overview: concepts/time-travel.md
+        - how-tos/human_in_the_loop/time-travel.ipynb
+      - Tools:
+        - Overview: concepts/tools.md
+        - how-tos/tool-calling.ipynb
       - Subgraphs:
-          - Overview: concepts/subgraphs.md
-          - Use subgraphs: how-tos/subgraph.ipynb
+        - Overview: concepts/subgraphs.md
+        - how-tos/subgraph.ipynb
       - Multi-agent:
-          - Overview: concepts/multi_agent.md
-          - Prebuilt implementation: agents/multi-agent.md
-          - Custom implementation: how-tos/multi_agent.ipynb
-      - MCP:
-          - Use MCP: agents/mcp.md
-          - Server API: concepts/server-mcp.md
-      - Evaluation:
-          - Basic implementation: agents/evals.md
-    - Platform-only capabilities:
-      - LangGraph Platform:
-          - Overview: concepts/langgraph_platform.md
-          - Components:
-            - Overview: concepts/langgraph_components.md
-            - LangGraph Server:
-              - Overview: concepts/langgraph_server.md
-              - Data plane: concepts/langgraph_data_plane.md
-              - Control plane: concepts/langgraph_control_plane.md
-            - LangGraph CLI: concepts/langgraph_cli.md
-            - LangGraph Studio: 
-              - Overview: concepts/langgraph_studio.md
-              - Quickstart: cloud/how-tos/studio/quick_start.md
-              - cloud/how-tos/invoke_studio.md
-              - cloud/how-tos/studio/manage_assistants.md
-              - cloud/how-tos/threads_studio.md
-              - cloud/how-tos/iterate_graph_studio.md
-              - cloud/how-tos/studio/run_evals.md
-              - cloud/how-tos/clone_traces_studio.md
-              - cloud/how-tos/datasets_studio.md
-            - LangGraph SDK: concepts/sdk.md
-          - Plans & pricing: concepts/plans.md
-          - Application structure: concepts/application_structure.md
-          - Scalability & resilience: concepts/scalability_and_resilience.md
-      - Authentication & access control:
-          - Overview: concepts/auth.md
-          - how-tos/auth/custom_auth.md
-          - how-tos/auth/openapi_security.md
-      - Assistants:
-          - Overview: concepts/assistants.md
-          - cloud/how-tos/configuration_cloud.md
-          - Threads: cloud/how-tos/use_threads.md
-          - Runs:
-            - cloud/how-tos/background_run.md
-            - cloud/how-tos/same-thread.md
-            - cloud/how-tos/cron_jobs.md
-            - cloud/how-tos/stateless_runs.md
-            - cloud/how-tos/configurable_headers.md
-      - Double-texting: 
-          - Overview: concepts/double_texting.md
-          - cloud/how-tos/interrupt_concurrent.md
-          - cloud/how-tos/rollback_concurrent.md
-          - cloud/how-tos/reject_concurrent.md
-          - cloud/how-tos/enqueue_concurrent.md
-      - Webhooks:
-          - Overview: cloud/concepts/webhooks.md
-          - Use webhooks: cloud/how-tos/webhooks.md
-      - Cron jobs:
-          - Overview: cloud/concepts/cron_jobs.md
-          - cloud/how-tos/cron_jobs.md
-      - Server customization:
-          - how-tos/http/custom_lifespan.md
-          - how-tos/http/custom_middleware.md
-          - how-tos/http/custom_routes.md
+        - Overview: concepts/multi_agent.md
+        - how-tos/multi_agent.ipynb
+      - Functional API:
+        - Overview: concepts/functional_api.md
+        - how-tos/use-functional-api.md
+
+    - LangGraph Platform:
+      - Overview: concepts/langgraph_platform.md
+      - Get started:
+        - Quickstart: tutorials/langgraph-platform/local-server.md
+        - Deployment quickstart: cloud/quick_start.md
+      - Components:
+        - Overview: concepts/langgraph_components.md
+        - LangGraph Server:
+          - Overview: concepts/langgraph_server.md
+          - Application structure:
+            - Overview: concepts/application_structure.md
+            - cloud/deployment/setup.md
+            - cloud/deployment/setup_pyproject.md
+            - cloud/deployment/setup_javascript.md
+            - cloud/deployment/custom_docker.md
+        - LangGraph CLI: concepts/langgraph_cli.md
+        - LangGraph Studio:
+          - Overview: concepts/langgraph_studio.md
+          - Quickstart: cloud/how-tos/studio/quick_start.md
+          - cloud/how-tos/invoke_studio.md
+          - cloud/how-tos/studio/manage_assistants.md
+          - cloud/how-tos/threads_studio.md
+          - cloud/how-tos/iterate_graph_studio.md
+          - cloud/how-tos/clone_traces_studio.md
+          - cloud/how-tos/datasets_studio.md
+        - LangGraph SDK: concepts/sdk.md
       - Data management:
         - Add semantic search: cloud/deployment/semantic_search.md
         - Add TTLs: how-tos/ttl/configure_ttl.md
+      - Authentication & access control:
+        - Overview: concepts/auth.md
+        - how-tos/auth/custom_auth.md
+        - how-tos/auth/openapi_security.md
+      - Assistants:
+        - Overview: concepts/assistants.md
+        - cloud/how-tos/configuration_cloud.md
+      - Threads:
+        - Overview: cloud/concepts/threads.md
+        - cloud/how-tos/use_threads.md
+      - Runs:
+        - Overview: cloud/concepts/runs.md
+        - cloud/how-tos/background_run.md
+        - cloud/how-tos/same-thread.md
+        - cloud/how-tos/cron_jobs.md
+        - cloud/how-tos/stateless_runs.md
+        - cloud/how-tos/configurable_headers.md
+      - Streaming:
+        - Overview: cloud/concepts/streaming.md
+        - cloud/how-tos/streaming.md
+      - Human-in-the-loop: cloud/how-tos/add-human-in-the-loop.md
+      - Breakpoints: cloud/how-tos/human_in_the_loop_breakpoint.md
+      - Time travel: cloud/how-tos/human_in_the_loop_time_travel.md
+      - MCP: concepts/server-mcp.md
+      - Double-texting:
+        - Overview: concepts/double_texting.md
+        - cloud/how-tos/interrupt_concurrent.md
+        - cloud/how-tos/rollback_concurrent.md
+        - cloud/how-tos/reject_concurrent.md
+        - cloud/how-tos/enqueue_concurrent.md
+      - Webhooks:
+        - Overview: cloud/concepts/webhooks.md
+        - cloud/how-tos/webhooks.md
+      - Cron jobs:
+        - Overview: cloud/concepts/cron_jobs.md
+        - cloud/how-tos/cron_jobs.md
+      - Server customization:
+        - how-tos/http/custom_lifespan.md
+        - how-tos/http/custom_middleware.md
+        - how-tos/http/custom_routes.md
       - Deployment:
-          - Overview: concepts/deployment_options.md
-          - Quickstart: cloud/quick_start.md
-          - Set up your application:
-            - Use requirements.txt: cloud/deployment/setup.md
-            - Use pyproject.toml: cloud/deployment/setup_pyproject.md
-            - Use JavaScript: cloud/deployment/setup_javascript.md
-            - Use custom Docker: cloud/deployment/custom_docker.md
-            - Rebuild graph at runtime: cloud/deployment/graph_rebuild.md
-          - Deployment options:
-            - Cloud SaaS: concepts/langgraph_cloud.md
-            - Self-Hosted Data Plane: concepts/langgraph_self_hosted_data_plane.md
-            - Self-Hosted Control Plane: concepts/langgraph_self_hosted_control_plane.md
-            - Standalone Container: concepts/langgraph_standalone_container.md
-          - Deploy to production:
-            - Cloud SaaS: cloud/deployment/cloud.md
-            - Self-Hosted Data Plane: cloud/deployment/self_hosted_data_plane.md
-            - Self-Hosted Control Plane: cloud/deployment/self_hosted_control_plane.md
-            - Standalone Container: cloud/deployment/standalone_container.md
-
+        - Overview: concepts/deployment_options.md
+        - Data plane: concepts/langgraph_data_plane.md
+        - Control plane: concepts/langgraph_control_plane.md
+        - Deployment options:
+          - Cloud SaaS:
+            - Overview: concepts/langgraph_cloud.md
+            - Deploy Cloud SaaS: cloud/deployment/cloud.md
+          - Self-Hosted Data Plane:
+            - Overview: concepts/langgraph_self_hosted_data_plane.md
+            - Deploy Self-Hosted Data Plane: cloud/deployment/self_hosted_data_plane.md
+          - Self-Hosted Control Plane:
+            - Overview: concepts/langgraph_self_hosted_control_plane.md
+            - Deploy Self-Hosted Control Plane: cloud/deployment/self_hosted_control_plane.md
+          - Standalone Container:
+            - Overview: concepts/langgraph_standalone_container.md
+            - Deploy Standalone Container: cloud/deployment/standalone_container.md
+        - Scalability & resilience: concepts/scalability_and_resilience.md
+        - Plans & pricing: concepts/plans.md
+      
   - Reference:
     - reference/index.md
     - LangGraph:
@@ -265,17 +273,16 @@ nav:
       - Environment variables: cloud/reference/env_var.md
 
   - Examples:
-    - Template applications: concepts/template_applications.md  # TODO: make tutorial
     - Agentic RAG: tutorials/rag/langgraph_agentic_rag.ipynb
     - Agent Supervisor: tutorials/multi_agent/agent_supervisor.ipynb
     - SQL agent: tutorials/sql-agent.ipynb
-    - Prebuilt chat UI: agents/ui.md
     - Graph runs in LangSmith: how-tos/run-id-langsmith.ipynb
     - LangGraph Platform:
       - Authentication:
         - tutorials/auth/getting_started.md
         - tutorials/auth/resource_auth.md
         - tutorials/auth/add_auth_server.md
+      - Rebuild graph at runtime: cloud/deployment/graph_rebuild.md
       - Use RemoteGraph: how-tos/use-remote-graph.md
       - Deploy CrewAI, AutoGen, and other frameworks: how-tos/autogen-langgraph-platform.ipynb
         # combine with how-tos/autogen-integration.ipynb
@@ -283,12 +290,11 @@ nav:
         - Integrate LangGraph into a React app: cloud/how-tos/use_stream_react.md
         - Implement generative UI with LangGraph: cloud/how-tos/generative_ui_react.md
 
-  - Additional resources:
-    - agents/prebuilt.md # NOTE: prebuilt.md is auto-generated by `make build-prebuilt`
-    - LangGraph Academy course: https://academy.langchain.com/courses/intro-to-langgraph
-    - Case studies: adopters.md
+  - Resources:
     - concepts/faq.md
+    - Template applications: concepts/template_applications.md  # TODO: make tutorial
     - llms.txt: llms-txt-overview.md
+    - agents/prebuilt.md # NOTE: prebuilt.md is auto-generated by `make build-prebuilt`
     - Troubleshooting:
         - Errors:
           - troubleshooting/errors/index.md
@@ -299,7 +305,9 @@ nav:
           - troubleshooting/errors/INVALID_CHAT_HISTORY.md
           - troubleshooting/errors/INVALID_LICENSE.md
         - LangGraph Studio: troubleshooting/studio.md
-    
+    - Learn:
+      - LangGraph Academy course: https://academy.langchain.com/courses/intro-to-langgraph
+      - Case studies: adopters.md
 
 markdown_extensions:
   - abbr
@@ -356,6 +364,16 @@ markdown_extensions:
 hooks:
   - _scripts/notebook_hooks.py
 extra:
+  consent:
+    title: Cookie consent
+    actions:
+      - accept
+      - reject
+    description: >- 
+      We use cookies to recognize your repeated visits and preferences, as well
+      as to measure the effectiveness of our documentation and whether users
+      find what they're searching for. <strong>Clicking "Accept" makes our
+      documentation better. Thank you!</strong> ❤️
   social:
     - icon: fontawesome/brands/js
       link: https://langchain-ai.github.io/langgraphjs/
@@ -380,4 +398,6 @@ extra_css:
   - stylesheets/logos.css
   - stylesheets/sticky_navigation.css
   - stylesheets/agent_graph_widget.css
-
+  - language-switcher.css
+extra_javascript:
+  - language-switcher.js

docs/overrides/partials/header.html

@@ -0,0 +1,70 @@
+{#-
+  This file was automatically generated - do not edit
+-#}
+{% set class = "md-header" %}
+{% if "navigation.tabs.sticky" in features %}
+  {% set class = class ~ " md-header--shadow md-header--lifted" %}
+{% elif "navigation.tabs" not in features %}
+  {% set class = class ~ " md-header--shadow" %}
+{% endif %}
+<header class="{{ class }}" data-md-component="header">
+  <nav class="md-header__inner md-grid" aria-label="{{ lang.t('header') }}">
+    <a href="{{ config.extra.homepage | d(nav.homepage.url, true) | url }}" title="{{ config.site_name | e }}" class="md-header__button md-logo" aria-label="{{ config.site_name }}" data-md-component="logo">
+      {% include "partials/logo.html" %}
+    </a>
+    <label class="md-header__button md-icon" for="__drawer">
+      {% set icon = config.theme.icon.menu or "material/menu" %}
+      {% include ".icons/" ~ icon ~ ".svg" %}
+    </label>
+    <div class="md-header__title" data-md-component="header-title">
+      <div class="md-header__ellipsis">
+        <div class="md-header__topic">
+          <span class="md-ellipsis">
+            {{ config.site_name }}
+          </span>
+        </div>
+        <div class="md-header__topic" data-md-component="header-topic">
+          <span class="md-ellipsis">
+            {% if page.meta and page.meta.title %}
+              {{ page.meta.title }}
+            {% else %}
+              {{ page.title }}
+            {% endif %}
+          </span>
+        </div>
+      </div>
+    </div>
+    {% if config.theme.palette %}
+      {% if not config.theme.palette is mapping %}
+        {% include "partials/palette.html" %}
+      {% endif %}
+    {% endif %}
+    {% if not config.theme.palette is mapping %}
+      {% include "partials/javascripts/palette.html" %}
+    {% endif %}
+    {% if config.extra.alternate %}
+      {% include "partials/alternate.html" %}
+    {% endif %}
+    {% if "material/search" in config.plugins %}
+      {% set search = config.plugins["material/search"] | attr("config") %}
+      {% if search.enabled %}
+        <label class="md-header__button md-icon" for="__search">
+          {% set icon = config.theme.icon.search or "material/magnify" %}
+          {% include ".icons/" ~ icon ~ ".svg" %}
+        </label>
+        {% include "partials/search.html" %}
+      {% endif %}
+    {% endif %}
+    {% if config.repo_url %}
+      <div class="md-header__source">
+        {% include "partials/source.html" %}
+      </div>
+    {% endif %}
+    {% include "partials/language-toggle.html" %}
+  </nav>
+  {% if "navigation.tabs.sticky" in features %}
+    {% if "navigation.tabs" in features %}
+      {% include "partials/tabs.html" %}
+    {% endif %}
+  {% endif %}
+</header>

docs/snippets/chat_model_tabs.md

@@ -1,6 +1,6 @@
 === "OpenAI"
 
-    ```shell
+    ```
     pip install -U "langchain[openai]"
     ```
     ```python
@@ -12,11 +12,9 @@
     llm = init_chat_model("openai:gpt-4.1")
     ```
 
-    👉 Read the [OpenAI integration docs](https://python.langchain.com/docs/integrations/chat/openai/)
-
 === "Anthropic"
 
-    ```shell
+    ```
     pip install -U "langchain[anthropic]"
     ```
     ```python
@@ -28,11 +26,9 @@
     llm = init_chat_model("anthropic:claude-3-5-sonnet-latest")
     ```
 
-    👉 Read the [Anthropic integration docs](https://python.langchain.com/docs/integrations/chat/anthropic/)
-
 === "Azure"
 
-    ```shell
+    ```
     pip install -U "langchain[openai]"
     ```
     ```python
@@ -48,12 +44,10 @@
         azure_deployment=os.environ["AZURE_OPENAI_DEPLOYMENT_NAME"],
     )
     ```
- 
-    👉 Read the [Azure integration docs](https://python.langchain.com/docs/integrations/chat/azure_chat_openai/)
 
 === "Google Gemini"
 
-    ```shell
+    ```
     pip install -U "langchain[google-genai]"
     ```
     ```python
@@ -65,11 +59,9 @@
     llm = init_chat_model("google_genai:gemini-2.0-flash")
     ```
 
-    👉 Read the [Google GenAI integration docs](https://python.langchain.com/docs/integrations/chat/google_generative_ai/)
-
 === "AWS Bedrock"
 
-    ```shell
+    ```
     pip install -U "langchain[aws]"
     ```
     ```python
@@ -83,5 +75,3 @@
         model_provider="bedrock_converse",
     )
     ```
-
-    👉 Read the [AWS Bedrock integration docs](https://python.langchain.com/docs/integrations/chat/bedrock/)

docs/uv.lock

@@ -2590,7 +2590,7 @@ wheels = [
 
 [[package]]
 name = "langgraph"
-version = "0.5.0"
+version = "0.4.7"
 source = { editable = "../libs/langgraph" }
 dependencies = [
     { name = "langchain-core" },
@@ -2641,7 +2641,7 @@ dev = [
 
 [[package]]
 name = "langgraph-checkpoint"
-version = "2.1.0"
+version = "2.0.26"
 source = { editable = "../libs/checkpoint" }
 dependencies = [
     { name = "langchain-core" },
@@ -2660,8 +2660,6 @@ dev = [
     { name = "dataclasses-json" },
     { name = "mypy" },
     { name = "numpy" },
-    { name = "pandas" },
-    { name = "pandas-stubs", specifier = ">=2.2.2.240807" },
     { name = "pytest" },
     { name = "pytest-asyncio" },
     { name = "pytest-mock" },
@@ -2894,7 +2892,7 @@ test = [
 
 [[package]]
 name = "langgraph-prebuilt"
-version = "0.5.1"
+version = "0.2.2"
 source = { editable = "../libs/prebuilt" }
 dependencies = [
     { name = "langchain-core" },
@@ -2925,7 +2923,7 @@ dev = [
 
 [[package]]
 name = "langgraph-sdk"
-version = "0.1.72"
+version = "0.1.70"
 source = { editable = "../libs/sdk-py" }
 dependencies = [
     { name = "httpx" },

examples/human_in_the_loop/breakpoints.ipynb

@@ -1 +1,33 @@
- 
+{
+ "cells": [
+  {
+   "cell_type": "markdown",
+   "id": "ac22b8de",
+   "metadata": {},
+   "source": [
+    "This file has been moved to https://github.com/langchain-ai/langgraph/blob/main/docs/docs/how-tos/human_in_the_loop/breakpoints.ipynb"
+   ]
+  }
+ ],
+ "metadata": {
+  "kernelspec": {
+   "display_name": "Python 3 (ipykernel)",
+   "language": "python",
+   "name": "python3"
+  },
+  "language_info": {
+   "codemirror_mode": {
+    "name": "ipython",
+    "version": 3
+   },
+   "file_extension": ".py",
+   "mimetype": "text/x-python",
+   "name": "python",
+   "nbconvert_exporter": "python",
+   "pygments_lexer": "ipython3",
+   "version": "3.11.9"
+  }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 5
+}

examples/persistence.ipynb

@@ -5,7 +5,7 @@
    "id": "d16e8b9c",
    "metadata": {},
    "source": [
-    "This file has been moved to https://github.com/langchain-ai/langgraph/blob/main/docs/docs/how-tos/memory/add-memory.md."
+    "This file has been moved to https://github.com/langchain-ai/langgraph/blob/main/docs/docs/how-tos/persistence.ipynb"
    ]
   }
  ],

libs/checkpoint-postgres/langgraph/checkpoint/postgres/__init__.py

@@ -23,7 +23,6 @@ from langgraph.checkpoint.base import (
 )
 from langgraph.checkpoint.postgres import _internal
 from langgraph.checkpoint.postgres.base import BasePostgresSaver
-from langgraph.checkpoint.postgres.shallow import ShallowPostgresSaver
 from langgraph.checkpoint.serde.base import SerializerProtocol
 
 Conn = _internal.Conn  # For backward compatibility
@@ -457,4 +456,4 @@ class PostgresSaver(BasePostgresSaver):
         )
 
 
-__all__ = ["PostgresSaver", "BasePostgresSaver", "ShallowPostgresSaver", "Conn"]
+__all__ = ["PostgresSaver", "BasePostgresSaver", "Conn"]

libs/checkpoint-postgres/langgraph/checkpoint/postgres/aio.py

@@ -23,7 +23,6 @@ from langgraph.checkpoint.base import (
 )
 from langgraph.checkpoint.postgres import _ainternal
 from langgraph.checkpoint.postgres.base import BasePostgresSaver
-from langgraph.checkpoint.postgres.shallow import AsyncShallowPostgresSaver
 from langgraph.checkpoint.serde.base import SerializerProtocol
 
 Conn = _ainternal.Conn  # For backward compatibility
@@ -560,4 +559,4 @@ class AsyncPostgresSaver(BasePostgresSaver):
         ).result()
 
 
-__all__ = ["AsyncPostgresSaver", "AsyncShallowPostgresSaver", "Conn"]
+__all__ = ["AsyncPostgresSaver", "Conn"]

libs/checkpoint-postgres/langgraph/checkpoint/postgres/base.py

@@ -168,7 +168,7 @@ class BasePostgresSaver(BaseCheckpointSaver[str]):
         checkpoint["channel_versions"][TASKS] = (
             max(checkpoint["channel_versions"].values())
             if checkpoint["channel_versions"]
-            else self.get_next_version(None, None)
+            else self.get_next_version(None)
         )
 
     def _load_blobs(
@@ -246,7 +246,7 @@ class BasePostgresSaver(BaseCheckpointSaver[str]):
             for idx, (channel, value) in enumerate(writes)
         ]
 
-    def get_next_version(self, current: str | None, channel: None) -> str:
+    def get_next_version(self, current: str | None) -> str:
         if current is None:
             current_v = 0
         elif isinstance(current, int):

libs/checkpoint-postgres/langgraph/checkpoint/postgres/shallow.py

@@ -1,959 +0,0 @@
-import asyncio
-import threading
-import warnings
-from collections.abc import AsyncIterator, Iterator, Sequence
-from contextlib import asynccontextmanager, contextmanager
-from typing import Any, Optional
-
-from langchain_core.runnables import RunnableConfig
-from psycopg import (
-    AsyncConnection,
-    AsyncCursor,
-    AsyncPipeline,
-    Capabilities,
-    Connection,
-    Cursor,
-    Pipeline,
-)
-from psycopg.rows import DictRow, dict_row
-from psycopg.types.json import Jsonb
-from psycopg_pool import AsyncConnectionPool, ConnectionPool
-
-from langgraph.checkpoint.base import (
-    WRITES_IDX_MAP,
-    ChannelVersions,
-    Checkpoint,
-    CheckpointMetadata,
-    CheckpointTuple,
-    get_checkpoint_metadata,
-)
-from langgraph.checkpoint.postgres import _ainternal, _internal
-from langgraph.checkpoint.postgres.base import BasePostgresSaver
-from langgraph.checkpoint.serde.base import SerializerProtocol
-from langgraph.checkpoint.serde.types import TASKS
-
-"""
-To add a new migration, add a new string to the MIGRATIONS list.
-The position of the migration in the list is the version number.
-"""
-MIGRATIONS = [
-    """CREATE TABLE IF NOT EXISTS checkpoint_migrations (
-    v INTEGER PRIMARY KEY
-);""",
-    """CREATE TABLE IF NOT EXISTS checkpoints (
-    thread_id TEXT NOT NULL,
-    checkpoint_ns TEXT NOT NULL DEFAULT '',
-    type TEXT,
-    checkpoint JSONB NOT NULL,
-    metadata JSONB NOT NULL DEFAULT '{}',
-    PRIMARY KEY (thread_id, checkpoint_ns)
-);""",
-    """CREATE TABLE IF NOT EXISTS checkpoint_blobs (
-    thread_id TEXT NOT NULL,
-    checkpoint_ns TEXT NOT NULL DEFAULT '',
-    channel TEXT NOT NULL,
-    type TEXT NOT NULL,
-    blob BYTEA,
-    PRIMARY KEY (thread_id, checkpoint_ns, channel)
-);""",
-    """CREATE TABLE IF NOT EXISTS checkpoint_writes (
-    thread_id TEXT NOT NULL,
-    checkpoint_ns TEXT NOT NULL DEFAULT '',
-    checkpoint_id TEXT NOT NULL,
-    task_id TEXT NOT NULL,
-    idx INTEGER NOT NULL,
-    channel TEXT NOT NULL,
-    type TEXT,
-    blob BYTEA NOT NULL,
-    PRIMARY KEY (thread_id, checkpoint_ns, checkpoint_id, task_id, idx)
-);""",
-    """
-    CREATE INDEX CONCURRENTLY IF NOT EXISTS checkpoints_thread_id_idx ON checkpoints(thread_id);
-    """,
-    """
-    CREATE INDEX CONCURRENTLY IF NOT EXISTS checkpoint_blobs_thread_id_idx ON checkpoint_blobs(thread_id);
-    """,
-    """
-    CREATE INDEX CONCURRENTLY IF NOT EXISTS checkpoint_writes_thread_id_idx ON checkpoint_writes(thread_id);
-    """,
-    """
-    ALTER TABLE checkpoint_writes ADD COLUMN task_path TEXT NOT NULL DEFAULT '';
-    """,
-]
-
-SELECT_SQL = f"""
-select
-    thread_id,
-    checkpoint,
-    checkpoint_ns,
-    metadata,
-    (
-        select array_agg(array[bl.channel::bytea, bl.type::bytea, bl.blob])
-        from jsonb_each_text(checkpoint -> 'channel_versions')
-        inner join checkpoint_blobs bl
-            on bl.thread_id = checkpoints.thread_id
-            and bl.checkpoint_ns = checkpoints.checkpoint_ns
-            and bl.channel = jsonb_each_text.key
-    ) as channel_values,
-    (
-        select
-        array_agg(array[cw.task_id::text::bytea, cw.channel::bytea, cw.type::bytea, cw.blob] order by cw.task_id, cw.idx)
-        from checkpoint_writes cw
-        where cw.thread_id = checkpoints.thread_id
-            and cw.checkpoint_ns = checkpoints.checkpoint_ns
-            and cw.checkpoint_id = (checkpoint->>'id')
-    ) as pending_writes,
-    (
-        select array_agg(array[cw.type::bytea, cw.blob] order by cw.task_path, cw.task_id, cw.idx)
-        from checkpoint_writes cw
-        where cw.thread_id = checkpoints.thread_id
-            and cw.checkpoint_ns = checkpoints.checkpoint_ns
-            and cw.channel = '{TASKS}'
-    ) as pending_sends
-from checkpoints """
-
-UPSERT_CHECKPOINT_BLOBS_SQL = """
-    INSERT INTO checkpoint_blobs (thread_id, checkpoint_ns, channel, type, blob)
-    VALUES (%s, %s, %s, %s, %s)
-    ON CONFLICT (thread_id, checkpoint_ns, channel) DO UPDATE SET
-        type = EXCLUDED.type,
-        blob = EXCLUDED.blob;
-"""
-
-UPSERT_CHECKPOINTS_SQL = """
-    INSERT INTO checkpoints (thread_id, checkpoint_ns, checkpoint, metadata)
-    VALUES (%s, %s, %s, %s)
-    ON CONFLICT (thread_id, checkpoint_ns)
-    DO UPDATE SET
-        checkpoint = EXCLUDED.checkpoint,
-        metadata = EXCLUDED.metadata;
-"""
-
-UPSERT_CHECKPOINT_WRITES_SQL = """
-    INSERT INTO checkpoint_writes (thread_id, checkpoint_ns, checkpoint_id, task_id, task_path, idx, channel, type, blob)
-    VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s)
-    ON CONFLICT (thread_id, checkpoint_ns, checkpoint_id, task_id, idx) DO UPDATE SET
-        channel = EXCLUDED.channel,
-        type = EXCLUDED.type,
-        blob = EXCLUDED.blob;
-"""
-
-INSERT_CHECKPOINT_WRITES_SQL = """
-    INSERT INTO checkpoint_writes (thread_id, checkpoint_ns, checkpoint_id, task_id, task_path, idx, channel, type, blob)
-    VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s)
-    ON CONFLICT (thread_id, checkpoint_ns, checkpoint_id, task_id, idx) DO NOTHING
-"""
-
-
-def _dump_blobs(
-    serde: SerializerProtocol,
-    thread_id: str,
-    checkpoint_ns: str,
-    values: dict[str, Any],
-    versions: ChannelVersions,
-) -> list[tuple[str, str, str, str, Optional[bytes]]]:
-    if not versions:
-        return []
-
-    return [
-        (
-            thread_id,
-            checkpoint_ns,
-            k,
-            *(serde.dumps_typed(values[k]) if k in values else ("empty", None)),
-        )
-        for k in versions
-    ]
-
-
-class ShallowPostgresSaver(BasePostgresSaver):
-    """A checkpoint saver that uses Postgres to store checkpoints.
-
-    This checkpointer ONLY stores the most recent checkpoint and does NOT retain any history.
-    It is meant to be a light-weight drop-in replacement for the PostgresSaver that
-    supports most of the LangGraph persistence functionality with the exception of time travel.
-    """
-
-    SELECT_SQL = SELECT_SQL
-    MIGRATIONS = MIGRATIONS
-    UPSERT_CHECKPOINT_BLOBS_SQL = UPSERT_CHECKPOINT_BLOBS_SQL
-    UPSERT_CHECKPOINTS_SQL = UPSERT_CHECKPOINTS_SQL
-    UPSERT_CHECKPOINT_WRITES_SQL = UPSERT_CHECKPOINT_WRITES_SQL
-    INSERT_CHECKPOINT_WRITES_SQL = INSERT_CHECKPOINT_WRITES_SQL
-
-    lock: threading.Lock
-
-    def __init__(
-        self,
-        conn: _internal.Conn,
-        pipe: Optional[Pipeline] = None,
-        serde: Optional[SerializerProtocol] = None,
-    ) -> None:
-        warnings.warn(
-            "ShallowPostgresSaver is deprecated as of version 2.0.20 and will be removed in 3.0.0. "
-            "Use PostgresSaver instead, and invoke the graph with `graph.invoke(..., checkpoint_during=False)`.",
-            DeprecationWarning,
-            stacklevel=2,
-        )
-        super().__init__(serde=serde)
-        if isinstance(conn, ConnectionPool) and pipe is not None:
-            raise ValueError(
-                "Pipeline should be used only with a single Connection, not ConnectionPool."
-            )
-
-        self.conn = conn
-        self.pipe = pipe
-        self.lock = threading.Lock()
-        self.supports_pipeline = Capabilities().has_pipeline()
-
-    @classmethod
-    @contextmanager
-    def from_conn_string(
-        cls, conn_string: str, *, pipeline: bool = False
-    ) -> Iterator["ShallowPostgresSaver"]:
-        """Create a new ShallowPostgresSaver instance from a connection string.
-
-        Args:
-            conn_string: The Postgres connection info string.
-            pipeline: whether to use Pipeline
-
-        Returns:
-            ShallowPostgresSaver: A new ShallowPostgresSaver instance.
-        """
-        with Connection.connect(
-            conn_string, autocommit=True, prepare_threshold=0, row_factory=dict_row
-        ) as conn:
-            if pipeline:
-                with conn.pipeline() as pipe:
-                    yield cls(conn, pipe)
-            else:
-                yield cls(conn)
-
-    def setup(self) -> None:
-        """Set up the checkpoint database asynchronously.
-
-        This method creates the necessary tables in the Postgres database if they don't
-        already exist and runs database migrations. It MUST be called directly by the user
-        the first time checkpointer is used.
-        """
-        with self._cursor() as cur:
-            cur.execute(self.MIGRATIONS[0])
-            results = cur.execute(
-                "SELECT v FROM checkpoint_migrations ORDER BY v DESC LIMIT 1"
-            )
-            row = results.fetchone()
-            if row is None:
-                version = -1
-            else:
-                version = row["v"]
-            for v, migration in zip(
-                range(version + 1, len(self.MIGRATIONS)),
-                self.MIGRATIONS[version + 1 :],
-            ):
-                cur.execute(migration)
-                cur.execute(f"INSERT INTO checkpoint_migrations (v) VALUES ({v})")
-        if self.pipe:
-            self.pipe.sync()
-
-    def list(
-        self,
-        config: Optional[RunnableConfig],
-        *,
-        filter: Optional[dict[str, Any]] = None,
-        before: Optional[RunnableConfig] = None,
-        limit: Optional[int] = None,
-    ) -> Iterator[CheckpointTuple]:
-        """List checkpoints from the database.
-
-        This method retrieves a list of checkpoint tuples from the Postgres database based
-        on the provided config. For ShallowPostgresSaver, this method returns a list with
-        ONLY the most recent checkpoint.
-        """
-        where, args = self._search_where(config, filter, before)
-        query = self.SELECT_SQL + where
-        if limit:
-            query += f" LIMIT {limit}"
-        with self._cursor() as cur:
-            cur.execute(self.SELECT_SQL + where, args, binary=True)
-            for value in cur:
-                checkpoint: Checkpoint = {
-                    **value["checkpoint"],
-                    "channel_values": self._load_blobs(value["channel_values"]),
-                    "pending_sends": [
-                        self.serde.loads_typed((t.decode(), v))
-                        for t, v in value["pending_sends"]
-                    ]
-                    if value["pending_sends"]
-                    else [],
-                }
-                yield CheckpointTuple(
-                    config={
-                        "configurable": {
-                            "thread_id": value["thread_id"],
-                            "checkpoint_ns": value["checkpoint_ns"],
-                            "checkpoint_id": checkpoint["id"],
-                        }
-                    },
-                    checkpoint=checkpoint,
-                    metadata=value["metadata"],
-                    pending_writes=self._load_writes(value["pending_writes"]),
-                )
-
-    def get_tuple(self, config: RunnableConfig) -> Optional[CheckpointTuple]:
-        """Get a checkpoint tuple from the database.
-
-        This method retrieves a checkpoint tuple from the Postgres database based on the
-        provided config (matching the thread ID in the config).
-
-        Args:
-            config: The config to use for retrieving the checkpoint.
-
-        Returns:
-            Optional[CheckpointTuple]: The retrieved checkpoint tuple, or None if no matching checkpoint was found.
-
-        Examples:
-
-            Basic:
-            >>> config = {"configurable": {"thread_id": "1"}}
-            >>> checkpoint_tuple = memory.get_tuple(config)
-            >>> print(checkpoint_tuple)
-            CheckpointTuple(...)
-
-            With timestamp:
-
-            >>> config = {
-            ...    "configurable": {
-            ...        "thread_id": "1",
-            ...        "checkpoint_ns": "",
-            ...        "checkpoint_id": "1ef4f797-8335-6428-8001-8a1503f9b875",
-            ...    }
-            ... }
-            >>> checkpoint_tuple = memory.get_tuple(config)
-            >>> print(checkpoint_tuple)
-            CheckpointTuple(...)
-        """  # noqa
-        thread_id = config["configurable"]["thread_id"]
-        checkpoint_ns = config["configurable"].get("checkpoint_ns", "")
-        args = (thread_id, checkpoint_ns)
-        where = "WHERE thread_id = %s AND checkpoint_ns = %s"
-
-        with self._cursor() as cur:
-            cur.execute(
-                self.SELECT_SQL + where,
-                args,
-                binary=True,
-            )
-
-            for value in cur:
-                checkpoint: Checkpoint = {
-                    **value["checkpoint"],
-                    "channel_values": self._load_blobs(value["channel_values"]),
-                    "pending_sends": [
-                        self.serde.loads_typed((t.decode(), v))
-                        for t, v in value["pending_sends"]
-                    ]
-                    if value["pending_sends"]
-                    else [],
-                }
-                return CheckpointTuple(
-                    config={
-                        "configurable": {
-                            "thread_id": thread_id,
-                            "checkpoint_ns": checkpoint_ns,
-                            "checkpoint_id": checkpoint["id"],
-                        }
-                    },
-                    checkpoint=checkpoint,
-                    metadata=value["metadata"],
-                    pending_writes=self._load_writes(value["pending_writes"]),
-                )
-
-    def put(
-        self,
-        config: RunnableConfig,
-        checkpoint: Checkpoint,
-        metadata: CheckpointMetadata,
-        new_versions: ChannelVersions,
-    ) -> RunnableConfig:
-        """Save a checkpoint to the database.
-
-        This method saves a checkpoint to the Postgres database. The checkpoint is associated
-        with the provided config. For ShallowPostgresSaver, this method saves ONLY the most recent
-        checkpoint and overwrites a previous checkpoint, if it exists.
-
-        Args:
-            config: The config to associate with the checkpoint.
-            checkpoint: The checkpoint to save.
-            metadata: Additional metadata to save with the checkpoint.
-            new_versions: New channel versions as of this write.
-
-        Returns:
-            RunnableConfig: Updated configuration after storing the checkpoint.
-
-        Examples:
-
-            >>> from langgraph.checkpoint.postgres import ShallowPostgresSaver
-            >>> DB_URI = "postgres://postgres:postgres@localhost:5432/postgres?sslmode=disable"
-            >>> with ShallowPostgresSaver.from_conn_string(DB_URI) as memory:
-            >>>     config = {"configurable": {"thread_id": "1", "checkpoint_ns": ""}}
-            >>>     checkpoint = {"ts": "2024-05-04T06:32:42.235444+00:00", "id": "1ef4f797-8335-6428-8001-8a1503f9b875", "channel_values": {"key": "value"}}
-            >>>     saved_config = memory.put(config, checkpoint, {"source": "input", "step": 1, "writes": {"key": "value"}}, {})
-            >>> print(saved_config)
-            {'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef4f797-8335-6428-8001-8a1503f9b875'}}
-        """
-        configurable = config["configurable"].copy()
-        thread_id = configurable.pop("thread_id")
-        checkpoint_ns = configurable.pop("checkpoint_ns")
-
-        copy = checkpoint.copy()
-        next_config = {
-            "configurable": {
-                "thread_id": thread_id,
-                "checkpoint_ns": checkpoint_ns,
-                "checkpoint_id": checkpoint["id"],
-            }
-        }
-
-        with self._cursor(pipeline=True) as cur:
-            cur.execute(
-                """DELETE FROM checkpoint_writes
-                WHERE thread_id = %s AND checkpoint_ns = %s AND checkpoint_id NOT IN (%s, %s)""",
-                (
-                    thread_id,
-                    checkpoint_ns,
-                    checkpoint["id"],
-                    configurable.get("checkpoint_id", ""),
-                ),
-            )
-            cur.executemany(
-                self.UPSERT_CHECKPOINT_BLOBS_SQL,
-                _dump_blobs(
-                    self.serde,
-                    thread_id,
-                    checkpoint_ns,
-                    copy.pop("channel_values"),  # type: ignore[misc]
-                    new_versions,
-                ),
-            )
-            cur.execute(
-                self.UPSERT_CHECKPOINTS_SQL,
-                (
-                    thread_id,
-                    checkpoint_ns,
-                    Jsonb(copy),
-                    Jsonb(get_checkpoint_metadata(config, metadata)),
-                ),
-            )
-        return next_config
-
-    def put_writes(
-        self,
-        config: RunnableConfig,
-        writes: Sequence[tuple[str, Any]],
-        task_id: str,
-        task_path: str = "",
-    ) -> None:
-        """Store intermediate writes linked to a checkpoint.
-
-        This method saves intermediate writes associated with a checkpoint to the Postgres database.
-
-        Args:
-            config: Configuration of the related checkpoint.
-            writes: List of writes to store.
-            task_id: Identifier for the task creating the writes.
-        """
-        query = (
-            self.UPSERT_CHECKPOINT_WRITES_SQL
-            if all(w[0] in WRITES_IDX_MAP for w in writes)
-            else self.INSERT_CHECKPOINT_WRITES_SQL
-        )
-        with self._cursor(pipeline=True) as cur:
-            cur.executemany(
-                query,
-                self._dump_writes(
-                    config["configurable"]["thread_id"],
-                    config["configurable"]["checkpoint_ns"],
-                    config["configurable"]["checkpoint_id"],
-                    task_id,
-                    task_path,
-                    writes,
-                ),
-            )
-
-    @contextmanager
-    def _cursor(self, *, pipeline: bool = False) -> Iterator[Cursor[DictRow]]:
-        """Create a database cursor as a context manager.
-
-        Args:
-            pipeline: whether to use pipeline for the DB operations inside the context manager.
-                Will be applied regardless of whether the ShallowPostgresSaver instance was initialized with a pipeline.
-                If pipeline mode is not supported, will fall back to using transaction context manager.
-        """
-        with _internal.get_connection(self.conn) as conn:
-            if self.pipe:
-                # a connection in pipeline mode can be used concurrently
-                # in multiple threads/coroutines, but only one cursor can be
-                # used at a time
-                try:
-                    with conn.cursor(binary=True, row_factory=dict_row) as cur:
-                        yield cur
-                finally:
-                    if pipeline:
-                        self.pipe.sync()
-            elif pipeline:
-                # a connection not in pipeline mode can only be used by one
-                # thread/coroutine at a time, so we acquire a lock
-                if self.supports_pipeline:
-                    with (
-                        self.lock,
-                        conn.pipeline(),
-                        conn.cursor(binary=True, row_factory=dict_row) as cur,
-                    ):
-                        yield cur
-                else:
-                    # Use connection's transaction context manager when pipeline mode not supported
-                    with (
-                        self.lock,
-                        conn.transaction(),
-                        conn.cursor(binary=True, row_factory=dict_row) as cur,
-                    ):
-                        yield cur
-            else:
-                with self.lock, conn.cursor(binary=True, row_factory=dict_row) as cur:
-                    yield cur
-
-
-class AsyncShallowPostgresSaver(BasePostgresSaver):
-    """A checkpoint saver that uses Postgres to store checkpoints asynchronously.
-
-    This checkpointer ONLY stores the most recent checkpoint and does NOT retain any history.
-    It is meant to be a light-weight drop-in replacement for the AsyncPostgresSaver that
-    supports most of the LangGraph persistence functionality with the exception of time travel.
-    """
-
-    SELECT_SQL = SELECT_SQL
-    MIGRATIONS = MIGRATIONS
-    UPSERT_CHECKPOINT_BLOBS_SQL = UPSERT_CHECKPOINT_BLOBS_SQL
-    UPSERT_CHECKPOINTS_SQL = UPSERT_CHECKPOINTS_SQL
-    UPSERT_CHECKPOINT_WRITES_SQL = UPSERT_CHECKPOINT_WRITES_SQL
-    INSERT_CHECKPOINT_WRITES_SQL = INSERT_CHECKPOINT_WRITES_SQL
-    lock: asyncio.Lock
-
-    def __init__(
-        self,
-        conn: _ainternal.Conn,
-        pipe: Optional[AsyncPipeline] = None,
-        serde: Optional[SerializerProtocol] = None,
-    ) -> None:
-        warnings.warn(
-            "AsyncShallowPostgresSaver is deprecated as of version 2.0.20 and will be removed in 3.0.0. "
-            "Use AsyncPostgresSaver instead, and invoke the graph with `await graph.ainvoke(..., checkpoint_during=False)`.",
-            DeprecationWarning,
-            stacklevel=2,
-        )
-        super().__init__(serde=serde)
-        if isinstance(conn, AsyncConnectionPool) and pipe is not None:
-            raise ValueError(
-                "Pipeline should be used only with a single AsyncConnection, not AsyncConnectionPool."
-            )
-
-        self.conn = conn
-        self.pipe = pipe
-        self.lock = asyncio.Lock()
-        self.loop = asyncio.get_running_loop()
-        self.supports_pipeline = Capabilities().has_pipeline()
-
-    @classmethod
-    @asynccontextmanager
-    async def from_conn_string(
-        cls,
-        conn_string: str,
-        *,
-        pipeline: bool = False,
-        serde: Optional[SerializerProtocol] = None,
-    ) -> AsyncIterator["AsyncShallowPostgresSaver"]:
-        """Create a new AsyncShallowPostgresSaver instance from a connection string.
-
-        Args:
-            conn_string: The Postgres connection info string.
-            pipeline: whether to use AsyncPipeline
-
-        Returns:
-            AsyncShallowPostgresSaver: A new AsyncShallowPostgresSaver instance.
-        """
-        async with await AsyncConnection.connect(
-            conn_string, autocommit=True, prepare_threshold=0, row_factory=dict_row
-        ) as conn:
-            if pipeline:
-                async with conn.pipeline() as pipe:
-                    yield cls(conn=conn, pipe=pipe, serde=serde)
-            else:
-                yield cls(conn=conn, serde=serde)
-
-    async def setup(self) -> None:
-        """Set up the checkpoint database asynchronously.
-
-        This method creates the necessary tables in the Postgres database if they don't
-        already exist and runs database migrations. It MUST be called directly by the user
-        the first time checkpointer is used.
-        """
-        async with self._cursor() as cur:
-            await cur.execute(self.MIGRATIONS[0])
-            results = await cur.execute(
-                "SELECT v FROM checkpoint_migrations ORDER BY v DESC LIMIT 1"
-            )
-            row = await results.fetchone()
-            if row is None:
-                version = -1
-            else:
-                version = row["v"]
-            for v, migration in zip(
-                range(version + 1, len(self.MIGRATIONS)),
-                self.MIGRATIONS[version + 1 :],
-            ):
-                await cur.execute(migration)
-                await cur.execute(f"INSERT INTO checkpoint_migrations (v) VALUES ({v})")
-        if self.pipe:
-            await self.pipe.sync()
-
-    async def alist(
-        self,
-        config: Optional[RunnableConfig],
-        *,
-        filter: Optional[dict[str, Any]] = None,
-        before: Optional[RunnableConfig] = None,
-        limit: Optional[int] = None,
-    ) -> AsyncIterator[CheckpointTuple]:
-        """List checkpoints from the database asynchronously.
-
-        This method retrieves a list of checkpoint tuples from the Postgres database based
-        on the provided config. For ShallowPostgresSaver, this method returns a list with
-        ONLY the most recent checkpoint.
-        """
-        where, args = self._search_where(config, filter, before)
-        query = self.SELECT_SQL + where
-        if limit:
-            query += f" LIMIT {limit}"
-        async with self._cursor() as cur:
-            await cur.execute(self.SELECT_SQL + where, args, binary=True)
-            async for value in cur:
-                checkpoint: Checkpoint = {
-                    **value["checkpoint"],
-                    "channel_values": self._load_blobs(value["channel_values"]),
-                    "pending_sends": [
-                        self.serde.loads_typed((t.decode(), v))
-                        for t, v in value["pending_sends"]
-                    ]
-                    if value["pending_sends"]
-                    else [],
-                }
-                yield CheckpointTuple(
-                    config={
-                        "configurable": {
-                            "thread_id": value["thread_id"],
-                            "checkpoint_ns": value["checkpoint_ns"],
-                            "checkpoint_id": checkpoint["id"],
-                        }
-                    },
-                    checkpoint=checkpoint,
-                    metadata=value["metadata"],
-                    pending_writes=await asyncio.to_thread(
-                        self._load_writes, value["pending_writes"]
-                    ),
-                )
-
-    async def aget_tuple(self, config: RunnableConfig) -> Optional[CheckpointTuple]:
-        """Get a checkpoint tuple from the database asynchronously.
-
-        This method retrieves a checkpoint tuple from the Postgres database based on the
-        provided config (matching the thread ID in the config).
-
-        Args:
-            config: The config to use for retrieving the checkpoint.
-
-        Returns:
-            Optional[CheckpointTuple]: The retrieved checkpoint tuple, or None if no matching checkpoint was found.
-        """
-        thread_id = config["configurable"]["thread_id"]
-        checkpoint_ns = config["configurable"].get("checkpoint_ns", "")
-        args = (thread_id, checkpoint_ns)
-        where = "WHERE thread_id = %s AND checkpoint_ns = %s"
-
-        async with self._cursor() as cur:
-            await cur.execute(
-                self.SELECT_SQL + where,
-                args,
-                binary=True,
-            )
-
-            async for value in cur:
-                checkpoint: Checkpoint = {
-                    **value["checkpoint"],
-                    "channel_values": self._load_blobs(value["channel_values"]),
-                    "pending_sends": [
-                        self.serde.loads_typed((t.decode(), v))
-                        for t, v in value["pending_sends"]
-                    ]
-                    if value["pending_sends"]
-                    else [],
-                }
-                return CheckpointTuple(
-                    config={
-                        "configurable": {
-                            "thread_id": thread_id,
-                            "checkpoint_ns": checkpoint_ns,
-                            "checkpoint_id": checkpoint["id"],
-                        }
-                    },
-                    checkpoint=checkpoint,
-                    metadata=value["metadata"],
-                    pending_writes=await asyncio.to_thread(
-                        self._load_writes, value["pending_writes"]
-                    ),
-                )
-
-    async def aput(
-        self,
-        config: RunnableConfig,
-        checkpoint: Checkpoint,
-        metadata: CheckpointMetadata,
-        new_versions: ChannelVersions,
-    ) -> RunnableConfig:
-        """Save a checkpoint to the database asynchronously.
-
-        This method saves a checkpoint to the Postgres database. The checkpoint is associated
-        with the provided config. For AsyncShallowPostgresSaver, this method saves ONLY the most recent
-        checkpoint and overwrites a previous checkpoint, if it exists.
-
-        Args:
-            config: The config to associate with the checkpoint.
-            checkpoint: The checkpoint to save.
-            metadata: Additional metadata to save with the checkpoint.
-            new_versions: New channel versions as of this write.
-
-        Returns:
-            RunnableConfig: Updated configuration after storing the checkpoint.
-        """
-        configurable = config["configurable"].copy()
-        thread_id = configurable.pop("thread_id")
-        checkpoint_ns = configurable.pop("checkpoint_ns")
-
-        copy = checkpoint.copy()
-        next_config = {
-            "configurable": {
-                "thread_id": thread_id,
-                "checkpoint_ns": checkpoint_ns,
-                "checkpoint_id": checkpoint["id"],
-            }
-        }
-
-        async with self._cursor(pipeline=True) as cur:
-            await cur.execute(
-                """DELETE FROM checkpoint_writes
-                WHERE thread_id = %s AND checkpoint_ns = %s AND checkpoint_id NOT IN (%s, %s)""",
-                (
-                    thread_id,
-                    checkpoint_ns,
-                    checkpoint["id"],
-                    configurable.get("checkpoint_id", ""),
-                ),
-            )
-            await cur.executemany(
-                self.UPSERT_CHECKPOINT_BLOBS_SQL,
-                _dump_blobs(
-                    self.serde,
-                    thread_id,
-                    checkpoint_ns,
-                    copy.pop("channel_values"),  # type: ignore[misc]
-                    new_versions,
-                ),
-            )
-            await cur.execute(
-                self.UPSERT_CHECKPOINTS_SQL,
-                (
-                    thread_id,
-                    checkpoint_ns,
-                    Jsonb(copy),
-                    Jsonb(get_checkpoint_metadata(config, metadata)),
-                ),
-            )
-        return next_config
-
-    async def aput_writes(
-        self,
-        config: RunnableConfig,
-        writes: Sequence[tuple[str, Any]],
-        task_id: str,
-        task_path: str = "",
-    ) -> None:
-        """Store intermediate writes linked to a checkpoint asynchronously.
-
-        This method saves intermediate writes associated with a checkpoint to the database.
-
-        Args:
-            config: Configuration of the related checkpoint.
-            writes: List of writes to store, each as (channel, value) pair.
-            task_id: Identifier for the task creating the writes.
-        """
-        query = (
-            self.UPSERT_CHECKPOINT_WRITES_SQL
-            if all(w[0] in WRITES_IDX_MAP for w in writes)
-            else self.INSERT_CHECKPOINT_WRITES_SQL
-        )
-        params = await asyncio.to_thread(
-            self._dump_writes,
-            config["configurable"]["thread_id"],
-            config["configurable"]["checkpoint_ns"],
-            config["configurable"]["checkpoint_id"],
-            task_id,
-            task_path,
-            writes,
-        )
-        async with self._cursor(pipeline=True) as cur:
-            await cur.executemany(query, params)
-
-    @asynccontextmanager
-    async def _cursor(
-        self, *, pipeline: bool = False
-    ) -> AsyncIterator[AsyncCursor[DictRow]]:
-        """Create a database cursor as a context manager.
-
-        Args:
-            pipeline: whether to use pipeline for the DB operations inside the context manager.
-                Will be applied regardless of whether the AsyncShallowPostgresSaver instance was initialized with a pipeline.
-                If pipeline mode is not supported, will fall back to using transaction context manager.
-        """
-        async with _ainternal.get_connection(self.conn) as conn:
-            if self.pipe:
-                # a connection in pipeline mode can be used concurrently
-                # in multiple threads/coroutines, but only one cursor can be
-                # used at a time
-                try:
-                    async with conn.cursor(binary=True, row_factory=dict_row) as cur:
-                        yield cur
-                finally:
-                    if pipeline:
-                        await self.pipe.sync()
-            elif pipeline:
-                # a connection not in pipeline mode can only be used by one
-                # thread/coroutine at a time, so we acquire a lock
-                if self.supports_pipeline:
-                    async with (
-                        self.lock,
-                        conn.pipeline(),
-                        conn.cursor(binary=True, row_factory=dict_row) as cur,
-                    ):
-                        yield cur
-                else:
-                    # Use connection's transaction context manager when pipeline mode not supported
-                    async with (
-                        self.lock,
-                        conn.transaction(),
-                        conn.cursor(binary=True, row_factory=dict_row) as cur,
-                    ):
-                        yield cur
-            else:
-                async with (
-                    self.lock,
-                    conn.cursor(binary=True, row_factory=dict_row) as cur,
-                ):
-                    yield cur
-
-    def list(
-        self,
-        config: Optional[RunnableConfig],
-        *,
-        filter: Optional[dict[str, Any]] = None,
-        before: Optional[RunnableConfig] = None,
-        limit: Optional[int] = None,
-    ) -> Iterator[CheckpointTuple]:
-        """List checkpoints from the database.
-
-        This method retrieves a list of checkpoint tuples from the Postgres database based
-        on the provided config. For ShallowPostgresSaver, this method returns a list with
-        ONLY the most recent checkpoint.
-        """
-        aiter_ = self.alist(config, filter=filter, before=before, limit=limit)
-        while True:
-            try:
-                yield asyncio.run_coroutine_threadsafe(
-                    anext(aiter_),  # noqa: F821
-                    self.loop,
-                ).result()
-            except StopAsyncIteration:
-                break
-
-    def get_tuple(self, config: RunnableConfig) -> Optional[CheckpointTuple]:
-        """Get a checkpoint tuple from the database.
-
-        This method retrieves a checkpoint tuple from the Postgres database based on the
-        provided config (matching the thread ID in the config).
-
-        Args:
-            config: The config to use for retrieving the checkpoint.
-
-        Returns:
-            Optional[CheckpointTuple]: The retrieved checkpoint tuple, or None if no matching checkpoint was found.
-        """
-        try:
-            # check if we are in the main thread, only bg threads can block
-            # we don't check in other methods to avoid the overhead
-            if asyncio.get_running_loop() is self.loop:
-                raise asyncio.InvalidStateError(
-                    "Synchronous calls to AsyncShallowPostgresSaver are only allowed from a "
-                    "different thread. From the main thread, use the async interface."
-                    "For example, use `await checkpointer.aget_tuple(...)` or `await "
-                    "graph.ainvoke(...)`."
-                )
-        except RuntimeError:
-            pass
-        return asyncio.run_coroutine_threadsafe(
-            self.aget_tuple(config), self.loop
-        ).result()
-
-    def put(
-        self,
-        config: RunnableConfig,
-        checkpoint: Checkpoint,
-        metadata: CheckpointMetadata,
-        new_versions: ChannelVersions,
-    ) -> RunnableConfig:
-        """Save a checkpoint to the database.
-
-        This method saves a checkpoint to the Postgres database. The checkpoint is associated
-        with the provided config. For AsyncShallowPostgresSaver, this method saves ONLY the most recent
-        checkpoint and overwrites a previous checkpoint, if it exists.
-
-        Args:
-            config: The config to associate with the checkpoint.
-            checkpoint: The checkpoint to save.
-            metadata: Additional metadata to save with the checkpoint.
-            new_versions: New channel versions as of this write.
-
-        Returns:
-            RunnableConfig: Updated configuration after storing the checkpoint.
-        """
-        return asyncio.run_coroutine_threadsafe(
-            self.aput(config, checkpoint, metadata, new_versions), self.loop
-        ).result()
-
-    def put_writes(
-        self,
-        config: RunnableConfig,
-        writes: Sequence[tuple[str, Any]],
-        task_id: str,
-        task_path: str = "",
-    ) -> None:
-        """Store intermediate writes linked to a checkpoint.
-
-        This method saves intermediate writes associated with a checkpoint to the database.
-
-        Args:
-            config: Configuration of the related checkpoint.
-            writes: List of writes to store, each as (channel, value) pair.
-            task_id: Identifier for the task creating the writes.
-            task_path: Path of the task creating the writes.
-        """
-        return asyncio.run_coroutine_threadsafe(
-            self.aput_writes(config, writes, task_id, task_path), self.loop
-        ).result()

libs/checkpoint-postgres/tests/checkpoint_utils.py

@@ -0,0 +1,53 @@
+from __future__ import annotations
+
+from collections.abc import Mapping
+from datetime import datetime, timezone
+from typing import Any, Protocol
+
+from langgraph.checkpoint.base import Checkpoint, EmptyChannelError
+from langgraph.checkpoint.base.id import uuid6
+
+
+class ChannelProtocol(Protocol):
+    def checkpoint(self) -> Any | None: ...
+
+
+def empty_checkpoint() -> Checkpoint:
+    return Checkpoint(
+        v=1,
+        id=str(uuid6(clock_seq=-2)),
+        ts=datetime.now(timezone.utc).isoformat(),
+        channel_values={},
+        channel_versions={},
+        versions_seen={},
+    )
+
+
+def create_checkpoint(
+    checkpoint: Checkpoint,
+    channels: Mapping[str, ChannelProtocol] | None,
+    step: int,
+    *,
+    id: str | None = None,
+) -> Checkpoint:
+    """Create a checkpoint for the given channels."""
+    ts = datetime.now(timezone.utc).isoformat()
+    if channels is None:
+        values = checkpoint["channel_values"]
+    else:
+        values = {}
+        for k, v in channels.items():
+            if k not in checkpoint["channel_versions"]:
+                continue
+            try:
+                values[k] = v.checkpoint()
+            except EmptyChannelError:
+                pass
+    return Checkpoint(
+        v=1,
+        ts=ts,
+        id=id or str(uuid6(clock_seq=step)),
+        channel_values=values,
+        channel_versions=checkpoint["channel_versions"],
+        versions_seen=checkpoint["versions_seen"],
+    )

libs/checkpoint-postgres/tests/test_async.py

@@ -14,14 +14,10 @@ from langgraph.checkpoint.base import (
     EXCLUDED_METADATA_KEYS,
     Checkpoint,
     CheckpointMetadata,
-    create_checkpoint,
-    empty_checkpoint,
-)
-from langgraph.checkpoint.postgres.aio import (
-    AsyncPostgresSaver,
-    AsyncShallowPostgresSaver,
 )
+from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver
 from langgraph.checkpoint.serde.types import TASKS
+from tests.checkpoint_utils import create_checkpoint, empty_checkpoint
 from tests.conftest import DEFAULT_POSTGRES_URI
 
 
@@ -112,41 +108,11 @@ async def _base_saver():
             await conn.execute(f"DROP DATABASE {database}")
 
 
-@asynccontextmanager
-async def _shallow_saver():
-    """Fixture for shallow connection mode testing."""
-    database = f"test_{uuid4().hex[:16]}"
-    # create unique db
-    async with await AsyncConnection.connect(
-        DEFAULT_POSTGRES_URI, autocommit=True
-    ) as conn:
-        await conn.execute(f"CREATE DATABASE {database}")
-    try:
-        async with await AsyncConnection.connect(
-            DEFAULT_POSTGRES_URI + database,
-            autocommit=True,
-            prepare_threshold=0,
-            row_factory=dict_row,
-        ) as conn:
-            checkpointer = AsyncShallowPostgresSaver(conn)
-            await checkpointer.setup()
-            yield checkpointer
-    finally:
-        # drop unique db
-        async with await AsyncConnection.connect(
-            DEFAULT_POSTGRES_URI, autocommit=True
-        ) as conn:
-            await conn.execute(f"DROP DATABASE {database}")
-
-
 @asynccontextmanager
 async def _saver(name: str):
     if name == "base":
         async with _base_saver() as saver:
             yield saver
-    elif name == "shallow":
-        async with _shallow_saver() as saver:
-            yield saver
     elif name == "pool":
         async with _pool_saver() as saver:
             yield saver
@@ -206,7 +172,7 @@ def test_data():
     }
 
 
-@pytest.mark.parametrize("saver_name", ["base", "pool", "pipe", "shallow"])
+@pytest.mark.parametrize("saver_name", ["base", "pool", "pipe"])
 async def test_combined_metadata(saver_name: str, test_data) -> None:
     async with _saver(saver_name) as saver:
         config = {
@@ -228,11 +194,12 @@ async def test_combined_metadata(saver_name: str, test_data) -> None:
         checkpoint = await saver.aget_tuple(config)
         assert checkpoint.metadata == {
             **metadata,
+            "thread_id": "thread-2",
             "run_id": "my_run_id",
         }
 
 
-@pytest.mark.parametrize("saver_name", ["base", "pool", "pipe", "shallow"])
+@pytest.mark.parametrize("saver_name", ["base", "pool", "pipe"])
 async def test_asearch(saver_name: str, test_data) -> None:
     async with _saver(saver_name) as saver:
         configs = test_data["configs"]
@@ -283,7 +250,7 @@ async def test_asearch(saver_name: str, test_data) -> None:
         } == {"", "inner"}
 
 
-@pytest.mark.parametrize("saver_name", ["base", "pool", "pipe", "shallow"])
+@pytest.mark.parametrize("saver_name", ["base", "pool", "pipe"])
 async def test_null_chars(saver_name: str, test_data) -> None:
     async with _saver(saver_name) as saver:
         config = await saver.aput(