One more

.github/ISSUE_TEMPLATE/bug-report.yml

@@ -1,6 +1,6 @@
 name: "\U0001F41B Bug Report"
 description: Report a bug in LangGraph. To report a security issue, please instead use the security option below. For questions, please use the GitHub Discussions.
-labels: [pending,bug]
+labels: ["02 Bug Report"]
 body:
   - type: markdown
     attributes:

.github/ISSUE_TEMPLATE/config.yml

@@ -1,4 +1,4 @@
-blank_issues_enabled: true
+blank_issues_enabled: false
 version: 2.1
 contact_links:
   - name: 🤔 Question or Problem

.github/ISSUE_TEMPLATE/documentation.yml

@@ -1,7 +1,7 @@
 name: Documentation
 description: Report an issue related to the LangGraph documentation.
 title: "DOC: <Please write a comprehensive title after the 'DOC: ' prefix>"
-labels: [documentation]
+labels: [03 - Documentation]
 
 body:
 - type: textarea

.github/dependabot.yml

@@ -1,11 +0,0 @@
-# Please see the documentation for all configuration options:
-# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
-# and
-# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
-
-version: 2
-updates:
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "weekly"

.github/workflows/_lint.yml

@@ -49,7 +49,7 @@ jobs:
 
       - name: Get .mypy_cache to speed up mypy
         if: steps.changed-files.outputs.all
-        uses: actions/cache@v4
+        uses: actions/cache@v3
         env:
           SEGMENT_DOWNLOAD_TIMEOUT_MIN: "2"
         with:
@@ -75,7 +75,7 @@ jobs:
 
       - name: Get .mypy_cache_test to speed up mypy
         if: steps.changed-files.outputs.all
-        uses: actions/cache@v4
+        uses: actions/cache@v3
         env:
           SEGMENT_DOWNLOAD_TIMEOUT_MIN: "2"
         with:

.github/workflows/_test_release.yml

@@ -13,7 +13,7 @@ env:
 
 jobs:
   build:
-    if: github.ref == 'refs/heads/main'
+    if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/v0'
     runs-on: ubuntu-latest
 
     outputs:

.github/workflows/_test_scheduler_kafka.yml

@@ -0,0 +1,52 @@
+name: test
+
+on:
+  workflow_call:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        python-version:
+          - "3.11"
+          - "3.12"
+
+    defaults:
+      run:
+        working-directory: libs/scheduler-kafka
+    name: "test #${{ matrix.python-version }}"
+    steps:
+      - uses: actions/checkout@v4
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: astral-sh/setup-uv@v6
+        with:
+          python-version: ${{ matrix.python-version }}
+          enable-cache: true
+          cache-suffix: "test-scheduler-kafka"
+      - name: Login to Docker Hub
+        uses: docker/login-action@v3
+        if: ${{ !github.event.pull_request.head.repo.fork }}
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_RO_TOKEN }}
+
+      - name: Install dependencies
+        shell: bash
+        run: uv sync --frozen --group dev
+
+      - name: Run tests
+        shell: bash
+        run: make test
+
+      - name: Ensure the tests did not create any additional files
+        shell: bash
+        run: |
+          set -eu
+
+          STATUS="$(git status)"
+          echo "$STATUS"
+
+          # grep will exit non-zero if the target message isn't found,
+          # and `set -e` above will cause the step to fail.
+          echo "$STATUS" | grep 'nothing to commit, working tree clean'

.github/workflows/ci.yml

@@ -35,6 +35,7 @@ jobs:
               - 'libs/checkpoint/**'
               - 'libs/checkpoint-sqlite/**'
               - 'libs/checkpoint-postgres/**'
+              - 'libs/scheduler-kafka/**'
               - 'libs/prebuilt/**'
             sdk-js:
               - 'libs/sdk-js/**'
@@ -52,7 +53,7 @@ jobs:
             "libs/checkpoint",
             "libs/checkpoint-sqlite",
             "libs/checkpoint-postgres",
-
+            "libs/scheduler-kafka",
             "libs/prebuilt",
           ]
     if: needs.changes.outputs.python == 'true'
@@ -88,6 +89,14 @@ jobs:
     uses: ./.github/workflows/_test_langgraph.yml
     secrets: inherit
 
+  # NOTE: we're testing scheduler-kafka separately because it requires a different matrix
+  test-scheduler-kafka:
+    needs: changes
+    if: needs.changes.outputs.python == 'true'
+    name: "cd libs/scheduler-kafka"
+    uses: ./.github/workflows/_test_scheduler_kafka.yml
+    secrets: inherit
+
   check-sdk-methods:
     needs: changes
     if: needs.changes.outputs.python == 'true'
@@ -157,9 +166,9 @@ jobs:
       run:
         working-directory: ${{ matrix.working-directory }}
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v3
       - name: Setup Node.js (LTS)
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v3
         with:
           node-version: "20"
           cache: "yarn"
@@ -183,9 +192,9 @@ jobs:
       run:
         working-directory: ${{ matrix.working-directory }}
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v3
       - name: Setup Node.js (LTS)
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v3
         with:
           node-version: "20"
           cache: "yarn"
@@ -203,6 +212,7 @@ jobs:
         lint-js,
         test,
         test-langgraph,
+        test-scheduler-kafka,
         check-sdk-methods,
         check-schema,
         integration-test,

.github/workflows/deploy_docs.yml

@@ -145,7 +145,7 @@ jobs:
 
       - name: Configure GitHub Pages
         if: github.ref == 'refs/heads/main'
-        uses: actions/configure-pages@v5
+        uses: actions/configure-pages@v4
 
       - name: Upload Pages Artifact
         # if: github.ref == 'refs/heads/main'

.github/workflows/release.yml

@@ -13,7 +13,7 @@ env:
 
 jobs:
   build:
-    if: github.ref == 'refs/heads/main'
+    if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/v0'
     runs-on: ubuntu-latest
 
     outputs:

.github/workflows/release_js.yml

@@ -22,7 +22,7 @@ jobs:
       - uses: actions/checkout@v4
       # JS Build
       - name: Use Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v3
         with:
           node-version: "20"
           cache: "yarn"

.gitignore

@@ -181,4 +181,3 @@ Chinook.db
 .vercel
 .turbo
 .editorconfig
-.scratch

AGENTS.md

@@ -1,55 +0,0 @@
-# AGENTS Instructions
-
-This repository is a monorepo. Each library lives in a subdirectory under `libs/`.
-
-When you modify code in any library, run the following commands in that library's directory before creating a pull request:
-
-- `make format` – run code formatters
-- `make lint` – run the linter
-- `make test` – execute the test suite
-
-To run a particular test file or to pass additional pytest options you can specify the `TEST` variable:
-
-```
-TEST=path/to/test.py make test
-```
-
-Other pytest arguments can also be supplied inside the `TEST` variable.
-
-## Libraries
-
-The repository contains several Python and JavaScript/TypeScript libraries.
-Below is a high-level overview:
-
-- **checkpoint** – base interfaces for LangGraph checkpointers.
-- **checkpoint-postgres** – Postgres implementation of the checkpoint saver.
-- **checkpoint-sqlite** – SQLite implementation of the checkpoint saver.
-- **cli** – official command-line interface for LangGraph.
-- **langgraph** – core framework for building stateful, multi-actor agents.
-- **prebuilt** – high-level APIs for creating and running agents and tools.
-- **sdk-js** – JS/TS SDK for interacting with the LangGraph REST API.
-- **sdk-py** – Python SDK for the LangGraph Platform API.
-
-### Dependency map
-
-The diagram below lists downstream libraries for each production dependency as
-declared in that library's `pyproject.toml` (or `package.json`).
-
-```text
-checkpoint
-├── checkpoint-postgres
-├── checkpoint-sqlite
-├── prebuilt
-└── langgraph
-
-prebuilt
-└── langgraph
-
-sdk-py
-├── langgraph
-└── cli
-
-sdk-js (standalone)
-```
-
-Changes to a library may impact all of its dependents shown above.

CONTRIBUTING.md

@@ -109,7 +109,7 @@ Here are some high-level tips on writing a good how-to guide:
 LangGraph's conceptual guides fall under the **Explanation** quadrant of Diataxis. They should cover LangChain terms and concepts
 in a more abstract way than how-to guides or tutorials, and should be geared towards curious users interested in
 gaining a deeper understanding of the framework. Try to avoid excessively large code examples. The goal here is to
-impart perspective to the user rather than to finish a practical project. These guides should cover **why** things work the way they do.
+impart perspective to the user rather than to finish a practical project. These guides should cover **why** things work they way they do.
 
 
 To quote the Diataxis website:

Makefile

@@ -1,58 +0,0 @@
-# Define the directories containing projects
-LIBS_DIRS := $(wildcard libs/*)
-
-# Default target
-.PHONY: all
-all: lint format lock test
-
-# Install dependencies for all projects
-.PHONY: install
-install:
-	@echo "Creating virtual environment..."
-	@uv venv
-	@for dir in $(LIBS_DIRS); do \
-		if [ -f $$dir/pyproject.toml ]; then \
-			echo "Installing dependencies for $$dir"; \
-			uv pip install -e $$dir; \
-		fi; \
-	done
-
-# Lint all projects
-.PHONY: lint
-lint:
-	@for dir in $(LIBS_DIRS); do \
-		if [ -f $$dir/Makefile ]; then \
-			echo "Running lint in $$dir"; \
-			$(MAKE) -C $$dir lint; \
-		fi; \
-	done
-
-# Format all projects
-.PHONY: format
-format:
-	@for dir in $(LIBS_DIRS); do \
-		if [ -f $$dir/Makefile ]; then \
-			echo "Running format in $$dir"; \
-			$(MAKE) -C $$dir format; \
-		fi; \
-	done
-
-# Lock all projects
-.PHONY: lock
-lock:
-	@for dir in $(LIBS_DIRS); do \
-		if [ -f $$dir/Makefile ]; then \
-			echo "Running lock in $$dir"; \
-			(cd $$dir && uv lock); \
-		fi; \
-	done
-
-# Test all projects
-.PHONY: test
-test:
-	@for dir in $(LIBS_DIRS); do \
-		if [ -f $$dir/Makefile ]; then \
-			echo "Running test in $$dir"; \
-			$(MAKE) -C $$dir test; \
-		fi; \
-	done

README.md

@@ -12,6 +12,7 @@
 [![Downloads](https://static.pepy.tech/badge/langgraph/month)](https://pepy.tech/project/langgraph)
 [![Open Issues](https://img.shields.io/github/issues-raw/langchain-ai/langgraph)](https://github.com/langchain-ai/langgraph/issues)
 [![Docs](https://img.shields.io/badge/docs-latest-blue)](https://langchain-ai.github.io/langgraph/)
+[![GitMCP](https://img.shields.io/endpoint?url=https://gitmcp.io/badge/langchain-ai/langgraph)](https://gitmcp.io/langchain-ai/langgraph)
 
 Trusted by companies shaping the future of agents – including Klarna, Replit, Elastic, and more – LangGraph is a low-level orchestration framework for building, managing, and deploying long-running, stateful agents.
 

docs/Makefile

@@ -19,10 +19,10 @@ build-prebuilt:
 		uv run python -m _scripts.third_party_page.get_download_stats --fake stats.yml; \
 		set +x; \
 	fi
-	uv run python -m _scripts.third_party_page.create_third_party_page stats.yml docs/agents/prebuilt.md
+	uv run python -m _scripts.third_party_page.create_third_party_page stats.yml docs/agents/prebuilt.md --language python
 
 build-docs: build-typedoc build-prebuilt
-	TARGET_LANGUAGE=js uv run python -m mkdocs build --clean -f mkdocs.yml --strict
+	uv run python -m mkdocs build --clean -f mkdocs.yml --strict
 
 llms-text:
 	uv run python -m _scripts.generate_llms_text docs/llms-full.txt

docs/_scripts/add_translation.py

@@ -0,0 +1,157 @@
+"""Add typescript translation to a given markdown file."""
+
+import argparse
+import re
+
+import requests
+from langchain_anthropic import ChatAnthropic
+
+URL = "https://gist.githubusercontent.com/eyurtsev/e7486731415463a9bc5b4682358859c8/raw/b5a5fda9c7e3387cfcb781f25082814d43675d50/gistfile1.txt"
+response = requests.get(URL)
+response.raise_for_status()
+reference_snippets = response.text
+
+model = ChatAnthropic(model="claude-3-5-sonnet-latest")
+
+
+def _get_tqdm():
+    try:
+        from tqdm import tqdm
+    except ImportError:
+        # If not available return a simple identity function
+        def tqdm(iterable, *args, **kwargs):
+            return iterable
+
+    return tqdm
+
+
+_tqdm = _get_tqdm()
+
+opening_pattern = re.compile(r"^\s*```python(?:\s+.*)?\s*$")
+closing_pattern = re.compile(r"^\s*```\s*$")
+
+
+def extract_python_snippets(markdown: str) -> list[str]:
+    """
+    Extract all python code blocks (including their fence lines) from the markdown content.
+    A python block is defined as any block that starts with a line containing an opening fence
+    with '```python' (optionally with extra parameters) and ends with a closing fence '```'.
+    """
+    snippets = []
+    inside_block = False
+    current_snippet = []
+
+    for line in markdown.splitlines(keepends=True):
+        if not inside_block:
+            if opening_pattern.match(line):
+                inside_block = True
+                current_snippet = [line]
+        else:
+            current_snippet.append(line)
+            if closing_pattern.match(line):
+                inside_block = False
+                snippets.append("".join(current_snippet))
+                current_snippet = []
+    return snippets
+
+
+def translate_snippet(python_snippet: str) -> str:
+    """Translate a python code block into a TypeScript code block using Langchain.
+    The response is expected to be a properly fenced TypeScript code block (i.e.
+    starting with ```typescript and ending with ```).
+    """
+    ai_message = model.invoke(
+        [
+            {
+                "role": "system",
+                "content": (
+                    f"You have access to the following up-to-date example TypeScript code "
+                    f"snippets that show examples of building with langgraph "
+                    f"and langchain:\n\n{reference_snippets}\n\n"
+                    "Use this context to translate the following Python code to equivalent "
+                    "TypeScript. Ensure that your output is a valid fenced TypeScript "
+                    "code block (i.e. starts with ```typescript and ends with ```)."
+                ),
+            },
+            {
+                "role": "user",
+                "content": f"Translate this Python snippet to TypeScript:\n\n{python_snippet}",
+            },
+        ]
+    )
+
+    # Use a regular expression to search for a TypeScript code block in the response.
+    pattern = r"```typescript\s*(.*?)\s*```"
+    match = re.search(pattern, ai_message.content, re.DOTALL)
+    if match:
+        # Reconstruct the code block with proper fences.
+        typescript_code = match.group(1).strip()
+        return f"```typescript\n{typescript_code}\n```"
+    else:
+        raise ValueError("No TypeScript code block found in the model's response.")
+
+
+def insert_translations_into_markdown(
+    markdown: str, typescript_snippets: list[str]
+) -> str:
+    """Walks through the original markdown content and, after each
+    Python snippet block, inserts the corresponding translated TypeScript snippet.
+    It assumes that the ordering of the Python snippets
+    (from extract_python_snippets) matches the order they appear in the markdown.
+    """
+    output_lines = []
+    lines = markdown.splitlines(keepends=True)
+    inside_block = False
+    snippet_index = 0
+
+    for line in lines:
+        output_lines.append(line)
+        if not inside_block and opening_pattern.match(line):
+            # We've encountered the start of a python code block.
+            inside_block = True
+        elif inside_block:
+            if closing_pattern.match(line):
+                # End of a python snippet block.
+                inside_block = False
+                if snippet_index < len(typescript_snippets):
+                    # Insert an extra newline for clarity, then the translated TypeScript snippet.
+                    output_lines.append("\n")
+                    output_lines.append(typescript_snippets[snippet_index])
+                    output_lines.append("\n")
+                    snippet_index += 1
+    return "".join(output_lines)
+
+
+def main(file_path: str) -> None:
+    # Read the markdown file.
+    with open(file_path, "r") as f:
+        markdown_content = f.read()
+
+    # 1. Extract all Python snippets.
+    python_snippets = extract_python_snippets(markdown_content)[:1]
+
+    # 2. Translate each Python snippet to TypeScript.
+    typescript_snippets = []
+    # Replace with .batch() for faster translation
+    for python_snippet in _tqdm(python_snippets):
+        ts_snippet = translate_snippet(python_snippet)
+        typescript_snippets.append(ts_snippet)
+
+    # 3. Insert the TypeScript translations after their respective Python snippets.
+    updated_markdown = insert_translations_into_markdown(
+        markdown_content, typescript_snippets
+    )
+
+    # Overwrite the original markdown file with the updated content.
+    with open(file_path, "w") as f:
+        f.write(updated_markdown)
+
+
+if __name__ == "__main__":
+    parser = argparse.ArgumentParser(
+        description="Translate Python snippets in a markdown file to TypeScript and insert them after each Python snippet."
+    )
+    parser.add_argument("file_path", type=str, help="Path to the markdown file.")
+    args = parser.parse_args()
+
+    main(args.file_path)

docs/_scripts/generate_llms_text.py

@@ -3,21 +3,19 @@
 import asyncio
 import glob
 import os
-import re
 from typing import TypedDict, List, Optional
+import pydantic
+import re
+from pydantic import BaseModel, Field
+from langchain_core.rate_limiters import InMemoryRateLimiter
 
 import yaml
 from langchain.chat_models import init_chat_model
-from langchain_core.rate_limiters import InMemoryRateLimiter
 from mkdocs.structure.files import File
 from mkdocs.structure.pages import Page
-from pydantic import BaseModel, Field
 from yaml import SafeLoader
 
-from _scripts.notebook_hooks import (
-    _on_page_markdown_with_config,
-    _apply_conditional_rendering,
-)
+from _scripts.notebook_hooks import _on_page_markdown_with_config
 
 HERE = os.path.dirname(os.path.abspath(__file__))
 # Get source directory (parent of HERE / docs)
@@ -213,9 +211,7 @@ async def process_nav_items(nav_items: list[NavItem]) -> list[NavItem]:
     # Remove any items that start with http:// or https:// looking only for
     # local file at this stages.
     nav_items = [
-        item
-        for item in nav_items
-        if not item["url"].startswith(("http://", "https://"))
+        item for item in nav_items if not item["url"].startswith(("http://", "https://"))
     ]
     # Process items in parallel
     tasks = [process_single_item(item) for item in nav_items]

docs/_scripts/js_translation/add_translation.py

@@ -1,236 +0,0 @@
-"""Translate Python markdown to TypeScript and/or consolidate Python-JS markdown into a single document."""
-
-import argparse
-
-import requests
-from langchain_anthropic import ChatAnthropic
-from textwrap import dedent
-
-
-# Load reference TypeScript snippets
-URL = "https://gist.githubusercontent.com/dqbd/b35d49e2ceec80e654fe1c5ab61ec477/raw/f4768aeedb67628190a4e06d063a938afc8e7672/snippets.md"
-response = requests.get(URL)
-response.raise_for_status()
-reference_snippets = response.text
-
-# Initialize model
-model = ChatAnthropic(model="claude-sonnet-4-0", max_tokens=64_000)
-
-
-FLUENT_INTERFACE_PROMPT = (
-    "CRITICAL: Always use method chaining (fluent interface) for StateGraph operations in TypeScript. "
-    "Never create separate variables for the graph builder or call methods individually. "
-    "The fluent interface provides better type safety and is the preferred pattern.\n\n"
-    "CORRECT examples with fluent interface:\n"
-    + dedent(
-        """
-        ```typescript
-        const graph = new StateGraph(MyState)
-          .addNode('node1', node1)
-          .addNode('node2', node2)
-          .addEdge(START, 'node1')
-          .addEdge('node1', 'node2')
-          .addEdge('node2', END)
-          .compile()
-        ```
-        
-        ```typescript
-        const graph = new StateGraph(MyState)
-          .addNode('chatbot', chatbot)
-          .addEdge(START, 'chatbot')
-          .addEdge('chatbot', END)
-          .compile()
-        ```
-        
-        ```typescript
-        const graph = new StateGraph(MyState)
-          .addNode('chatbot', chatbot)
-          .addEdge(START, 'chatbot')
-          .addEdge('chatbot', END)
-          .compile()
-        ```
-        """
-    )
-    + "\n"
-    + "INCORRECT examples to avoid:\n"
-    + dedent(
-        """
-        ```typescript
-        // WRONG: Creating separate builder variable
-        const graphBuilder = new StateGraph(MyState)
-        graphBuilder.addNode('node1', node1)
-        graphBuilder.addEdge(START, 'node1')
-        const graph = graphBuilder.compile()
-        ```
-        
-        ```typescript
-        // WRONG: Using Python-style method names
-        const workflow = new StateGraph(MyState)
-        workflow.add_node('node1', node1)
-        workflow.add_edge(START, 'node1')
-        const graph = workflow.compile()
-        ```
-        
-        ```typescript
-        // WRONG: Calling methods individually
-        const graphBuilder = new StateGraph(MyState)
-        graphBuilder.addNode('chatbot', chatbot)
-        graphBuilder.addEdge(START, 'chatbot')
-        graphBuilder.addEdge('chatbot', END)
-        const graph = graphBuilder.compile()
-        ```
-        """
-    )
-    + "\n"
-    + "Key rules:\n"
-    + "- Always chain methods directly on the StateGraph constructor\n"
-    + "- Use camelCase method names (addNode, addEdge, not add_node, add_edge)\n"
-    + "- Always end with .compile()\n"
-    + "- Never store the builder in a separate variable\n"
-)
-
-
-TRANSLATION_PROMPT = (
-    "You are a helpful assistant that translates Python-based technical "
-    "documentation written in Markdown to equivalent TypeScript-based documentation. "
-    "The input is a Markdown file written in mkdocs format. It contains "
-    "Python code snippets embedded in prose. "
-    "Your task is to rewrite the content by translating the Python code to "
-    "idiomatic TypeScript, using the provided TypeScript reference snippets "
-    "to ensure accurate and consistent usage (e.g., correct imports, function "
-    "names, and patterns). "
-    "Remove the original Python code and replace it with the corresponding "
-    "TypeScript version. "
-    "Do not alter the surrounding prose unless a change is necessary to "
-    "reflect differences between Python and TypeScript. "
-    "Preserve the structure and formatting of the original Markdown document. "
-    "Do not make stylistic or structural changes unless they directly support "
-    "the translation. "
-    "Use the reference TypeScript snippets as guidance whenever possible to "
-    "maintain alignment with existing conventions.\n\n"
-    "IMPORTANT REQUIREMENTS:\n"
-    "- Use Zod for state definition for StateGraph. Avoid using Annotation since it will be deprecated in the future.\n"
-    "- ALWAYS use fluent interface (method chaining) for StateGraph operations - this is CRITICAL\n"
-    "- Never create separate variables for graph builders\n"
-    "- Always chain methods directly on the StateGraph constructor and end with .compile()\n\n"
-    f"{FLUENT_INTERFACE_PROMPT}\n\n"
-    f"Here are the reference TypeScript snippets:\n\n{reference_snippets}\n\n"
-)
-
-CONSOLIDATION_PROMPT = (
-    "You are a helpful assistant that consolidates parallel Python and JavaScript (TypeScript) technical documentation "
-    "written in Markdown into a single unified Markdown document. "
-    "The input consists of two documents: the first is for Python users, and the second is for JavaScript/TypeScript users. "
-    "Your task is to merge these into one Markdown file using language-specific fenced blocks to separate the content where needed. "
-    "Use the following syntax to distinguish content for each language:\n\n"
-    ":::python\n"
-    "# Python-specific content\n"
-    ":::\n\n"
-    ":::js\n"
-    "# JavaScript/TypeScript-specific content\n"
-    ":::\n\n"
-    "Follow these consolidation rules:\n"
-    "- When content (prose or code) is the same or nearly identical in both versions, include it only once—outside of any fenced block.\n"
-    "- When content differs between the Python and JS versions, wrap each version in its corresponding fenced block.\n"
-    "- Prefer **paragraph-level separation** of language-specific content. Do not combine Python and JS snippets or terminology in the same sentence or paragraph using conditional phrases.\n"
-    "  For example, avoid inline constructs like:\n"
-    "  `The :::python add_messages ::: :::js reducer ::: function...`\n"
-    "  Instead, write two distinct paragraphs:\n\n"
-    "  :::python\n"
-    "  The `add_messages` function in our `State` will append the LLM's response messages to whatever messages are already in the state.\n"
-    "  ::: \n\n"
-    "  :::js\n"
-    "  The `reducer` function in our `StateAnnotation` will append the LLM's response messages to whatever messages are already in the state.\n"
-    "  :::\n\n"
-    "- Preserve the overall structure, ordering, and formatting of the original Markdown documents.\n"
-    "- Do not rephrase or unify content unless it is logically and semantically identical.\n"
-    "- Use the fenced blocks for both prose and code as needed, and ensure output is clean, readable Markdown suitable for tools that parse these directives.\n"
-    "Your goal is to produce a cleanly merged documentation file that serves both Python and JavaScript users without redundancy, while maximizing clarity and separation of language-specific details."
-)
-
-
-def translate_python_to_ts(markdown_content: str) -> str:
-    response = model.invoke(
-        [
-            {
-                "role": "system",
-                "content": TRANSLATION_PROMPT,
-                "cache_control": {"type": "ephemeral"},
-            },
-            {"role": "user", "content": markdown_content},
-        ]
-    )
-    return response.content
-
-
-def consolidate_python_and_ts(combined_content: str) -> str:
-    response = model.invoke(
-        [
-            {
-                "role": "system",
-                "content": CONSOLIDATION_PROMPT,
-                "cache_control": {"type": "ephemeral"},
-            },
-            {"role": "user", "content": combined_content},
-        ]
-    )
-    return response.content
-
-
-def main(file_path: str, translate_only: bool, consolidate_only: bool) -> None:
-    with open(file_path, "r", encoding="utf-8") as f:
-        markdown_content = f.read()
-
-    if translate_only:
-        translated = translate_python_to_ts(markdown_content)
-        output_path = file_path.replace(".md", ".translated.md")
-        with open(output_path, "w", encoding="utf-8") as f:
-            f.write(translated)
-        print(f"Translated JS/TS version written to: {output_path}")
-
-    elif consolidate_only:
-        consolidated = consolidate_python_and_ts(markdown_content)
-        with open(file_path, "w", encoding="utf-8") as f:
-            f.write(consolidated)
-        print(f"Consolidated content written to: {file_path}")
-
-    else:
-        # Default behavior: translate first, then consolidate both
-        translated = translate_python_to_ts(markdown_content)
-        combined = f"{markdown_content.strip()}\n\n\n{translated.strip()}"
-        consolidated = consolidate_python_and_ts(combined)
-        with open(file_path, "w", encoding="utf-8") as f:
-            f.write(consolidated)
-        print(f"Translated and consolidated content written to: {file_path}")
-
-
-if __name__ == "__main__":
-    parser = argparse.ArgumentParser(
-        description=(
-            "Translate Python markdown to TypeScript and/or consolidate "
-            "Python-JS markdown into one file."
-        )
-    )
-    parser.add_argument("file_path", type=str, help="Path to the markdown file.")
-    parser.add_argument(
-        "--translate-only",
-        action="store_true",
-        help="Only generate the JS translation.",
-    )
-    parser.add_argument(
-        "--consolidate-only",
-        action="store_true",
-        help="Only consolidate pre-paired Python and JS content.",
-    )
-    args = parser.parse_args()
-
-    if args.translate_only and args.consolidate_only:
-        raise ValueError(
-            "Cannot use both --translate-only and --consolidate-only at the same time."
-        )
-
-    main(
-        args.file_path,
-        translate_only=args.translate_only,
-        consolidate_only=args.consolidate_only,
-    )

docs/_scripts/js_translation/codeblocks/.gitkeep

@@ -1,6 +0,0 @@
-.prettierrc
-.eslint.config.mjs
-package.json
-README.md
-tsconfig.json
-yarn.lock

docs/_scripts/js_translation/codeblocks/.prettierrc

@@ -1,19 +0,0 @@
-{
-  "$schema": "https://json.schemastore.org/prettierrc",
-  "printWidth": 80,
-  "tabWidth": 2,
-  "useTabs": false,
-  "semi": true,
-  "singleQuote": false,
-  "quoteProps": "as-needed",
-  "jsxSingleQuote": false,
-  "trailingComma": "es5",
-  "bracketSpacing": true,
-  "arrowParens": "always",
-  "requirePragma": false,
-  "insertPragma": false,
-  "proseWrap": "preserve",
-  "htmlWhitespaceSensitivity": "css",
-  "vueIndentScriptAndStyle": false,
-  "endOfLine": "lf"
-}

docs/_scripts/js_translation/codeblocks/README.md

@@ -1 +0,0 @@
-# \_codeblocks

docs/_scripts/js_translation/codeblocks/eslint.config.mjs

@@ -1,14 +0,0 @@
-import js from "@eslint/js";
-import globals from "globals";
-import tseslint from "typescript-eslint";
-import { defineConfig } from "eslint/config";
-
-export default defineConfig([
-  {
-    files: ["**/*.{js,mjs,cjs,ts,mts,cts}"],
-    plugins: { js },
-    extends: ["js/recommended"],
-    languageOptions: { globals: globals.browser },
-  },
-  tseslint.configs.recommended,
-]);

docs/_scripts/js_translation/codeblocks/package.json

@@ -1,27 +0,0 @@
-{
-  "name": "_codeblocks",
-  "packageManager": "yarn@4.6.0",
-  "scripts": {
-    "lint": "eslint .",
-    "lint:fix": "eslint . --fix",
-    "format": "prettier --write .",
-    "format:fix": "prettier --write . --fix"
-  },
-  "dependencies": {
-    "@langchain/anthropic": "^0.3.24",
-    "@langchain/core": "^0.3.66",
-    "@langchain/langgraph": "^0.3.11",
-    "@langchain/langgraph-api": "^0.0.52",
-    "@langchain/langgraph-sdk": "^0.0.102",
-    "@langchain/openai": "^0.6.3",
-    "zod": "^4.0.10"
-  },
-  "devDependencies": {
-    "@eslint/js": "^9.32.0",
-    "eslint": "^9.32.0",
-    "globals": "^16.3.0",
-    "jiti": "^2.5.1",
-    "typescript": "^5.8.3",
-    "typescript-eslint": "^8.38.0"
-  }
-}

docs/_scripts/js_translation/codeblocks/tsconfig.json

@@ -1,114 +0,0 @@
-{
-  "compilerOptions": {
-    /* Visit https://aka.ms/tsconfig to read more about this file */
-
-    /* Projects */
-    // "incremental": true,                              /* Save .tsbuildinfo files to allow for incremental compilation of projects. */
-    // "composite": true,                                /* Enable constraints that allow a TypeScript project to be used with project references. */
-    // "tsBuildInfoFile": "./.tsbuildinfo",              /* Specify the path to .tsbuildinfo incremental compilation file. */
-    // "disableSourceOfProjectReferenceRedirect": true,  /* Disable preferring source files instead of declaration files when referencing composite projects. */
-    // "disableSolutionSearching": true,                 /* Opt a project out of multi-project reference checking when editing. */
-    // "disableReferencedProjectLoad": true,             /* Reduce the number of projects loaded automatically by TypeScript. */
-
-    /* Language and Environment */
-    "target": "esnext",                                  /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */
-    // "lib": [],                                        /* Specify a set of bundled library declaration files that describe the target runtime environment. */
-    // "jsx": "preserve",                                /* Specify what JSX code is generated. */
-    // "libReplacement": true,                           /* Enable lib replacement. */
-    // "experimentalDecorators": true,                   /* Enable experimental support for legacy experimental decorators. */
-    // "emitDecoratorMetadata": true,                    /* Emit design-type metadata for decorated declarations in source files. */
-    // "jsxFactory": "",                                 /* Specify the JSX factory function used when targeting React JSX emit, e.g. 'React.createElement' or 'h'. */
-    // "jsxFragmentFactory": "",                         /* Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. 'React.Fragment' or 'Fragment'. */
-    // "jsxImportSource": "",                            /* Specify module specifier used to import the JSX factory functions when using 'jsx: react-jsx*'. */
-    // "reactNamespace": "",                             /* Specify the object invoked for 'createElement'. This only applies when targeting 'react' JSX emit. */
-    // "noLib": true,                                    /* Disable including any library files, including the default lib.d.ts. */
-    // "useDefineForClassFields": true,                  /* Emit ECMAScript-standard-compliant class fields. */
-    // "moduleDetection": "auto",                        /* Control what method is used to detect module-format JS files. */
-
-    /* Modules */
-    "module": "nodenext",                                /* Specify what module code is generated. */
-    // "rootDir": "./",                                  /* Specify the root folder within your source files. */
-    "moduleResolution": "nodenext",                     /* Specify how TypeScript looks up a file from a given module specifier. */
-    // "baseUrl": "./",                                  /* Specify the base directory to resolve non-relative module names. */
-    // "paths": {},                                      /* Specify a set of entries that re-map imports to additional lookup locations. */
-    // "rootDirs": [],                                   /* Allow multiple folders to be treated as one when resolving modules. */
-    // "typeRoots": [],                                  /* Specify multiple folders that act like './node_modules/@types'. */
-    // "types": [],                                      /* Specify type package names to be included without being referenced in a source file. */
-    // "allowUmdGlobalAccess": true,                     /* Allow accessing UMD globals from modules. */
-    // "moduleSuffixes": [],                             /* List of file name suffixes to search when resolving a module. */
-    // "allowImportingTsExtensions": true,               /* Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set. */
-    // "rewriteRelativeImportExtensions": true,          /* Rewrite '.ts', '.tsx', '.mts', and '.cts' file extensions in relative import paths to their JavaScript equivalent in output files. */
-    // "resolvePackageJsonExports": true,                /* Use the package.json 'exports' field when resolving package imports. */
-    // "resolvePackageJsonImports": true,                /* Use the package.json 'imports' field when resolving imports. */
-    // "customConditions": [],                           /* Conditions to set in addition to the resolver-specific defaults when resolving imports. */
-    // "noUncheckedSideEffectImports": true,             /* Check side effect imports. */
-    // "resolveJsonModule": true,                        /* Enable importing .json files. */
-    // "allowArbitraryExtensions": true,                 /* Enable importing files with any extension, provided a declaration file is present. */
-    // "noResolve": true,                                /* Disallow 'import's, 'require's or '<reference>'s from expanding the number of files TypeScript should add to a project. */
-
-    /* JavaScript Support */
-    // "allowJs": true,                                  /* Allow JavaScript files to be a part of your program. Use the 'checkJS' option to get errors from these files. */
-    // "checkJs": true,                                  /* Enable error reporting in type-checked JavaScript files. */
-    // "maxNodeModuleJsDepth": 1,                        /* Specify the maximum folder depth used for checking JavaScript files from 'node_modules'. Only applicable with 'allowJs'. */
-
-    /* Emit */
-    // "declaration": true,                              /* Generate .d.ts files from TypeScript and JavaScript files in your project. */
-    // "declarationMap": true,                           /* Create sourcemaps for d.ts files. */
-    // "emitDeclarationOnly": true,                      /* Only output d.ts files and not JavaScript files. */
-    // "sourceMap": true,                                /* Create source map files for emitted JavaScript files. */
-    // "inlineSourceMap": true,                          /* Include sourcemap files inside the emitted JavaScript. */
-    // "noEmit": true,                                   /* Disable emitting files from a compilation. */
-    // "outFile": "./",                                  /* Specify a file that bundles all outputs into one JavaScript file. If 'declaration' is true, also designates a file that bundles all .d.ts output. */
-    // "outDir": "./",                                   /* Specify an output folder for all emitted files. */
-    // "removeComments": true,                           /* Disable emitting comments. */
-    // "importHelpers": true,                            /* Allow importing helper functions from tslib once per project, instead of including them per-file. */
-    // "downlevelIteration": true,                       /* Emit more compliant, but verbose and less performant JavaScript for iteration. */
-    // "sourceRoot": "",                                 /* Specify the root path for debuggers to find the reference source code. */
-    // "mapRoot": "",                                    /* Specify the location where debugger should locate map files instead of generated locations. */
-    // "inlineSources": true,                            /* Include source code in the sourcemaps inside the emitted JavaScript. */
-    // "emitBOM": true,                                  /* Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files. */
-    // "newLine": "crlf",                                /* Set the newline character for emitting files. */
-    // "stripInternal": true,                            /* Disable emitting declarations that have '@internal' in their JSDoc comments. */
-    // "noEmitHelpers": true,                            /* Disable generating custom helper functions like '__extends' in compiled output. */
-    // "noEmitOnError": true,                            /* Disable emitting files if any type checking errors are reported. */
-    // "preserveConstEnums": true,                       /* Disable erasing 'const enum' declarations in generated code. */
-    // "declarationDir": "./",                           /* Specify the output directory for generated declaration files. */
-
-    /* Interop Constraints */
-    // "isolatedModules": true,                          /* Ensure that each file can be safely transpiled without relying on other imports. */
-    // "verbatimModuleSyntax": true,                     /* Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the 'module' setting. */
-    // "isolatedDeclarations": true,                     /* Require sufficient annotation on exports so other tools can trivially generate declaration files. */
-    // "erasableSyntaxOnly": true,                       /* Do not allow runtime constructs that are not part of ECMAScript. */
-    // "allowSyntheticDefaultImports": true,             /* Allow 'import x from y' when a module doesn't have a default export. */
-    "esModuleInterop": true,                             /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables 'allowSyntheticDefaultImports' for type compatibility. */
-    // "preserveSymlinks": true,                         /* Disable resolving symlinks to their realpath. This correlates to the same flag in node. */
-    "forceConsistentCasingInFileNames": true,            /* Ensure that casing is correct in imports. */
-
-    /* Type Checking */
-    "strict": false,                                      /* Enable all strict type-checking options. */
-    // "noImplicitAny": true,                            /* Enable error reporting for expressions and declarations with an implied 'any' type. */
-    // "strictNullChecks": true,                         /* When type checking, take into account 'null' and 'undefined'. */
-    // "strictFunctionTypes": true,                      /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */
-    // "strictBindCallApply": true,                      /* Check that the arguments for 'bind', 'call', and 'apply' methods match the original function. */
-    // "strictPropertyInitialization": true,             /* Check for class properties that are declared but not set in the constructor. */
-    // "strictBuiltinIteratorReturn": true,              /* Built-in iterators are instantiated with a 'TReturn' type of 'undefined' instead of 'any'. */
-    // "noImplicitThis": true,                           /* Enable error reporting when 'this' is given the type 'any'. */
-    // "useUnknownInCatchVariables": true,               /* Default catch clause variables as 'unknown' instead of 'any'. */
-    // "alwaysStrict": true,                             /* Ensure 'use strict' is always emitted. */
-    // "noUnusedLocals": true,                           /* Enable error reporting when local variables aren't read. */
-    // "noUnusedParameters": true,                       /* Raise an error when a function parameter isn't read. */
-    // "exactOptionalPropertyTypes": true,               /* Interpret optional property types as written, rather than adding 'undefined'. */
-    // "noImplicitReturns": true,                        /* Enable error reporting for codepaths that do not explicitly return in a function. */
-    // "noFallthroughCasesInSwitch": true,               /* Enable error reporting for fallthrough cases in switch statements. */
-    // "noUncheckedIndexedAccess": true,                 /* Add 'undefined' to a type when accessed using an index. */
-    // "noImplicitOverride": true,                       /* Ensure overriding members in derived classes are marked with an override modifier. */
-    // "noPropertyAccessFromIndexSignature": true,       /* Enforces using indexed accessors for keys declared using an indexed type. */
-    // "allowUnusedLabels": true,                        /* Disable error reporting for unused labels. */
-    // "allowUnreachableCode": true,                     /* Disable error reporting for unreachable code. */
-
-    /* Completeness */
-    // "skipDefaultLibCheck": true,                      /* Skip type checking .d.ts files that are included with TypeScript. */
-    "skipLibCheck": true                                 /* Skip type checking all .d.ts files. */
-    ""
-  }
-}

docs/_scripts/js_translation/extract_codeblocks.py

@@ -1,150 +0,0 @@
-#!/usr/bin/env python
-"""Extracts typescript code blocks from a markdown file."""
-
-import argparse
-import json
-import re
-import os
-from typing import List, TypedDict, Literal
-
-
-class CodeBlock(TypedDict):
-    """A code block extracted from a markdown file."""
-    starting_line: int
-    """The line number where the code block starts in the source file"""
-    ending_line: int
-    """The line number where the code block ends in the source file"""
-    indentation: int
-    """Number of spaces/tabs used for indentation of the code block"""
-    source_file: str
-    """Path to the markdown file containing this code block"""
-    frontmatter: str
-    """Any metadata or frontmatter specified after the opening code fence"""
-    code: str
-    """The actual code content within the code block"""
-    language: str
-    """The language of the code block (e.g. typescript, javascript)"""
-
-
-def extract_code_blocks(markdown_content: str, source_file: str) -> List[CodeBlock]:
-    """Extracts code blocks from a markdown file.
-
-    Args:
-        markdown_content: The content of the markdown file.
-        source_file: The path to the markdown file.
-
-    Returns:
-        A list of TypedDicts, where each dict represents a code block.
-    """
-    # Regex to find code blocks with specified languages, capturing indentation
-    # and frontmatter.
-    pattern = re.compile(
-        r"^(?P<indentation>\s*)```(?P<language>typescript|javascript|ts|js)(?P<frontmatter>[^\n]*)\n(?P<code>.*?)\n^(?P=indentation)```\s*$",
-        re.DOTALL | re.MULTILINE,
-    )
-
-    code_blocks: List[CodeBlock] = []
-    for match in pattern.finditer(markdown_content):
-        start_pos = match.start()
-
-        # Calculate line numbers
-        starting_line = markdown_content.count("\n", 0, start_pos) + 1
-        ending_line = starting_line + match.group(0).count("\n")
-
-        indentation_str = match.group("indentation")
-
-        code_block: CodeBlock = {
-            "starting_line": starting_line,
-            "ending_line": ending_line,
-            "indentation": len(indentation_str),
-            "source_file": source_file,
-            "frontmatter": match.group("frontmatter").strip(),
-            "code": match.group("code"),
-            "language": match.group("language"),
-        }
-        code_blocks.append(code_block)
-
-    return code_blocks
-
-def dump_code_blocks(input_file: str, output_file: str, format: Literal["json", "inline"]) -> None:
-    """Function to extract and save code blocks from a markdown file.
-
-    Args:
-        input_file: Path to the input markdown file.
-        output_file: Path to the output JSON file for the extracted code blocks.
-        format: Output format - either "json" or "inline"
-    """
-    with open(input_file, "r", encoding="utf-8") as f:
-        markdown_content = f.read()
-
-    extracted_code = extract_code_blocks(markdown_content, input_file)
-
-    if len(extracted_code) == 0:
-        print(f"No code blocks found in {input_file}")
-        return
-    
-    if format == "json":
-        with open(output_file, "w", encoding="utf-8") as f:
-            json.dump(extracted_code, f, indent=2)
-    elif format == "inline":
-        with open(output_file, "w", encoding="utf-8") as f:
-            for code_block in extracted_code:
-                f.write(f"// {json.dumps({k:v for k,v in code_block.items() if k != 'code'})}\n")
-                f.write("\n")
-                f.write(code_block["code"])
-                f.write("\n")
-    print(f"Extracted {len(extracted_code)} code blocks from {input_file} to {output_file}")
-
-def main(input_path: str, output_path: str, format: Literal["json", "inline"]) -> None:
-    """Main function to extract code blocks from a markdown file.
-
-    Args:
-        input_file: Path to the input markdown file.
-        output_file: Path to the output JSON file for the extracted code blocks.
-        format: Output format - either "json" or "inline"
-    """
-    # Check if input path is a directory
-    if os.path.isdir(input_path):
-        if os.path.isfile(output_path):
-            raise ValueError("If input_path is a directory, output_path must also be a directory")
-        if not os.path.isdir(output_path):
-            os.makedirs(output_path, exist_ok=True)
-        
-        # Process each markdown file in the directory recursively
-        for root, _, files in os.walk(input_path):
-            for filename in files:
-                if filename.endswith(".md"):
-                    # Get relative path to maintain directory structure
-                    rel_path = os.path.relpath(root, input_path)
-                    input_file = os.path.join(root, filename)
-                    # Create output directory if it doesn't exist
-                    output_dir = os.path.join(output_path, rel_path)
-                    os.makedirs(output_dir, exist_ok=True)
-                    output_file = os.path.join(output_dir, filename.replace(".md", ".ts"))
-                    dump_code_blocks(input_file, output_file, format)
-    else:
-        # Process single file
-        dump_code_blocks(input_path, output_path, format)
-
-
-if __name__ == "__main__":
-    parser = argparse.ArgumentParser(
-        description="Extract typescript code blocks from a markdown file."
-    )
-    parser.add_argument(
-        "input_file",
-        help="Path to the input markdown file.",
-    )
-    parser.add_argument(
-        "output_file",
-        help="Path to the output JSON file for the extracted code blocks.",
-    )
-    parser.add_argument(
-        "--format",
-        choices=["json", "inline"],
-        default="json",
-        help="Output format - either 'json' or 'inline'",
-    )
-    args = parser.parse_args()
-
-    main(args.input_file, args.output_file, args.format)

docs/_scripts/link_map.py

@@ -1,5 +0,0 @@
-JS_LINK_MAP = {
-    "langgraph.types.interrupt": "https://langchain-ai.github.io/langgraphjs/reference/functions/langgraph.interrupt-2.html",
-    "create_react_agent": "https://langchain-ai.github.io/langgraphjs/reference/functions/langgraph_prebuilt.createReactAgent.html",
-    "langgraph.types.Command": "https://langchain-ai.github.io/langgraphjs/reference/classes/langgraph.Command.html",
-}

docs/_scripts/notebook_hooks.py

@@ -1,21 +1,13 @@
-"""mkdocs hooks for adding custom logic to documentation pipeline.
-
-Lifecycle events: https://www.mkdocs.org/dev-guide/plugins/#events
-"""
-
 import logging
 import os
 import posixpath
 import re
 from typing import Any, Dict
 
-from bs4 import BeautifulSoup
-from mkdocs.config.defaults import MkDocsConfig
 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.link_map import JS_LINK_MAP
 from _scripts.notebook_convert import convert_notebook
 
 logger = logging.getLogger(__name__)
@@ -49,24 +41,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 +79,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",
@@ -114,15 +100,9 @@ REDIRECT_MAP = {
     # 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",
+    "cloud/how-tos/assistant_versioning.md": "cloud/how-tos/configuration_cloud.md"
+
 }
 
 
@@ -172,62 +152,6 @@ def _add_path_to_code_blocks(markdown: str, page: Page) -> str:
     return code_block_pattern.sub(replace_code_block_header, markdown)
 
 
-def _resolve_cross_references(md_text: str, link_map: dict[str, str]) -> str:
-    """Replace [title][identifier] with [title](url) using language-specific link_map.
-
-    Args:
-        md_text: The markdown text to process.
-        link_map: mapping of identifier to URL.
-
-    Returns:
-        The processed markdown text with cross-references resolved.
-    """
-    # Pattern to match [title][identifier]
-    pattern = re.compile(r"\[([^\]]+)\]\[([^\]]+)\]")
-
-    def replace_reference(match: re.Match) -> str:
-        """Replace the matched reference with the corresponding URL."""
-        title, identifier = match.group(1), match.group(2)
-        url = link_map.get(identifier)
-
-        if url:
-            return f"[{title}]({url})"
-        else:
-            # Leave it unchanged if not found
-            return match.group(0)
-
-    return pattern.sub(replace_reference, md_text)
-
-
-def _apply_conditional_rendering(md_text: str, target_language: str) -> str:
-    if target_language not in {"python", "js"}:
-        raise ValueError("target_language must be 'python' or 'js'")
-
-    pattern = re.compile(
-        r"(?P<indent>[ \t]*):::(?P<language>\w+)\s*\n"
-        r"(?P<content>((?:.*\n)*?))"  # Capture the content inside the block
-        r"(?P=indent):::"  # Match closing with the same indentation
-    )
-
-    def replace_conditional_blocks(match: re.Match) -> str:
-        """Keep active conditionals."""
-        language = match.group("language")
-        content = match.group("content")
-
-        if language not in {"python", "js"}:
-            # If the language is not supported, return the original block
-            return match.group(0)
-
-        if language == target_language:
-            return content
-
-        # If the language does not match, return an empty string
-        return ""
-
-    processed = pattern.sub(replace_conditional_blocks, md_text)
-    return processed
-
-
 def _highlight_code_blocks(markdown: str) -> str:
     """Find code blocks with highlight comments and add hl_lines attribute.
 
@@ -306,12 +230,6 @@ def _highlight_code_blocks(markdown: str) -> str:
     return markdown
 
 
-TARGET_LANGUAGE = os.environ.get("TARGET_LANGUAGE", "python")
-
-if TARGET_LANGUAGE not in {"python", "js"}:
-    raise ValueError(f"TARGET_LANGUAGE must be 'python' or 'js', got {TARGET_LANGUAGE}")
-
-
 def _on_page_markdown_with_config(
     markdown: str,
     page: Page,
@@ -333,19 +251,6 @@ def _on_page_markdown_with_config(
     # Apply highlight comments to code blocks
     markdown = _highlight_code_blocks(markdown)
 
-    # Apply conditional rendering for code blocks
-    markdown = _apply_conditional_rendering(markdown, TARGET_LANGUAGE)
-    if TARGET_LANGUAGE == "js":
-        markdown = _resolve_cross_references(markdown, JS_LINK_MAP)
-    elif TARGET_LANGUAGE == "python":
-        # Via a dedicated plugin
-        pass
-    else:
-        raise ValueError(
-            f"Unsupported target language: {TARGET_LANGUAGE}. "
-            "Supported languages are 'python' and 'js'."
-        )
-
     # Add file path as an attribute to code blocks that are executable.
     # This file path is used to associate fixtures with the executable code
     # which can be used in CI to test the docs without making network requests.
@@ -387,7 +292,7 @@ Redirecting...
 """
 
 
-def _write_html(site_dir, old_path, new_path):
+def write_html(site_dir, old_path, new_path):
     """Write an HTML file in the site_dir with a meta redirect to the new page"""
     # Determine all relevant paths
     old_path_abs = os.path.join(site_dir, old_path)
@@ -403,52 +308,6 @@ def _write_html(site_dir, old_path, new_path):
         f.write(content)
 
 
-def _inject_gtm(html: str) -> str:
-    """Inject Google Tag Manager code into the HTML.
-
-    Code to inject Google Tag Manager noscript tag immediately after <body>.
-
-    This is done via hooks rather than via a template because the MkDocs material
-    theme does not seem to allow placing the code immediately after the <body> tag
-    without modifying the template files directly.
-
-    Args:
-        html: The HTML content to modify.
-
-    Returns:
-        The modified HTML content with GTM code injected.
-    """
-    # Code was copied from Google Tag Manager setup instructions.
-    gtm_code = """
-<!-- Google Tag Manager (noscript) -->
-<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-T35S4S46"
-height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
-<!-- End Google Tag Manager (noscript) -->
-"""
-    soup = BeautifulSoup(html, "html.parser")
-    body = soup.body
-    if body:
-        # Insert the GTM code as raw HTML at the top of <body>
-        body.insert(0, BeautifulSoup(gtm_code, "html.parser"))
-        return str(soup)
-    else:
-        return html  # fallback if no <body> found
-
-
-def on_post_page(output: str, page: Page, config: MkDocsConfig) -> str:
-    """Inject Google Tag Manager noscript tag immediately after <body>.
-
-    Args:
-        output: The HTML output of the page.
-        page: The page instance.
-        config: The MkDocs configuration object.
-
-    Returns:
-        modified HTML output with GTM code injected.
-    """
-    return _inject_gtm(output)
-
-
 # Create HTML files for redirects after site dir has been built
 def on_post_build(config):
     use_directory_urls = config.get("use_directory_urls")
@@ -465,4 +324,4 @@ def on_post_build(config):
             + hash
             + suffix
         )
-        _write_html(config["site_dir"], old_html_path, new_html_path)
+        write_html(config["site_dir"], old_html_path, new_html_path)

docs/_scripts/third_party_page/create_third_party_page.py

@@ -15,10 +15,9 @@ If you’re looking for other prebuilt libraries, explore the community-built op
 below. These libraries can extend LangGraph's functionality in various ways.
 
 ## 📚 Available Libraries
+
 [//]: # (This file is automatically generated using a script in docs/_scripts. Do not edit this file directly!)
-
-:::python
-{python_library_list}
+{library_list}
 
 ## ✨ Contributing Your Library
 
@@ -29,39 +28,16 @@ To share your project, simply open a Pull Request adding an entry for your packa
 
 **Guidelines**
 
-- Your repo must be distributed as an installable package on PyPI 📦
+- Your repo must be distributed as an installable package (e.g., PyPI for Python, npm 
+  for JavaScript/TypeScript, etc.) 📦
 - The repo should either use the Graph API (exposing a `StateGraph` instance) or 
   the Functional API (exposing an `entrypoint`).
 - The package must include documentation (e.g., a `README.md` or docs site) 
   explaining how to use it.
-
+  
 We'll review your contribution and merge it in!
 
 Thanks for contributing! 🚀
-:::
-
-:::js
-{js_library_list}
-
-## ✨ 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! 🏆
-
-To share your project, simply open a Pull Request adding an entry for your package in our [packages.yml]({langgraph_url}) file.
-
-**Guidelines**
-
-- Your repo must be distributed as an installable package on npm 📦
-- The repo should either use the Graph API (exposing a `StateGraph` instance) or 
-  the Functional API (exposing an `entrypoint`).
-- The package must include documentation (e.g., a `README.md` or docs site) 
-  explaining how to use it.
-
-We'll review your contribution and merge it in!
-
-Thanks for contributing! 🚀
-:::
 """
 
 
@@ -70,18 +46,36 @@ class ResolvedPackage(TypedDict):
     """The name of the package."""
     repo: str
     """Repository ID within github. Format is: [orgname]/[repo_name]."""
-    monorepo_path: str | None
-    """Optional: The path to the package in the monorepo. Must be relative to the root of the monorepo."""
-    language: str
-    """The language of the package. (either 'python' or 'js')"""
     weekly_downloads: int | None
     """The weekly download count of the package."""
     description: str
     """A brief description of what the package does."""
 
-def generate_package_table(resolved_packages: List[ResolvedPackage]) -> str:
-    """Generate the package table for the third party page.
+
+def generate_markdown(resolved_packages: List[ResolvedPackage], language: str) -> str:
+    """Generate the markdown content for the third party page.
+
+    Args:
+        resolved_packages: A list of resolved package information.
+        language: str
+
+    Returns:
+        The markdown content as a string.
     """
+    # Update the URL to the actual file once the initial version is merged
+    if language == "python":
+        langgraph_url = (
+            "https://github.com/langchain-ai/langgraph/blob/main/docs"
+            "/_scripts/third_party_page/packages.yml"
+        )
+    elif language == "js":
+        langgraph_url = (
+            "https://github.com/langchain-ai/langgraphjs/blob/main/docs"
+            "/_scripts/third_party/packages.yml"
+        )
+    else:
+        raise ValueError(f"Invalid language '{language}'. Expected 'python' or 'js'.")
+
     sorted_packages = sorted(
         resolved_packages, key=lambda p: p["weekly_downloads"] or 0, reverse=True
     )
@@ -91,15 +85,7 @@ def generate_package_table(resolved_packages: List[ResolvedPackage]) -> str:
     ]
     for package in sorted_packages:
         name = f"**{package['name']}**"
-        
-        monorepo_path = package.get("monorepo_path", "")
-        if monorepo_path:
-            monorepo_path = monorepo_path[1:] if monorepo_path.startswith('/') else monorepo_path
-            repo_url_suffix = f"/tree/main/{monorepo_path}"
-        else:
-            repo_url_suffix = ""
-        repo_url = f"https://github.com/{package['repo']}{repo_url_suffix}"
-
+        repo_url = f"[{package['repo']}](https://github.com/{package['repo']})"
         stars_badge = (
             f"https://img.shields.io/github/stars/{package['repo']}?style=social"
         )
@@ -107,39 +93,13 @@ def generate_package_table(resolved_packages: List[ResolvedPackage]) -> str:
         downloads = package["weekly_downloads"] or "-"
         row = f"| {name} | {repo_url} | {package['description']} | {downloads} | {stars}"
         rows.append(row)
-    return "\n".join(rows)
-
-def generate_markdown(resolved_packages: List[ResolvedPackage]) -> str:
-    """Generate the markdown content for the third party page.
-
-    Args:
-        resolved_packages: A list of resolved package information.
-
-    Returns:
-        The markdown content as a string.
-    """
-    # Update the URL to the actual file once the initial version is merged
-    langgraph_url = (
-        "https://github.com/langchain-ai/langgraph/blob/main/docs"
-        "/_scripts/third_party_page/packages.yml"
-    )
-
-    python_library_list = generate_package_table(
-        [p for p in resolved_packages if p["language"] == "python"]
-    )
-    js_library_list = generate_package_table(
-        [p for p in resolved_packages if p["language"] == "js"]
-    )
-    
     markdown_content = MARKDOWN.format(
-        python_library_list=python_library_list,
-        js_library_list=js_library_list,
-        langgraph_url=langgraph_url,
+        library_list="\n".join(rows), langgraph_url=langgraph_url
     )
     return markdown_content
 
 
-def main(input_file: str, output_file: str) -> None:
+def main(input_file: str, output_file: str, language: str) -> None:
     """Main function to create the third party page.
 
     Args:
@@ -151,7 +111,7 @@ def main(input_file: str, output_file: str) -> None:
     with open(input_file, "r") as f:
         resolved_packages: List[ResolvedPackage] = yaml.safe_load(f)
 
-    markdown_content = generate_markdown(resolved_packages)
+    markdown_content = generate_markdown(resolved_packages, language)
 
     # Write the markdown content to the output file
     with open(output_file, "w", encoding="utf-8") as f:
@@ -167,6 +127,12 @@ if __name__ == "__main__":
     parser.add_argument(
         "output_file", help="Path to the output file for the third party page."
     )
+    parser.add_argument(
+        "--language",
+        choices=["python", "js"],
+        default="python",
+        help="The language for which to generate the third party page. Defaults to 'python'.",
+    )
     args = parser.parse_args()
 
-    main(args.input_file, args.output_file)
+    main(args.input_file, args.output_file, args.language)

docs/_scripts/third_party_page/get_download_stats.py

@@ -11,146 +11,101 @@ import yaml
 
 
 class Package(TypedDict):
+    """A TypedDict representing a package"""
+
     name: str
     """The name of the package."""
     repo: str
     """Repository ID within github. Format is: [orgname]/[repo_name]."""
-    monorepo_path: str | None
-    """The path to the package in the monorepo. Only used for JS packages."""
     description: str
     """A brief description of what the package does."""
 
+
 class ResolvedPackage(Package):
     weekly_downloads: int | None
-    """The weekly download count of the package."""
-    language: str
-    """The language of the package. (either 'python' or 'js')"""
+
 
 HERE = pathlib.Path(__file__).parent
 PACKAGES_FILE = HERE / "packages.yml"
-PACKAGES = yaml.safe_load(PACKAGES_FILE.read_text())["packages"]
+PACKAGES = yaml.safe_load(PACKAGES_FILE.read_text())['packages']
 
-def _get_pypi_downloads(package: Package) -> int:
-    """Retrieve the weekly download count for a package from PyPIStats."""
 
-    # First check if package exists on PyPI
-    pypi_url = f"https://pypi.org/pypi/{package['name']}/json"
-    try:
-        pypi_response = requests.get(pypi_url)
-        pypi_response.raise_for_status()
-    except requests.exceptions.HTTPError:
-        raise AssertionError(f"Package {package['name']} does not exist on PyPI")
-
-    # Get first release date
-    pypi_data = pypi_response.json()
-    releases = pypi_data["releases"]
-    first_release_date = None
-    for version_releases in releases.values():
-        if version_releases:  # Some versions may be empty lists
-            upload_time = datetime.fromisoformat(version_releases[0]["upload_time"])
-            if first_release_date is None or upload_time < first_release_date:
-                first_release_date = upload_time
-
-    if first_release_date is None:
-        raise AssertionError(f"Package {package['name']} has no releases yet")
-
-    # If package was published in last 48 hours, skip download stats
-    if (datetime.now() - first_release_date).total_seconds() >= 48 * 3600:
-        url = f"https://pypistats.org/api/packages/{package['name']}/overall"
-
-        response = requests.get(url)
-        response.raise_for_status()
-        data = response.json()
-
-        sorted_data = sorted(
-            data["data"],
-            key=lambda x: datetime.strptime(x["date"], "%Y-%m-%d"),
-            reverse=True,
-        )
-
-        # Sum the last 7 days of downloads
-        return sum(entry["downloads"] for entry in sorted_data[:7])
-    else:
-        return None
-    
-def _get_npm_downloads(package: Package) -> int:
-    """Retrieve the weekly download count for a package on the npm registry."""
-
-    # Check if package exists on the npm registry
-    npm_url = f"https://registry.npmjs.org/{package['name']}"
-    try:
-        npm_response = requests.get(npm_url)
-        npm_response.raise_for_status()
-    except requests.exceptions.HTTPError:
-        raise AssertionError(f"Package {package['name']} does not exist on npm registry")
-
-    npm_data = npm_response.json()
-
-    # Retrieve the first publish date using the 'created' timestamp from the 'time' field.
-    created_str = npm_data.get("time", {}).get("created")
-    if created_str is None:
-        raise AssertionError(f"Package {package['name']} has no creation time in registry data")
-    # Remove the trailing 'Z' if present and parse the ISO format timestamp
-    first_publish_date = datetime.fromisoformat(created_str.rstrip("Z"))
-
-    # If package was published more than 48 hours ago, fetch download stats.
-    if (datetime.now() - first_publish_date).total_seconds() >= 48 * 3600:
-        stats_url = f"https://api.npmjs.org/downloads/point/last-week/{package['name']}"
-        stats_response = requests.get(stats_url)
-        stats_response.raise_for_status()
-        stats_data = stats_response.json()
-        return stats_data.get("downloads", None)
-    else:
-        return None
-
-def _get_weekly_downloads(packages: dict[str, list[Package]], fake: bool) -> list[ResolvedPackage]:
-    """Retrieve the weekly download count for a dictionary of python or js packages."""
+def _get_weekly_downloads(packages: list[Package], fake: bool) -> list[ResolvedPackage]:
+    """Retrieve the monthly download count for a list of packages from PyPIStats."""
     resolved_packages: list[ResolvedPackage] = []
 
     if fake:
         # To avoid making network requests during testing, return fake download counts
-        for language, package_list in packages.items():
-            for package in package_list:
-                resolved_packages.append(
-                    {
-                        "name": package["name"],
-                        "repo": package["repo"],
-                        "monorepo_path": package.get("monorepo_path", None),
-                        "language": language,
-                        "description": package["description"],
-                        "weekly_downloads": -12345,
-                    }
-                )
-        return resolved_packages
-
-    for language, package_list in packages.items():
-        for package in package_list:
-            if language == "python":
-                num_downloads = _get_pypi_downloads(package)
-            elif language == "js":
-                num_downloads = _get_npm_downloads(package)
-            else:
-                num_downloads = None
-            
+        for package in packages:
             resolved_packages.append(
                 {
                     "name": package["name"],
                     "repo": package["repo"],
-                    "monorepo_path": package.get("monorepo_path", None),
-                    "language": language,
+                    "weekly_downloads": -12345,
                     "description": package["description"],
-                    "weekly_downloads": num_downloads,
                 }
             )
+        return resolved_packages
+
+    for package in packages:
+        # First check if package exists on PyPI
+        pypi_url = f"https://pypi.org/pypi/{package['name']}/json"
+        try:
+            pypi_response = requests.get(pypi_url)
+            pypi_response.raise_for_status()
+        except requests.exceptions.HTTPError:
+            raise AssertionError(f"Package {package['name']} does not exist on PyPI")
+
+        # Get first release date
+        pypi_data = pypi_response.json()
+        releases = pypi_data["releases"]
+        first_release_date = None
+        for version_releases in releases.values():
+            if version_releases:  # Some versions may be empty lists
+                upload_time = datetime.fromisoformat(version_releases[0]["upload_time"])
+                if first_release_date is None or upload_time < first_release_date:
+                    first_release_date = upload_time
+
+        if first_release_date is None:
+            raise AssertionError(f"Package {package['name']} has no releases yet")
+
+        # If package was published in last 48 hours, skip download stats
+        if (datetime.now() - first_release_date).total_seconds() >= 48 * 3600:
+            url = f"https://pypistats.org/api/packages/{package['name']}/overall"
+
+            response = requests.get(url)
+            response.raise_for_status()
+            data = response.json()
+
+            sorted_data = sorted(
+                data["data"],
+                key=lambda x: datetime.strptime(x["date"], "%Y-%m-%d"),
+                reverse=True,
+            )
+
+            # Sum the last 7 days of downloads
+            num_downloads = sum(entry["downloads"] for entry in sorted_data[:7])
+        else:
+            num_downloads = None
+
+        resolved_packages.append(
+            {
+                "name": package["name"],
+                "repo": package["repo"],
+                "weekly_downloads": num_downloads,
+                "description": package["description"],
+            }
+        )
 
     return resolved_packages
 
+
+
 def main(output_file: str, fake: bool) -> None:
     """Main function to generate package download information.
 
     Args:
         output_file: Path to the output YAML file.
-        fake: If True, use fake download counts for testing purposes.
     """
     resolved_packages: list[ResolvedPackage] = _get_weekly_downloads(PACKAGES, fake)
 

docs/_scripts/third_party_page/packages.yml

@@ -1,58 +1,41 @@
 #A list of third-party packages to surface on the third-party page.
 packages:
-  python:
-    - name: "trustcall"
-      repo: "hinthornw/trustcall"
-      description: "Tenacious tool calling built on LangGraph."
-    - name: "breeze-agent"
-      repo: "andrestorres123/breeze-agent"
-      description: "A streamlined research system built inspired on STORM and built on LangGraph."
-    - name: "langgraph-supervisor"
-      repo: "langchain-ai/langgraph-supervisor-py"
-      description: "Build supervisor multi-agent systems with LangGraph."
-    - name: "langmem"
-      repo: "langchain-ai/langmem"
-      description: "Build agents that learn and adapt from interactions over time."
-    - name: "langchain-mcp-adapters"
-      repo: "langchain-ai/langchain-mcp-adapters"
-      description: "Make Anthropic Model Context Protocol (MCP) tools compatible with LangGraph agents."
-    - name: "open-deep-research"
-      repo: "langchain-ai/open_deep_research"
-      description: "Open source assistant for iterative web research and report writing."
-    - name: "langgraph-swarm"
-      repo: "langchain-ai/langgraph-swarm-py"
-      description: "Build swarm-style multi-agent systems using LangGraph."
-    - name: "delve-taxonomy-generator"
-      repo: "andrestorres123/delve"
-      description: "A taxonomy generator for unstructured data"
-    - name: "nodeology"
-      repo: "xyin-anl/Nodeology"
-      description: "Enable researcher to build scientific workflows easily with simplified interface."
-    - name: "langgraph-bigtool"
-      repo: "langchain-ai/langgraph-bigtool"
-      description: "Build LangGraph agents with large numbers of tools."
-    - name: "ai-data-science-team"
-      repo: "business-science/ai-data-science-team"
-      description: "An AI-powered data science team of agents to help you perform common data science tasks 10X faster."
-    - name: "langgraph-reflection"
-      repo: "langchain-ai/langgraph-reflection"
-      description: "LangGraph agent that runs a reflection step."
-    - name: "langgraph-codeact"
-      repo: "langchain-ai/langgraph-codeact"
-      description: "LangGraph implementation of CodeAct agent that generates and executes code instead of tool calling."
-  js:
-    - name: "@langchain/mcp-adapters"
-      repo: "langchain-ai/langchainjs"
-      description: "Make Anthropic Model Context Protocol (MCP) tools compatible with LangGraph agents."
-    - name: "@langchain/langgraph-supervisor"
-      repo: "langchain-ai/langgraphjs"
-      monorepo_path: "libs/langgraph-supervisor"
-      description: "Build supervisor multi-agent systems with LangGraph"
-    - name: "@langchain/langgraph-swarm"
-      repo: "langchain-ai/langgraphjs"
-      monorepo_path: "libs/langgraph-swarm"
-      description: "Build multi-agent swarms with LangGraph"
-    - name: "@langchain/langgraph-cua"
-      repo: "langchain-ai/langgraphjs"
-      monorepo_path: "libs/langgraph-cua"
-      description: "Build computer use agents with LangGraph"
+  - name: "trustcall"
+    repo: "hinthornw/trustcall"
+    description: "Tenacious tool calling built on LangGraph."
+  - name: "breeze-agent"
+    repo: "andrestorres123/breeze-agent"
+    description: "A streamlined research system built inspired on STORM and built on LangGraph."
+  - name: "langgraph-supervisor"
+    repo: "langchain-ai/langgraph-supervisor-py"
+    description: "Build supervisor multi-agent systems with LangGraph."
+  - name: "langmem"
+    repo: "langchain-ai/langmem"
+    description: "Build agents that learn and adapt from interactions over time."
+  - name: "langchain-mcp-adapters"
+    repo: "langchain-ai/langchain-mcp-adapters"
+    description: "Make Anthropic Model Context Protocol (MCP) tools compatible with LangGraph agents."
+  - name: "open-deep-research"
+    repo: "langchain-ai/open_deep_research"
+    description: "Open source assistant for iterative web research and report writing."
+  - name: "langgraph-swarm"
+    repo: "langchain-ai/langgraph-swarm-py"
+    description: "Build swarm-style multi-agent systems using LangGraph."
+  - name: "delve-taxonomy-generator"
+    repo: "andrestorres123/delve"
+    description: "A taxonomy generator for unstructured data"
+  - name: "nodeology"
+    repo: "xyin-anl/Nodeology"
+    description: "Enable researcher to build scientific workflows easily with simplified interface."
+  - name: "langgraph-bigtool"
+    repo: "langchain-ai/langgraph-bigtool"
+    description: "Build LangGraph agents with large numbers of tools."
+  - name: "ai-data-science-team"
+    repo: "business-science/ai-data-science-team"
+    description: "An AI-powered data science team of agents to help you perform common data science tasks 10X faster."
+  - name: "langgraph-reflection"
+    repo: "langchain-ai/langgraph-reflection"
+    description: "LangGraph agent that runs a reflection step."
+  - name: "langgraph-codeact"
+    repo: "langchain-ai/langgraph-codeact"
+    description: "LangGraph implementation of CodeAct agent that generates and executes code instead of tool calling."

docs/cross-refs.txt

@@ -1,101 +0,0 @@
-[`add_conditional_edges`][langgraph.graph.StateGraph.add_conditional_edges]
-[add_conditional_edges][langgraph.graph.StateGraph.add_conditional_edges]
-[`add_edge`][langgraph.graph.StateGraph.add_edge]
-[add_edge][langgraph.graph.StateGraph.add_edge]
-[`add_messages`][langgraph.graph.message.add_messages]
-[add_node][langgraph.graph.StateGraph.add_node]
-[API reference][langgraph.prebuilt.tool_node.ToolNode]
-[API reference][toolnode]
-[`astream()`][langgraph.graph.state.CompiledStateGraph.astream]
-[`.astream()`][langgraph.pregel.Pregel.astream]
-[AsyncPostgresSaver][langgraph.checkpoint.postgres.aio.AsyncPostgresSaver]
-[AsyncSqliteSaver][langgraph.checkpoint.sqlite.aio.AsyncSqliteSaver]
-[BaseCheckpointSaver][<insert-ref>]
-[BaseCheckpointSaver][langgraph.checkpoint.base.BaseCheckpointSaver]
-[BaseStore][langgraph.store.base.BaseStore]
-[BaseStore.put][<insert-ref>]
-[BaseStore.put][langgraph.store.base.BaseStore.put]
-[BinaryOperatorAggregate][<insert-ref>]
-[BinaryOperatorAggregate][langgraph.channels.BinaryOperatorAggregate]
-[`CipherProtocol`][langgraph.checkpoint.serde.base.CipherProtocol]
-[`client.runs.stream`][langgraph_sdk.client.RunsClient.stream]
-[`client.runs.wait`][langgraph_sdk.client.RunsClient.wait]
-[`client.threads.get_history`][langgraph_sdk.client.ThreadsClient.get_history]
-[`client.threads.update_state`][langgraph_sdk.client.ThreadsClient.update_state]
-[`Command`][<insert-ref>]
-[`Command`][langgraph.types.Command]
-[Command][langgraph.types.Command]
-[CompiledStateGraph][langgraph.graph.state.CompiledStateGraph]
-[`createReactAgent`][<insert-ref>]
-[`create_react_agent`][langgraph.prebuilt.chat_agent_executor.create_react_agent]
-[create_react_agent][langgraph.prebuilt.chat_agent_executor.create_react_agent]
-[`create_supervisor`][langgraph_supervisor.supervisor.create_supervisor]
-[`EncryptedSerializer`][langgraph.checkpoint.serde.encrypted.EncryptedSerializer]
-[`entrypoint.final`][langgraph.func.entrypoint.final]
-[`entrypoint`][<insert-ref>]
-[entrypoint][<insert-ref>]
-[`@entrypoint`][langgraph.func.entrypoint]
-[`entrypoint`][langgraph.func.entrypoint]
-[entrypoint()][langgraph.func.entrypoint]
-[entrypoint][langgraph.func.entrypoint]
-[finalResult['values']['messages']
-[`from_pycryptodome_aes`][langgraph.checkpoint.serde.encrypted.EncryptedSerializer.from_pycryptodome_aes]
-[`getContextVariable`][<insert-ref>]
-[`getStateHistory()`][<insert-ref>]
-[`get_state_history()`][langgraph.graph.state.CompiledStateGraph.get_state_history]
-[get_stream_writer][langgraph.config.get_stream_writer]
-[`HumanInterrupt`][langgraph.prebuilt.interrupt.HumanInterrupt]
-[`HumanInterrupt` schema][langgraph.prebuilt.interrupt.HumanInterrupt]
-[HumanMessage(content=state[\"messages\"][-2]
-[`InjectedState`][langgraph.prebuilt.InjectedState]
-[InjectedState][langgraph.prebuilt.InjectedState]
-[InMemorySaver][langgraph.checkpoint.memory.InMemorySaver]
-[`interrupt` function][<insert-ref>]
-[`interrupt` function][langgraph.types.interrupt]
-[`interrupt()`][langgraph.types.interrupt]
-[`interrupt`][langgraph.types.interrupt]
-[interrupt][langgraph.types.interrupt]
-[`invoke`][<insert-ref>]
-[`invoke`][langgraph.graph.state.CompiledStateGraph.invoke]
-[`JsonPlusSerializer`][langgraph.checkpoint.serde.jsonplus.JsonPlusSerializer]
-[JsonPlusSerializer][langgraph.checkpoint.serde.jsonplus.JsonPlusSerializer]
-[langgraph.json CLI reference][configuration-file]
-[LastValue][<insert-ref>]
-[LastValue][langgraph.channels.LastValue]
-[MemorySaver][<insert-ref>]
-[`messagesStateReducer`][<insert-ref>]
-[PostgresSaver][<insert-ref>]
-[PostgresSaver][langgraph.checkpoint.postgres.PostgresSaver]
-[Pregel][<insert-ref>]
-[Pregel][langgraph.pregel.Pregel]
-[`Pregel`][langgraph.pregel.Pregel.stream]
-[`pre_model_hook`][langgraph.prebuilt.chat_agent_executor.create_react_agent]
-[protocol][langgraph.checkpoint.serde.base.SerializerProtocol]
-[`Send()`][langgraph.types.Send]
-[`Send`][langgraph.types.Send]
-[SerializerProtocol][<insert-ref>]
-[SerializerProtocol][langgraph.checkpoint.serde.base.SerializerProtocol]
-[SqliteSaver][<insert-ref>]
-[SqliteSaver][langgraph.checkpoint.sqlite.SqliteSaver]
-[`START`][langgraph.constants.START]
-[StateGraph (Graph API)][<insert-ref>]
-[StateGraph (Graph API)][langgraph.graph.StateGraph]
-[StateGraph (Graph API)][langgraph.graph.state.StateGraph]
-[StateGraph][<insert-ref>]
-[StateGraph][langgraph.graph.StateGraph]
-[`.stream()`][<insert-ref>]
-[`stream()`][<insert-ref>]
-[`stream`][<insert-ref>]
-[`stream()`][langgraph.graph.state.CompiledStateGraph.stream]
-[`stream`][langgraph.graph.state.CompiledStateGraph.stream]
-[`.stream()`][langgraph.pregel.Pregel.stream]
-[tasks][<insert-ref>]
-[tasks][langgraph.func.task]
-[`ToolNode`][<insert-ref>]
-[`ToolNode`][langgraph.prebuilt.tool_node.ToolNode]
-[ToolNode][langgraph.prebuilt.tool_node.ToolNode]
-[Topic][<insert-ref>]
-[Topic][langgraph.channels.Topic]
-[`updateState`][<insert-ref>]
-[`update_state`][langgraph.graph.state.CompiledStateGraph.update_state]
-['values']['messages']

docs/docs/agents/agents.md

@@ -15,39 +15,22 @@ This guide shows you how to set up and use LangGraph's **prebuilt**, **reusable*
 
 Before you start this tutorial, ensure you have the following:
 
-- An [Anthropic](https://console.anthropic.com/settings/keys) API key
+- An [Anthropic](https://console.anthropic.com/settings/keys) API key 
 
 ## 1. Install dependencies
 
 If you haven't already, install LangGraph and LangChain:
 
-:::python
-
 ```
 pip install -U langgraph "langchain[anthropic]"
 ```
 
-!!! info
+!!! info 
 
     LangChain is installed so the agent can call the [model](https://python.langchain.com/docs/integrations/chat/).
 
-:::
-
-:::js
-
-```bash
-npm install @langchain/langgraph @langchain/core @langchain/anthropic
-```
-
-!!! info
-
-    LangChain is installed so the agent can call the [model](https://js.langchain.com/docs/integrations/chat/).
-
-:::
-
 ## 2. Create an agent
 
-:::python
 To create an agent, use [`create_react_agent`][langgraph.prebuilt.chat_agent_executor.create_react_agent]:
 
 ```python
@@ -73,52 +56,9 @@ agent.invoke(
 2. Provide a language model for the agent to use. To learn more about configuring language models for the agents, check the [models](./models.md) page.
 3. Provide a list of tools for the model to use.
 4. Provide a system prompt (instructions) to the language model used by the agent.
-   :::
-
-:::js
-To create an agent, use [`createReactAgent`](https://langchain-ai.github.io/langgraphjs/reference/functions/langgraph_prebuilt.createReactAgent.html):
-
-```typescript
-import { ChatAnthropic } from "@langchain/anthropic";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-import { tool } from "@langchain/core/tools";
-import { z } from "zod";
-
-const getWeather = tool(
-  // (1)!
-  async ({ city }) => {
-    return `It's always sunny in ${city}!`;
-  },
-  {
-    name: "get_weather",
-    description: "Get weather for a given city.",
-    schema: z.object({
-      city: z.string().describe("The city to get weather for"),
-    }),
-  }
-);
-
-const agent = createReactAgent({
-  llm: new ChatAnthropic({ model: "anthropic:claude-3-5-sonnet-latest" }), // (2)!
-  tools: [getWeather], // (3)!
-  stateModifier: "You are a helpful assistant", // (4)!
-});
-
-// Run the agent
-await agent.invoke({
-  messages: [{ role: "user", content: "what is the weather in sf" }],
-});
-```
-
-1. Define a tool for the agent to use. Tools can be defined using the `tool` function. For more advanced tool usage and customization, check the [tools](./tools.md) page.
-2. Provide a language model for the agent to use. To learn more about configuring language models for the agents, check the [models](./models.md) page.
-3. Provide a list of tools for the model to use.
-4. Provide a system prompt (instructions) to the language model used by the agent.
-   :::
 
 ## 3. Configure an LLM
 
-:::python
 To configure an LLM with specific parameters, such as temperature, use [init_chat_model](https://python.langchain.com/api_reference/langchain/chat_models/langchain.chat_models.base.init_chat_model.html):
 
 ```python
@@ -139,45 +79,19 @@ agent = create_react_agent(
 )
 ```
 
-:::
-
-:::js
-To configure an LLM with specific parameters, such as temperature, use a model instance:
-
-```typescript
-import { ChatAnthropic } from "@langchain/anthropic";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-// highlight-next-line
-const model = new ChatAnthropic({
-  model: "claude-3-5-sonnet-latest",
-  // highlight-next-line
-  temperature: 0,
-});
-
-const agent = createReactAgent({
-  // highlight-next-line
-  llm: model,
-  tools: [getWeather],
-});
-```
-
-:::
-
 For more information on how to configure LLMs, see [Models](./models.md).
 
 ## 4. Add a custom prompt
 
 Prompts instruct the LLM how to behave. Add one of the following types of prompts:
 
-- **Static**: A string is interpreted as a **system message**.
-- **Dynamic**: A list of messages generated at **runtime**, based on input or configuration.
+* **Static**: A string is interpreted as a **system message**.
+* **Dynamic**: A list of messages generated at **runtime**, based on input or configuration.
 
 === "Static prompt"
 
     Define a fixed prompt string or list of messages:
 
-    :::python
     ```python
     from langgraph.prebuilt import create_react_agent
 
@@ -193,30 +107,9 @@ Prompts instruct the LLM how to behave. Add one of the following types of prompt
         {"messages": [{"role": "user", "content": "what is the weather in sf"}]}
     )
     ```
-    :::
-
-    :::js
-    ```typescript
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-    import { ChatAnthropic } from "@langchain/anthropic";
-
-    const agent = createReactAgent({
-      llm: new ChatAnthropic({ model: "anthropic:claude-3-5-sonnet-latest" }),
-      tools: [getWeather],
-      // A static prompt that never changes
-      // highlight-next-line
-      stateModifier: "Never answer questions about the weather."
-    });
-
-    await agent.invoke({
-      messages: [{ role: "user", content: "what is the weather in sf" }]
-    });
-    ```
-    :::
 
 === "Dynamic prompt"
 
-    :::python
     Define a function that returns a message list based on the agent's state and configuration:
 
     ```python
@@ -251,52 +144,12 @@ Prompts instruct the LLM how to behave. Add one of the following types of prompt
         - Internal agent state updated during a multi-step reasoning process (using `state`).
 
         Dynamic prompts can be defined as functions that take `state` and `config` and return a list of messages to send to the LLM.
-    :::
-
-    :::js
-    Define a function that returns messages based on the agent's state and configuration:
-
-    ```typescript
-    import { type BaseMessageLike } from "@langchain/core/messages";
-    import { type RunnableConfig } from "@langchain/core/runnables";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-    // highlight-next-line
-    const dynamicPrompt = (state: { messages: BaseMessageLike[] }, config: RunnableConfig): BaseMessageLike[] => {  // (1)!
-      const userName = config.configurable?.user_name;
-      const systemMsg = `You are a helpful assistant. Address the user as ${userName}.`;
-      return [{ role: "system", content: systemMsg }, ...state.messages];
-    };
-
-    const agent = createReactAgent({
-      llm: "anthropic:claude-3-5-sonnet-latest",
-      tools: [getWeather],
-      // highlight-next-line
-      stateModifier: dynamicPrompt
-    });
-
-    await agent.invoke(
-      { messages: [{ role: "user", content: "what is the weather in sf" }] },
-      // highlight-next-line
-      { configurable: { user_name: "John Smith" } }
-    );
-    ```
-
-    1. Dynamic prompts allow including non-message [context](./context.md) when constructing an input to the LLM, such as:
-
-        - Information passed at runtime, like a `user_id` or API credentials (using `config`).
-        - Internal agent state updated during a multi-step reasoning process (using `state`).
-
-        Dynamic prompts can be defined as functions that take `state` and `config` and return a list of messages to send to the LLM.
-    :::
 
 For more information, see [Context](./context.md).
 
 ## 5. Add memory
 
-To allow multi-turn conversations with an agent, you need to enable [persistence](../concepts/persistence.md) by providing a checkpointer when creating an agent. At runtime, you need to provide a config containing `thread_id` — a unique identifier for the conversation (session):
-
-:::python
+To allow multi-turn conversations with an agent, you need to enable [persistence](../concepts/persistence.md) by providing a `checkpointer` when creating an agent. At runtime, you need to provide a config containing `thread_id` — a unique identifier for the conversation (session):
 
 ```python
 from langgraph.prebuilt import create_react_agent
@@ -327,60 +180,17 @@ 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.
-   :::
 
-:::js
-
-```typescript
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-import { MemorySaver } from "@langchain/langgraph";
-
-// highlight-next-line
-const checkpointer = new MemorySaver();
-
-const agent = createReactAgent({
-  llm: "anthropic:claude-3-5-sonnet-latest",
-  tools: [getWeather],
-  // highlight-next-line
-  checkpointSaver: checkpointer, // (1)!
-});
-
-// Run the agent
-// highlight-next-line
-const config = { configurable: { thread_id: "1" } };
-const sfResponse = await agent.invoke(
-  { messages: [{ role: "user", content: "what is the weather in sf" }] },
-  // highlight-next-line
-  config // (2)!
-);
-const nyResponse = await agent.invoke(
-  { messages: [{ role: "user", content: "what about new york?" }] },
-  // highlight-next-line
-  config
-);
-```
-
-1. `checkpointSaver` 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.
-2. Pass configuration with `thread_id` to be able to resume the same conversation on future agent invocations.
-   :::
-
-:::python
 When you enable the checkpointer, it stores agent state at every step in the provided checkpointer database (or in memory, if using `InMemorySaver`).
-:::
-
-:::js
-When you enable the checkpointer, it stores agent state at every step in the provided checkpointer database (or in memory, if using `MemorySaver`).
-:::
 
 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
 
-:::python
 To produce structured responses conforming to a schema, use the `response_format` parameter. The schema can be defined with a `Pydantic` model or `TypedDict`. The result will be accessible via the `structured_response` field.
 
 ```python
@@ -405,43 +215,9 @@ response = agent.invoke(
 response["structured_response"]
 ```
 
-1.  When `response_format` is provided, a separate step is added at the end of the agent loop: agent message history is passed to an LLM with structured output to generate a structured response.
+1. When `response_format` is provided, a separate step is added at the end of the agent loop: agent message history is passed to an LLM with structured output to generate a structured response.
 
-        To provide a system prompt to this LLM, use a tuple `(prompt, schema)`, e.g., `response_format=(prompt, WeatherResponse)`.
-
-    :::
-
-:::js
-To produce structured responses conforming to a schema, use the `responseFormat` parameter. The schema can be defined with a `Zod` schema. The result will be accessible via the `structuredResponse` field.
-
-```typescript
-import { z } from "zod";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-const WeatherResponse = z.object({
-  conditions: z.string(),
-});
-
-const agent = createReactAgent({
-  llm: "anthropic:claude-3-5-sonnet-latest",
-  tools: [getWeather],
-  // highlight-next-line
-  responseFormat: WeatherResponse, // (1)!
-});
-
-const response = await agent.invoke({
-  messages: [{ role: "user", content: "what is the weather in sf" }],
-});
-
-// highlight-next-line
-response.structuredResponse;
-```
-
-1.  When `responseFormat` is provided, a separate step is added at the end of the agent loop: agent message history is passed to an LLM with structured output to generate a structured response.
-
-        To provide a system prompt to this LLM, use an object `{ prompt, schema }`, e.g., `responseFormat: { prompt, schema: WeatherResponse }`.
-
-    :::
+    To provide a system prompt to this LLM, use a tuple `(prompt, schema)`, e.g., `response_format=(prompt, WeatherResponse)`.
 
 !!! Note "LLM post-processing"
 

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.
@@ -11,12 +20,20 @@ Context includes _any_ data outside the message list that can shape behavior. Th
 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    |
+|------------------------------------------------------------------------------|-----------------------------------------------|----------|-------------------------|
+| [**Config**](#config-static-context)                                         | data passed at the start of a run             | ❌        | per run                 |
+| [**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)
 
@@ -26,183 +43,105 @@ when you have values that don't change mid-run.
 Specify configuration using a key called **"configurable"** which is reserved
 for this purpose:
 
-:::python
-
 ```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"}}
 )
 ```
 
-:::
+### State (mutable context)
 
-:::js
+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.
 
-```typescript
-await graph.invoke(
-  // (1)!
-  { messages: [{ role: "user", content: "hi!" }] }, // (2)!
-  // highlight-next-line
-  { configurable: { user_id: "user_123" } } // (3)!
-);
+```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"
 
-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.
+    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.
 
-=== "Agent prompt"
 
-    :::python
+
+### 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"}}
     )
     ```
-    :::
 
-    :::js
-    ```typescript
-    import type { BaseMessage } from "@langchain/core/messages";
-    import type { RunnableConfig } from "@langchain/core/runnables";
-    import type { AgentState } from "@langchain/langgraph/prebuilt";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
+=== "Using state"
 
-    // highlight-next-line
-    const prompt = (state: AgentState, config: RunnableConfig): BaseMessage[] => {
-      const userName = config.configurable?.user_name;
-      const systemMsg = `You are a helpful assistant. Address the user as ${userName}.`;
-      return [{ role: "system", content: systemMsg }, ...state.messages];
-    };
-
-    const agent = createReactAgent({
-      llm: model,
-      tools: [getWeather],
-      prompt,
-    });
-
-    await agent.invoke(
-      { messages: [{ role: "user", content: "what is the weather in sf" }] },
-      // highlight-next-line
-      { configurable: { user_name: "John Smith" } }
-    );
-    ```
-    :::
-
-    * See [Agents](../agents/agents.md) for details.
-
-=== "Workflow node"
-
-    :::python
-    ```python
-    from langchain_core.runnables import RunnableConfig
-
-    # highlight-next-line
-    def node(state: State, config: RunnableConfig):
-        user_name = config["configurable"].get("user_name")
-        ...
-    ```
-    :::
-
-    :::js
-    ```typescript
-    import type { RunnableConfig } from "@langchain/core/runnables";
-
-    // highlight-next-line
-    const node = (state: State, config?: RunnableConfig) => {
-      const userName = config?.configurable?.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
-    ```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"
-    ```
-    :::
-
-    :::js
-    ```typescript
-    import type { RunnableConfig } from "@langchain/core/runnables";
-    import { tool } from "@langchain/core/tools";
-    import { z } from "zod";
-
-    // highlight-next-line
-    const getUserInfo = tool(
-      async (_, config: RunnableConfig): Promise<string> => {
-        const userId = config.configurable?.user_id;
-        return userId === "user_123" ? "User is John Smith" : "Unknown user";
-      },
-      {
-        name: "get_user_info",
-        description: "Retrieve user information based on user ID."
-      }
-    );
-    ```
-    :::
-
-    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.
-
-    :::python
     ```python
     from langchain_core.messages import AnyMessage
     from langchain_core.runnables import RunnableConfig
     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"]
@@ -211,130 +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 }
 
-    :::js
-    ```typescript
-    import type { BaseMessage } from "@langchain/core/messages";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-    import { MessagesZodState } from "@langchain/langgraph";
-    import { z } from "zod";
+Tools can access context through special parameter **annotations**.
 
-    // highlight-next-line
-    const CustomState = z.object({ // (1)!
-      messages: MessagesZodState.shape.messages,
-      userName: z.string(),
-    });
+* Use `RunnableConfig` for config access
+* Use `Annotated[StateSchema, InjectedState]` for agent state
 
-    const prompt = (
-      // highlight-next-line
-      state: z.infer<typeof CustomState>
-    ): BaseMessage[] => {
-      const userName = state.userName;
-      const systemMsg = `You are a helpful assistant. User's name is ${userName}`;
-      return [{ role: "system", content: systemMsg }, ...state.messages];
-    };
 
-    const agent = createReactAgent({
-      llm: model,
-      tools: [...],
-      // highlight-next-line
-      stateSchema: CustomState, // (2)!
-      stateModifier: prompt,
-    });
+!!! tip 
 
-    await agent.invoke({
-      messages: [{ role: "user", content: "hi!" }],
-      userName: "John Smith",
-    });
-    ```
+    These annotations prevent LLMs from attempting to fill in the values. These parameters will be **hidden** from the LLM.
 
-    1. Define a custom state schema that extends `MessagesZodState` or creates a new schema.
-    2. Pass the custom state schema to the agent. This allows the agent to access and modify the state during execution.
-    :::
+=== "Using config"
 
-=== "In a workflow"
-
-    :::python
     ```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"
 
-    :::js
-    ```typescript
-    import type { BaseMessage } from "@langchain/core/messages";
-    import { StateGraph, MessagesZodState, START } from "@langchain/langgraph";
-    import { z } from "zod";
+    ```python
+    from typing import Annotated
+    from langgraph.prebuilt import InjectedState
 
-    // highlight-next-line
-    const CustomState = z.object({ // (1)!
-      messages: MessagesZodState.shape.messages,
-      extraField: z.number(),
-    });
+    class CustomState(AgentState):
+        # highlight-next-line
+        user_id: str
 
-    const builder = new StateGraph(CustomState)
-      .addNode("node", async (state) => { // (2)!
-        const messages = state.messages;
-        // ...
-        return { // (3)!
-          // highlight-next-line
-          extraField: state.extraField + 1,
-        };
-      })
-      .addEdge(START, "node");
+    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"
 
-    const graph = builder.compile();
+    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"
+    })
     ```
 
-    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.
-    :::
+### Update Context from Tools
 
-!!! tip "Turning on memory"
-
-    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.
-
-### 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 information, see the [Memory guide](../how-tos/memory/add-memory.md).
+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

@@ -11,21 +11,19 @@ hide:
 
 To deploy your LangGraph agent, create and configure a LangGraph app. This setup supports both local development and production deployments.
 
-Features:
+Features: 
 
-- 🖥️ Local server for development
-- 🧩 Studio Web UI for visual debugging
-- ☁️ Cloud and 🔧 self-hosted deployment options
-- 📊 LangSmith integration for tracing and observability
+* 🖥️ Local server for development
+* 🧩 Studio Web UI for visual debugging
+* ☁️ Cloud and 🔧 self-hosted deployment options
+* 📊 LangSmith integration for tracing and observability
 
-!!! info "Requirements"
+!!! 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
 
-:::python
-
 ```bash
 pip install -U "langgraph-cli[inmem]"
 langgraph new path/to/your/app --template new-langgraph-project-python
@@ -47,46 +45,6 @@ graph = create_react_agent(
 )
 ```
 
-:::
-
-:::js
-
-```bash
-npm install -g @langchain/langgraph-cli
-langgraph new path/to/your/app --template new-langgraph-project-js
-```
-
-This will create an empty LangGraph project. You can modify it by replacing the code in `src/agent/graph.ts` with your agent code. For example:
-
-```typescript
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-import { tool } from "@langchain/core/tools";
-import { z } from "zod";
-
-const getWeather = tool(
-  (input) => {
-    return `It's always sunny in ${input.city}!`;
-  },
-  {
-    name: "get_weather",
-    description: "Get weather for a given city.",
-    schema: z.object({
-      city: z.string().describe("The city to get weather for"),
-    }),
-  }
-);
-
-export const graph = createReactAgent({
-  llm: "anthropic:claude-3-5-sonnet-latest",
-  tools: [getWeather],
-  stateModifier: "You are a helpful assistant",
-});
-```
-
-:::
-
-:::python
-
 ### 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:
@@ -95,8 +53,6 @@ In the root of your new LangGraph app, install the dependencies in `edit` mode s
 pip install -e .
 ```
 
-:::
-
 ### Create an `.env` file
 
 You will find a `.env.example` in the root of your new LangGraph app. Create
@@ -115,13 +71,13 @@ 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
+>    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.
 
@@ -129,8 +85,8 @@ See this [tutorial](https://langchain-ai.github.io/langgraph/tutorials/langgraph
 
 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
+>    - 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](../concepts/deployment_options.md) for detailed instructions on all supported deployment models.
+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/evals.md

@@ -11,8 +11,6 @@ hide:
 
 To evaluate your agent's performance you can use `LangSmith` [evaluations](https://docs.smith.langchain.com/evaluation). You would need to first define an evaluator function to judge the results from an agent, such as final outputs or trajectory. Depending on your evaluation technique, this may or may not involve a reference output:
 
-:::python
-
 ```python
 def evaluator(*, outputs: dict, reference_outputs: dict):
     # compare agent outputs against reference outputs
@@ -22,51 +20,16 @@ def evaluator(*, outputs: dict, reference_outputs: dict):
     return {"key": "evaluator_score", "score": score}
 ```
 
-:::
-
-:::js
-
-```typescript
-type EvaluatorParams = {
-  outputs: Record<string, any>;
-  referenceOutputs: Record<string, any>;
-};
-
-function evaluator({ outputs, referenceOutputs }: EvaluatorParams) {
-  // compare agent outputs against reference outputs
-  const outputMessages = outputs.messages;
-  const referenceMessages = referenceOutputs.messages;
-  const score = compareMessages(outputMessages, referenceMessages);
-  return { key: "evaluator_score", score: score };
-}
-```
-
-:::
-
 To get started, you can use prebuilt evaluators from `AgentEvals` package:
 
-:::python
-
 ```bash
 pip install -U agentevals
 ```
 
-:::
-
-:::js
-
-```bash
-npm install agentevals
-```
-
-:::
-
 ## Create evaluator
 
 A common way to evaluate agent performance is by comparing its trajectory (the order in which it calls its tools) against a reference trajectory:
 
-:::python
-
 ```python
 import json
 # highlight-next-line
@@ -117,72 +80,15 @@ result = evaluator(
 )
 ```
 
-:::
-
-:::js
-
-```typescript
-import { createTrajectoryMatchEvaluator } from "agentevals/trajectory/match";
-
-const outputs = [
-  {
-    role: "assistant",
-    tool_calls: [
-      {
-        function: {
-          name: "get_weather",
-          arguments: JSON.stringify({ city: "san francisco" }),
-        },
-      },
-      {
-        function: {
-          name: "get_directions",
-          arguments: JSON.stringify({ destination: "presidio" }),
-        },
-      },
-    ],
-  },
-];
-
-const referenceOutputs = [
-  {
-    role: "assistant",
-    tool_calls: [
-      {
-        function: {
-          name: "get_weather",
-          arguments: JSON.stringify({ city: "san francisco" }),
-        },
-      },
-    ],
-  },
-];
-
-// Create the evaluator
-const evaluator = createTrajectoryMatchEvaluator({
-  // Specify how the trajectories will be compared. `superset` will accept output trajectory as valid if it's a superset of the reference one. Other options include: strict, unordered and subset
-  trajectoryMatchMode: "superset", // (1)!
-});
-
-// Run the evaluator
-const result = evaluator({
-  outputs: outputs,
-  referenceOutputs: referenceOutputs,
-});
-```
-
-:::
-
 1. Specify how the trajectories will be compared. `superset` will accept output trajectory as valid if it's a superset of the reference one. Other options include: [strict](https://github.com/langchain-ai/agentevals?tab=readme-ov-file#strict-match), [unordered](https://github.com/langchain-ai/agentevals?tab=readme-ov-file#unordered-match) and [subset](https://github.com/langchain-ai/agentevals?tab=readme-ov-file#subset-and-superset-match)
 
+
 As a next step, learn more about how to [customize trajectory match evaluator](https://github.com/langchain-ai/agentevals?tab=readme-ov-file#agent-trajectory-match).
 
 ### LLM-as-a-judge
 
 You can use LLM-as-a-judge evaluator that uses an LLM to compare the trajectory against the reference outputs and output a score:
 
-:::python
-
 ```python
 import json
 from agentevals.trajectory.llm import (
@@ -197,24 +103,6 @@ evaluator = create_trajectory_llm_as_judge(
 )
 ```
 
-:::
-
-:::js
-
-```typescript
-import {
-  createTrajectoryLlmAsJudge,
-  TRAJECTORY_ACCURACY_PROMPT_WITH_REFERENCE,
-} from "agentevals/trajectory/llm";
-
-const evaluator = createTrajectoryLlmAsJudge({
-  prompt: TRAJECTORY_ACCURACY_PROMPT_WITH_REFERENCE,
-  model: "openai:o3-mini",
-});
-```
-
-:::
-
 ## Run evaluator
 
 To run an evaluator, you will first need to create a [LangSmith dataset](https://docs.smith.langchain.com/evaluation/concepts#datasets). To use the prebuilt AgentEvals evaluators, you will need a dataset with the following schema:
@@ -222,8 +110,6 @@ To run an evaluator, you will first need to create a [LangSmith dataset](https:/
 - **input**: `{"messages": [...]}` input messages to call the agent with.
 - **output**: `{"messages": [...]}` expected message history in the agent output. For trajectory evaluation, you can choose to keep only assistant messages.
 
-:::python
-
 ```python
 from langsmith import Client
 from langgraph.prebuilt import create_react_agent
@@ -239,27 +125,4 @@ experiment_results = client.evaluate(
     data="<Name of your dataset>",
     evaluators=[evaluator]
 )
-```
-
-:::
-
-:::js
-
-```typescript
-import { Client } from "langsmith";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-import { createTrajectoryMatchEvaluator } from "agentevals/trajectory/match";
-
-const client = new Client();
-const agent = createReactAgent({...});
-const evaluator = createTrajectoryMatchEvaluator({...});
-
-const experimentResults = await client.evaluate(
-    (inputs) => agent.invoke(inputs),
-    // replace with your dataset name
-    { data: "<Name of your dataset>" },
-    { evaluators: [evaluator] }
-);
-```
-
-:::
+```

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,223 +7,60 @@ 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.
 
 ![MCP](./assets/mcp.png)
 
-:::python
 Install the `langchain-mcp-adapters` library to use MCP tools in LangGraph:
 
 ```bash
 pip install langchain-mcp-adapters
 ```
 
-:::
-
-:::js
-Install the `@langchain/mcp-adapters` library to use MCP tools in LangGraph:
-
-```bash
-npm install langchain-mcp-adapters
-```
-
-:::
-
 ## Use MCP tools
 
-:::python
 The `langchain-mcp-adapters` package enables agents to use tools defined across one or more MCP servers.
 
-=== "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
 
-    ```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 your 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?"})
-    ```
-
-:::
-
-:::js
-The `@langchain/mcp-adapters` package enables agents to use tools defined across one or more MCP servers.
-
-=== "In an agent"
-
-    ```typescript title="Agent using tools defined on MCP servers"
-    // highlight-next-line
-    import { MultiServerMCPClient } from "langchain-mcp-adapters/client";
-    import { ChatAnthropic } from "@langchain/langgraph/prebuilt";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-    // highlight-next-line
-    const client = new MultiServerMCPClient({
-      math: {
-        command: "node",
-        // Replace with absolute path to your math_server.js file
-        args: ["/path/to/math_server.js"],
-        transport: "stdio",
-      },
-      weather: {
-        // Ensure you start your weather server on port 8000
-        url: "http://localhost:8000/mcp",
-        transport: "streamable_http",
-      },
-    });
-
-    // highlight-next-line
-    const tools = await client.getTools();
-    const agent = createReactAgent({
-      llm: new ChatAnthropic({ model: "claude-3-7-sonnet-latest" }),
-      // highlight-next-line
-      tools,
-    });
-
-    const mathResponse = await agent.invoke({
-      messages: [{ role: "user", content: "what's (3 + 5) x 12?" }],
-    });
-
-    const weatherResponse = await agent.invoke({
-      messages: [{ role: "user", content: "what is the weather in nyc?" }],
-    });
-    ```
-
-=== "In a workflow"
-
-    ```typescript
-    import { MultiServerMCPClient } from "langchain-mcp-adapters/client";
-    import { StateGraph, MessagesZodState, START } from "@langchain/langgraph";
-    import { ToolNode } from "@langchain/langgraph/prebuilt";
-    import { ChatOpenAI } from "@langchain/openai";
-    import { AIMessage } from "@langchain/core/messages";
-    import { z } from "zod";
-
-    const model = new ChatOpenAI({ model: "gpt-4" });
-
-    const client = new MultiServerMCPClient({
-      math: {
-        command: "node",
-        // Make sure to update to the full absolute path to your math_server.js file
-        args: ["./examples/math_server.js"],
-        transport: "stdio",
-      },
-      weather: {
-        // make sure you start your weather server on port 8000
-        url: "http://localhost:8000/mcp/",
-        transport: "streamable_http",
-      },
-    });
-
-    const tools = await client.getTools();
-
-    const builder = new StateGraph(MessagesZodState)
-      .addNode("callModel", async (state) => {
-        const response = await model.bindTools(tools).invoke(state.messages);
-        return { messages: [response] };
-      })
-      .addNode("tools", new ToolNode(tools))
-      .addEdge(START, "callModel")
-      .addConditionalEdges("callModel", (state) => {
-        const lastMessage = state.messages.at(-1) as AIMessage | undefined;
-        if (!lastMessage?.tool_calls?.length) {
-          return "__end__";
-        }
-        return "tools";
-      })
-      .addEdge("tools", "callModel");
-
-    const graph = builder.compile();
-
-    const mathResponse = await graph.invoke({
-      messages: [{ role: "user", content: "what's (3 + 5) x 12?" }],
-    });
-
-    const weatherResponse = await graph.invoke({
-      messages: [{ role: "user", content: "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
 
-:::python
 To create your own MCP servers, you can use the `mcp` library. This library provides a simple way to define tools and run them as servers.
 
 Install the MCP library:
@@ -231,24 +68,8 @@ Install the MCP library:
 ```bash
 pip install mcp
 ```
-
-:::
-
-:::js
-To create your own MCP servers, you can use the `@modelcontextprotocol/sdk` library. This library provides a simple way to define tools and run them as servers.
-
-Install the MCP SDK:
-
-```bash
-npm install @modelcontextprotocol/sdk
-```
-
-:::
-
 Use the following reference implementations to test your agent with MCP tool servers.
 
-:::python
-
 ```python title="Example Math Server (stdio transport)"
 from mcp.server.fastmcp import FastMCP
 
@@ -268,115 +89,6 @@ if __name__ == "__main__":
     mcp.run(transport="stdio")
 ```
 
-:::
-
-:::js
-
-```typescript title="Example Math Server (stdio transport)"
-import { Server } from "@modelcontextprotocol/sdk/server/index.js";
-import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
-import {
-  CallToolRequestSchema,
-  ListToolsRequestSchema,
-} from "@modelcontextprotocol/sdk/types.js";
-
-const server = new Server(
-  {
-    name: "math-server",
-    version: "0.1.0",
-  },
-  {
-    capabilities: {
-      tools: {},
-    },
-  }
-);
-
-server.setRequestHandler(ListToolsRequestSchema, async () => {
-  return {
-    tools: [
-      {
-        name: "add",
-        description: "Add two numbers",
-        inputSchema: {
-          type: "object",
-          properties: {
-            a: {
-              type: "number",
-              description: "First number",
-            },
-            b: {
-              type: "number",
-              description: "Second number",
-            },
-          },
-          required: ["a", "b"],
-        },
-      },
-      {
-        name: "multiply",
-        description: "Multiply two numbers",
-        inputSchema: {
-          type: "object",
-          properties: {
-            a: {
-              type: "number",
-              description: "First number",
-            },
-            b: {
-              type: "number",
-              description: "Second number",
-            },
-          },
-          required: ["a", "b"],
-        },
-      },
-    ],
-  };
-});
-
-server.setRequestHandler(CallToolRequestSchema, async (request) => {
-  switch (request.params.name) {
-    case "add": {
-      const { a, b } = request.params.arguments as { a: number; b: number };
-      return {
-        content: [
-          {
-            type: "text",
-            text: String(a + b),
-          },
-        ],
-      };
-    }
-    case "multiply": {
-      const { a, b } = request.params.arguments as { a: number; b: number };
-      return {
-        content: [
-          {
-            type: "text",
-            text: String(a * b),
-          },
-        ],
-      };
-    }
-    default:
-      throw new Error(`Unknown tool: ${request.params.name}`);
-  }
-});
-
-async function main() {
-  const transport = new StdioServerTransport();
-  await server.connect(transport);
-  console.error("Math MCP server running on stdio");
-}
-
-main();
-```
-
-:::
-
-:::python
-
 ```python title="Example Weather Server (Streamable HTTP transport)"
 from mcp.server.fastmcp import FastMCP
 
@@ -391,100 +103,7 @@ if __name__ == "__main__":
     mcp.run(transport="streamable-http")
 ```
 
-:::
-
-:::js
-
-```typescript title="Example Weather Server (HTTP transport)"
-import { Server } from "@modelcontextprotocol/sdk/server/index.js";
-import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";
-import {
-  CallToolRequestSchema,
-  ListToolsRequestSchema,
-} from "@modelcontextprotocol/sdk/types.js";
-import express from "express";
-
-const app = express();
-app.use(express.json());
-
-const server = new Server(
-  {
-    name: "weather-server",
-    version: "0.1.0",
-  },
-  {
-    capabilities: {
-      tools: {},
-    },
-  }
-);
-
-server.setRequestHandler(ListToolsRequestSchema, async () => {
-  return {
-    tools: [
-      {
-        name: "get_weather",
-        description: "Get weather for location",
-        inputSchema: {
-          type: "object",
-          properties: {
-            location: {
-              type: "string",
-              description: "Location to get weather for",
-            },
-          },
-          required: ["location"],
-        },
-      },
-    ],
-  };
-});
-
-server.setRequestHandler(CallToolRequestSchema, async (request) => {
-  switch (request.params.name) {
-    case "get_weather": {
-      const { location } = request.params.arguments as { location: string };
-      return {
-        content: [
-          {
-            type: "text",
-            text: `It's always sunny in ${location}`,
-          },
-        ],
-      };
-    }
-    default:
-      throw new Error(`Unknown tool: ${request.params.name}`);
-  }
-});
-
-app.post("/mcp", async (req, res) => {
-  const transport = new SSEServerTransport("/mcp", res);
-  await server.connect(transport);
-});
-
-const PORT = process.env.PORT || 8000;
-app.listen(PORT, () => {
-  console.log(`Weather MCP server running on port ${PORT}`);
-});
-```
-
-:::
-
-:::python
-
 ## Additional resources
 
 - [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)
-  :::
-
-:::js
-
-## Additional resources
-
-- [MCP documentation](https://modelcontextprotocol.io/introduction)
-- [MCP Transport documentation](https://modelcontextprotocol.io/docs/concepts/transports)
-- [`@langchain/mcp-adapters`](https://npmjs.com/package/@langchain/mcp-adapters)
-  :::
+- [MCP Transport documentation](https://modelcontextprotocol.io/docs/concepts/transports)

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 providers 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,155 +1,234 @@
+---
+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.
 
-## Initialize a model
+## Tool calling support
 
-:::python
-Use [`init_chat_model`](https://python.langchain.com/docs/how_to/chat_models_universal_init/) to initialize models:
+To enable tool-calling agents, the underlying LLM must support [tool calling](https://python.langchain.com/docs/concepts/tool_calling/).
 
-{!snippets/chat_model_tabs.md!}
-:::
+Compatible models can be found in the [LangChain integrations directory](https://python.langchain.com/docs/integrations/chat/).
 
-:::js
-Use model provider classes to initialize models:
+## Specifying a model by name
+
+You can configure an agent with a model name string:
 
 === "OpenAI"
 
-    ```typescript
-    import { ChatOpenAI } from "@langchain/openai";
+    ```python
+    import os
+    from langgraph.prebuilt import create_react_agent
 
-    const model = new ChatOpenAI({
-      model: "gpt-4o",
-      temperature: 0,
-    });
+    os.environ["OPENAI_API_KEY"] = "sk-..."
+
+    agent = create_react_agent(
+        # highlight-next-line
+        model="openai:gpt-4.1",
+        # other parameters
+    )
     ```
 
 === "Anthropic"
 
-    ```typescript
-    import { ChatAnthropic } from "@langchain/anthropic";
+    ```python
+    import os
+    from langgraph.prebuilt import create_react_agent
 
-    const model = new ChatAnthropic({
-      model: "claude-3-5-sonnet-20240620",
-      temperature: 0,
-      maxTokens: 2048,
-    });
+    os.environ["ANTHROPIC_API_KEY"] = "sk-..."
+
+    agent = create_react_agent(
+        # highlight-next-line
+        model="anthropic:claude-3-7-sonnet-latest",
+        # other parameters
+    )
     ```
 
-=== "Google"
+=== "Azure"
 
-    ```typescript
-    import { ChatGoogleGenerativeAI } from "@langchain/google-genai";
+    ```python
+    import os
+    from langgraph.prebuilt import create_react_agent
 
-    const model = new ChatGoogleGenerativeAI({
-      model: "gemini-1.5-pro",
-      temperature: 0,
-    });
+    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
+    )
     ```
 
-=== "Groq"
+=== "Google Gemini"
 
-    ```typescript
-    import { ChatGroq } from "@langchain/groq";
+    ```python
+    import os
+    from langgraph.prebuilt import create_react_agent
 
-    const model = new ChatGroq({
-      model: "llama-3.1-70b-versatile",
-      temperature: 0,
-    });
+    os.environ["GOOGLE_API_KEY"] = "..."
+
+    agent = create_react_agent(
+        # highlight-next-line
+        model="google_genai:gemini-2.0-flash",
+        # other parameters
+    )
     ```
 
-:::
+=== "AWS Bedrock"
 
-:::python
+    ```python
+    from langgraph.prebuilt import create_react_agent
 
-### Instantiate a model directly
+    # 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
+    )
+    ```
+
+
+## Using `init_chat_model`
+
+The [`init_chat_model`](https://python.langchain.com/docs/how_to/chat_models_universal_init/) utility simplifies model initialization with configurable parameters:
+
+=== "OpenAI"
+
+    ```
+    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
 )
 ```
 
-:::
+!!! note "Illustrative example" 
 
-!!! important "Tool calling support"
+    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.
 
-    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/).
+## Disable streaming
 
-## Use in an agent
-
-:::python
-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
-      )
-      ```
-
-:::
-
-:::js
-When using `createReactAgent` you can pass the model instance directly:
-
-```typescript
-import { ChatOpenAI } from "@langchain/openai";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-const model = new ChatOpenAI({
-  model: "gpt-4o",
-  temperature: 0,
-});
-
-const agent = createReactAgent({
-  llm: model,
-  tools: tools,
-});
-```
-
-:::
-
-## Advanced model configuration
-
-### Disable streaming
-
-:::python
 To disable streaming of the individual LLM tokens, set `disable_streaming=True` when initializing the model:
 
 === "`init_chat_model`"
@@ -177,25 +256,9 @@ 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`
-:::
 
-:::js
-To disable streaming of the individual LLM tokens, set `streaming: false` when initializing the model:
+## Adding model fallbacks
 
-```typescript
-import { ChatOpenAI } from "@langchain/openai";
-
-const model = new ChatOpenAI({
-  model: "gpt-4o",
-  streaming: false,
-});
-```
-
-:::
-
-### Add model fallbacks
-
-:::python
 You can add a fallback to a different model or a different LLM provider using `model.with_fallbacks([...])`:
 
 === "`init_chat_model`"
@@ -228,87 +291,8 @@ 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.
-:::
-
-:::js
-You can add a fallback to a different model or a different LLM provider using `model.withFallbacks([...])`:
-
-```typescript
-import { ChatOpenAI } from "@langchain/openai";
-import { ChatAnthropic } from "@langchain/anthropic";
-
-const modelWithFallbacks = new ChatOpenAI({
-  model: "gpt-4o",
-}).withFallbacks([
-  new ChatAnthropic({
-    model: "claude-3-5-sonnet-20240620",
-  }),
-]);
-```
-
-See this [guide](https://js.langchain.com/docs/how_to/fallbacks/#fallback-to-better-model) for more information on model fallbacks.
-:::
-
-:::python
-
-### 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:
-
-:::python
-
-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.
-   :::
-
-:::js
-
-1. **Implement a custom LangChain chat model**: Create a model conforming to the [LangChain chat model interface](https://js.langchain.com/docs/how_to/custom_chat/). 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
 
-:::python
-
-- [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/)
-  :::
-
-:::js
-
-- [Multimodal inputs](https://js.langchain.com/docs/how_to/multimodal_inputs/)
-- [Structured outputs](https://js.langchain.com/docs/how_to/structured_output/)
-- [Model integration directory](https://js.langchain.com/docs/integrations/chat/)
-- [Force model to call a specific tool](https://js.langchain.com/docs/how_to/tool_choice/)
-- [All chat model how-to guides](https://js.langchain.com/docs/how_to/#chat-models)
-- [Chat model integrations](https://js.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/multi-agent.md

@@ -9,7 +9,7 @@ hide:
 
 # Multi-agent
 
-A single agent might struggle if it needs to specialize in multiple domains or manage many tools. To tackle this, you can break your agent into smaller, independent agents and compose them into a [multi-agent system](../concepts/multi_agent.md).
+A single agent might struggle if it needs to specialize in multiple domains or manage many tools. To tackle this, you can break your agent into smaller, independent agents and composing them into a [multi-agent system](../concepts/multi_agent.md).
 
 In multi-agent systems, agents need to communicate between each other. They do so via [handoffs](#handoffs) — a primitive that describes which agent to hand control to and the payload to send to that agent.
 
@@ -22,7 +22,6 @@ Two of the most popular multi-agent architectures are:
 
 ![Supervisor](./assets/supervisor.png)
 
-:::python
 Use [`langgraph-supervisor`](https://github.com/langchain-ai/langgraph-supervisor-py) library to create a supervisor multi-agent system:
 
 ```bash
@@ -83,76 +82,10 @@ for chunk in supervisor.stream(
     print("\n")
 ```
 
-:::
-
-:::js
-Use [`@langchain/langgraph-supervisor`](https://github.com/langchain-ai/langgraphjs/tree/main/libs/langgraph-supervisor) library to create a supervisor multi-agent system:
-
-```bash
-npm install @langchain/langgraph-supervisor
-```
-
-```typescript
-import { ChatOpenAI } from "@langchain/openai";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-// highlight-next-line
-import { createSupervisor } from "langgraph-supervisor";
-
-function bookHotel(hotelName: string) {
-  /**Book a hotel*/
-  return `Successfully booked a stay at ${hotelName}.`;
-}
-
-function bookFlight(fromAirport: string, toAirport: string) {
-  /**Book a flight*/
-  return `Successfully booked a flight from ${fromAirport} to ${toAirport}.`;
-}
-
-const flightAssistant = createReactAgent({
-  llm: "openai:gpt-4o",
-  tools: [bookFlight],
-  stateModifier: "You are a flight booking assistant",
-  // highlight-next-line
-  name: "flight_assistant",
-});
-
-const hotelAssistant = createReactAgent({
-  llm: "openai:gpt-4o",
-  tools: [bookHotel],
-  stateModifier: "You are a hotel booking assistant",
-  // highlight-next-line
-  name: "hotel_assistant",
-});
-
-// highlight-next-line
-const supervisor = createSupervisor({
-  agents: [flightAssistant, hotelAssistant],
-  llm: new ChatOpenAI({ model: "gpt-4o" }),
-  systemPrompt:
-    "You manage a hotel booking assistant and a " +
-    "flight booking assistant. Assign work to them.",
-});
-
-for await (const chunk of supervisor.stream({
-  messages: [
-    {
-      role: "user",
-      content: "book a flight from BOS to JFK and a stay at McKittrick Hotel",
-    },
-  ],
-})) {
-  console.log(chunk);
-  console.log("\n");
-}
-```
-
-:::
-
 ## Swarm
 
 ![Swarm](./assets/swarm.png)
 
-:::python
 Use [`langgraph-swarm`](https://github.com/langchain-ai/langgraph-swarm-py) library to create a swarm multi-agent system:
 
 ```bash
@@ -210,82 +143,18 @@ for chunk in swarm.stream(
     print("\n")
 ```
 
-:::
-
-:::js
-Use [`@langchain/langgraph-swarm`](https://github.com/langchain-ai/langgraphjs/tree/main/libs/langgraph-swarm) library to create a swarm multi-agent system:
-
-```bash
-npm install @langchain/langgraph-swarm
-```
-
-```typescript
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-// highlight-next-line
-import { createSwarm, createHandoffTool } from "@langchain/langgraph-swarm";
-
-const transferToHotelAssistant = createHandoffTool({
-  agentName: "hotel_assistant",
-  description: "Transfer user to the hotel-booking assistant.",
-});
-
-const transferToFlightAssistant = createHandoffTool({
-  agentName: "flight_assistant",
-  description: "Transfer user to the flight-booking assistant.",
-});
-
-const flightAssistant = createReactAgent({
-  llm: "anthropic:claude-3-5-sonnet-latest",
-  // highlight-next-line
-  tools: [bookFlight, transferToHotelAssistant],
-  stateModifier: "You are a flight booking assistant",
-  // highlight-next-line
-  name: "flight_assistant",
-});
-
-const hotelAssistant = createReactAgent({
-  llm: "anthropic:claude-3-5-sonnet-latest",
-  // highlight-next-line
-  tools: [bookHotel, transferToFlightAssistant],
-  stateModifier: "You are a hotel booking assistant",
-  // highlight-next-line
-  name: "hotel_assistant",
-});
-
-// highlight-next-line
-const swarm = createSwarm({
-  agents: [flightAssistant, hotelAssistant],
-  defaultActiveAgent: "flight_assistant",
-});
-
-for await (const chunk of swarm.stream({
-  messages: [
-    {
-      role: "user",
-      content: "book a flight from BOS to JFK and a stay at McKittrick Hotel",
-    },
-  ],
-})) {
-  console.log(chunk);
-  console.log("\n");
-}
-```
-
-:::
-
 ## Handoffs
 
-A common pattern in multi-agent interactions is **handoffs**, where one agent _hands off_ control to another. Handoffs allow you to specify:
+A common pattern in multi-agent interactions is **handoffs**, where one agent *hands off* control to another. Handoffs allow you to specify:
 
 - **destination**: target agent to navigate to
 - **payload**: information to pass to that agent
 
-:::python
 This is used both by `langgraph-supervisor` (supervisor hands off to individual agents) and `langgraph-swarm` (an individual agent can hand off to other agents).
 
 To implement handoffs with `create_react_agent`, you need to:
 
-1.  Create a special tool that can transfer control to a different agent
+1. Create a special tool that can transfer control to a different agent
 
     ```python
     def transfer_to_bob():
@@ -304,7 +173,7 @@ To implement handoffs with `create_react_agent`, you need to:
         )
     ```
 
-2.  Create individual agents that have access to handoff tools:
+1. Create individual agents that have access to handoff tools:
 
     ```python
     flight_assistant = create_react_agent(
@@ -315,72 +184,20 @@ To implement handoffs with `create_react_agent`, you need to:
     )
     ```
 
-3.  Define a parent graph that contains individual agents as nodes:
+1. Define a parent graph that contains individual agents as nodes:
 
-        ```python
-        from langgraph.graph import StateGraph, MessagesState
-        multi_agent_graph = (
-            StateGraph(MessagesState)
-            .add_node(flight_assistant)
-            .add_node(hotel_assistant)
-            ...
-        )
-        ```
-
-    :::
-
-:::js
-This is used both by `@langchain/langgraph-supervisor` (supervisor hands off to individual agents) and `@langchain/langgraph-swarm` (an individual agent can hand off to other agents).
-
-To implement handoffs with `createReactAgent`, you need to:
-
-1.  Create a special tool that can transfer control to a different agent
-
-    ```typescript
-    function transferToBob() {
-      /**Transfer to bob.*/
-      return new Command({
-        // name of the agent (node) to go to
-        // highlight-next-line
-        goto: "bob",
-        // data to send to the agent
-        // highlight-next-line
-        update: { messages: [...] },
-        // indicate to LangGraph that we need to navigate to
-        // agent node in a parent graph
-        // highlight-next-line
-        graph: Command.PARENT,
-      });
-    }
+    ```python
+    from langgraph.graph import StateGraph, MessagesState
+    multi_agent_graph = (
+        StateGraph(MessagesState)
+        .add_node(flight_assistant)
+        .add_node(hotel_assistant)
+        ...
+    )
     ```
 
-2.  Create individual agents that have access to handoff tools:
-
-    ```typescript
-    const flightAssistant = createReactAgent({
-      ..., tools: [bookFlight, transferToHotelAssistant]
-    });
-    const hotelAssistant = createReactAgent({
-      ..., tools: [bookHotel, transferToFlightAssistant]
-    });
-    ```
-
-3.  Define a parent graph that contains individual agents as nodes:
-
-        ```typescript
-        import { StateGraph, MessagesZodState } from "@langchain/langgraph";
-        const multiAgentGraph = new StateGraph(MessagesZodState)
-          .addNode("flight_assistant", flightAssistant)
-          .addNode("hotel_assistant", hotelAssistant)
-          // ...
-        ```
-
-    :::
-
 Putting this together, here is how you can implement a simple multi-agent system with two agents — a flight booking assistant and a hotel booking assistant:
 
-:::python
-
 ```python
 from typing import Annotated
 from langchain_core.tools import tool, InjectedToolCallId
@@ -481,156 +298,11 @@ for chunk in multi_agent_graph.stream(
 3. Name of the agent or node to hand off to.
 4. Take the agent's messages and **add** them to the parent's **state** as part of the handoff. The next agent will see the parent state.
 5. Indicate to LangGraph that we need to navigate to agent node in a **parent** multi-agent graph.
-   :::
-
-:::js
-
-```typescript
-import { tool } from "@langchain/core/tools";
-import { ChatAnthropic } from "@langchain/anthropic";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-import {
-  StateGraph,
-  START,
-  MessagesZodState,
-  Command,
-} from "@langchain/langgraph";
-import { z } from "zod";
-
-function createHandoffTool({
-  agentName,
-  description,
-}: {
-  agentName: string;
-  description?: string;
-}) {
-  const name = `transfer_to_${agentName}`;
-  const toolDescription = description || `Transfer to ${agentName}`;
-
-  return tool(
-    async (_, config) => {
-      const toolMessage = {
-        role: "tool" as const,
-        content: `Successfully transferred to ${agentName}`,
-        name: name,
-        tool_call_id: config.toolCall?.id!,
-      };
-      return new Command({
-        // (2)!
-        // highlight-next-line
-        goto: agentName, // (3)!
-        // highlight-next-line
-        update: { messages: [toolMessage] }, // (4)!
-        // highlight-next-line
-        graph: Command.PARENT, // (5)!
-      });
-    },
-    {
-      name,
-      description: toolDescription,
-      schema: z.object({}),
-    }
-  );
-}
-
-// Handoffs
-const transferToHotelAssistant = createHandoffTool({
-  agentName: "hotel_assistant",
-  description: "Transfer user to the hotel-booking assistant.",
-});
-
-const transferToFlightAssistant = createHandoffTool({
-  agentName: "flight_assistant",
-  description: "Transfer user to the flight-booking assistant.",
-});
-
-// Simple agent tools
-const bookHotel = tool(
-  async ({ hotelName }) => {
-    /**Book a hotel*/
-    return `Successfully booked a stay at ${hotelName}.`;
-  },
-  {
-    name: "book_hotel",
-    description: "Book a hotel",
-    schema: z.object({
-      hotelName: z.string().describe("Name of the hotel to book"),
-    }),
-  }
-);
-
-const bookFlight = tool(
-  async ({ fromAirport, toAirport }) => {
-    /**Book a flight*/
-    return `Successfully booked a flight from ${fromAirport} to ${toAirport}.`;
-  },
-  {
-    name: "book_flight",
-    description: "Book a flight",
-    schema: z.object({
-      fromAirport: z.string().describe("Departure airport code"),
-      toAirport: z.string().describe("Arrival airport code"),
-    }),
-  }
-);
-
-// Define agents
-const flightAssistant = createReactAgent({
-  llm: new ChatAnthropic({ model: "anthropic:claude-3-5-sonnet-latest" }),
-  // highlight-next-line
-  tools: [bookFlight, transferToHotelAssistant],
-  stateModifier: "You are a flight booking assistant",
-  // highlight-next-line
-  name: "flight_assistant",
-});
-
-const hotelAssistant = createReactAgent({
-  llm: new ChatAnthropic({ model: "anthropic:claude-3-5-sonnet-latest" }),
-  // highlight-next-line
-  tools: [bookHotel, transferToFlightAssistant],
-  stateModifier: "You are a hotel booking assistant",
-  // highlight-next-line
-  name: "hotel_assistant",
-});
-
-// Define multi-agent graph
-const multiAgentGraph = new StateGraph(MessagesZodState)
-  .addNode("flight_assistant", flightAssistant)
-  .addNode("hotel_assistant", hotelAssistant)
-  .addEdge(START, "flight_assistant")
-  .compile();
-
-// Run the multi-agent graph
-for await (const chunk of multiAgentGraph.stream({
-  messages: [
-    {
-      role: "user",
-      content: "book a flight from BOS to JFK and a stay at McKittrick Hotel",
-    },
-  ],
-})) {
-  console.log(chunk);
-  console.log("\n");
-}
-```
-
-1. Access agent's state
-2. The `Command` primitive allows specifying a state update and a node transition as a single operation, making it useful for implementing handoffs.
-3. Name of the agent or node to hand off to.
-4. Take the agent's messages and **add** them to the parent's **state** as part of the handoff. The next agent will see the parent state.
-5. Indicate to LangGraph that we need to navigate to agent node in a **parent** multi-agent graph.
-   :::
 
 !!! Note
-This handoff implementation assumes that:
+    This handoff implementation assumes that:
 
     - each agent receives overall message history (across all agents) in the multi-agent system as its input
     - each agent outputs its internal messages history to the overall message history of the multi-agent system
 
-:::python
-Check out LangGraph [supervisor](https://github.com/langchain-ai/langgraph-supervisor-py#customizing-handoff-tools) and [swarm](https://github.com/langchain-ai/langgraph-swarm-py#customizing-handoff-tools) documentation to learn how to customize handoffs.
-:::
-
-:::js
-Check out LangGraph [supervisor](https://github.com/langchain-ai/langgraphjs/tree/main/libs/langgraph-supervisor#customizing-handoff-tools) and [swarm](https://github.com/langchain-ai/langgraphjs/tree/main/libs/langgraph-swarm#customizing-handoff-tools) documentation to learn how to customize handoffs.
-:::
+    Check out LangGraph [supervisor](https://github.com/langchain-ai/langgraph-supervisor-py#customizing-handoff-tools) and [swarm](https://github.com/langchain-ai/langgraph-swarm-py#customizing-handoff-tools) documentation to learn how to customize handoffs.

docs/docs/agents/overview.md

@@ -14,7 +14,7 @@ hide:
 
 ## What is an agent?
 
-An _agent_ consists of three components: a **large language model (LLM)**, a set of **tools** it can use, and a **prompt** that provides instructions.
+An *agent* consists of three components: a **large language model (LLM)**, a set of **tools** it can use, and a **prompt** that provides instructions.
 
 The LLM operates in a loop. In each iteration, it selects a tool to invoke, provides input, receives the result (an observation), and uses that observation to inform the next action. The loop continues until a stopping condition is met — typically when the agent has gathered enough information to respond to the user.
 
@@ -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.
+    - **[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/tutorials/deployment/) for production.
 
 ## High-level building blocks
 
@@ -40,20 +40,18 @@ LangGraph comes with a set of prebuilt components that implement common agent be
 
 Using LangGraph for agent development allows you to focus on your application's logic and behavior, instead of building and maintaining the supporting infrastructure for state, memory, and human feedback.
 
-:::python
-
 ## Package ecosystem
 
 The high-level components are organized into several packages, each with a specific focus.
 
-| Package                                    | Description                                                                              | Installation                            |
-| ------------------------------------------ | ---------------------------------------------------------------------------------------- | --------------------------------------- |
-| `langgraph-prebuilt` (part of `langgraph`) | Prebuilt components to [**create agents**](./agents.md)                                  | `pip install -U langgraph langchain`    |
-| `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`                |
-| `agentevals`                               | Utilities to [**evaluate agent performance**](./evals.md)                                | `pip install -U agentevals`             |
+| Package                                    | Description                                                                 | Installation                            |
+|--------------------------------------------|-----------------------------------------------------------------------------|-----------------------------------------|
+| `langgraph-prebuilt` (part of `langgraph`) | Prebuilt components to [**create agents**](./agents.md)                     | `pip install -U langgraph langchain`    |
+| `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**](./memory.md)        | `pip install -U langmem`                |
+| `agentevals`                               | Utilities to [**evaluate agent performance**](./evals.md)                   | `pip install -U agentevals`             |
 
 ## Visualize an agent graph
 
@@ -62,10 +60,10 @@ Use the following tool to visualize the graph generated by
 and to view an outline of the corresponding code.
 It allows you to explore the infrastructure of the agent as defined by the presence of:
 
-- [`tools`](../agents/tools.md): A list of tools (functions, APIs, or other callable objects) that the agent can use to perform tasks.
-- [`pre_model_hook`](../how-tos/create-react-agent-manage-message-history.ipynb): A function that is called before the model is invoked. It can be used to condense messages or perform other preprocessing tasks.
-- `post_model_hook`: A function that is called after the model is invoked. It can be used to implement guardrails, human-in-the-loop flows, or other postprocessing tasks.
-- [`response_format`](../agents/agents.md#6-configure-structured-output): A data structure used to constrain the type of the final output, e.g., a `pydantic` `BaseModel`.
+* [`tools`](../agents/tools.md): A list of tools (functions, APIs, or other callable objects) that the agent can use to perform tasks.
+* [`pre_model_hook`](../how-tos/create-react-agent-manage-message-history.ipynb): A function that is called before the model is invoked. It can be used to condense messages or perform other preprocessing tasks.
+* `post_model_hook`: A function that is called after the model is invoked. It can be used to implement guardrails, human-in-the-loop flows, or other postprocessing tasks.
+* [`response_format`](../agents/agents.md#6-configure-structured-output): A data structure used to constrain the type of the final output, e.g., a `pydantic` `BaseModel`.
 
 <div class="agent-layout">
   <div class="agent-graph-features-container">
@@ -84,6 +82,7 @@ It allows you to explore the infrastructure of the agent as defined by the prese
   </div>
 </div>
 
+
 The following code snippet shows how to create the above agent (and underlying graph) with
 [`create_react_agent`][langgraph.prebuilt.chat_agent_executor.create_react_agent]:
 
@@ -91,6 +90,7 @@ The following code snippet shows how to create the above agent (and underlying g
   <pre><code id="agent-code" class="language-python"></code></pre>
 </div>
 
+
 <script>
 function getCheckedValue(id) {
   return document.getElementById(id).checked ? "1" : "0";
@@ -189,159 +189,3 @@ function initializeWidget() {
 window.addEventListener("DOMContentLoaded", initializeWidget);
 document$.subscribe(initializeWidget);
 </script>
-
-:::
-
-:::js
-
-## Package ecosystem
-
-The high-level components are organized into several packages, each with a specific focus.
-
-| Package                  | Description                                                                 | Installation                                       |
-| ------------------------ | --------------------------------------------------------------------------- | -------------------------------------------------- |
-| `langgraph`              | Prebuilt components to [**create agents**](./agents.md)                     | `npm install @langchain/langgraph @langchain/core` |
-| `langgraph-supervisor`   | Tools for building [**supervisor**](./multi-agent.md#supervisor) agents     | `npm install @langchain/langgraph-supervisor`      |
-| `langgraph-swarm`        | Tools for building a [**swarm**](./multi-agent.md#swarm) multi-agent system | `npm install @langchain/langgraph-swarm`           |
-| `langchain-mcp-adapters` | Interfaces to [**MCP servers**](./mcp.md) for tool and resource integration | `npm install @langchain/mcp-adapters`              |
-| `agentevals`             | Utilities to [**evaluate agent performance**](./evals.md)                   | `npm install agentevals`                           |
-
-## Visualize an agent graph
-
-Use the following tool to visualize the graph generated by [`createReactAgent`](/langgraphjs/reference/functions/langgraph_prebuilt.createReactAgent.html) and to view an outline of the corresponding code. It allows you to explore the infrastructure of the agent as defined by the presence of:
-
-- [`tools`](./tools.md): A list of tools (functions, APIs, or other callable objects) that the agent can use to perform tasks.
-- `preModelHook`: A function that is called before the model is invoked. It can be used to condense messages or perform other preprocessing tasks.
-- `postModelHook`: A function that is called after the model is invoked. It can be used to implement guardrails, human-in-the-loop flows, or other postprocessing tasks.
-- [`responseFormat`](./agents.md#structured-output): A data structure used to constrain the type of the final output (via Zod schemas).
-
-<div class="agent-layout">
-  <div class="agent-graph-features-container">
-    <div class="agent-graph-features">
-      <h3 class="agent-section-title">Features</h3>
-      <label><input type="checkbox" id="tools" checked> <code>tools</code></label>
-      <label><input type="checkbox" id="preModelHook"> <code>preModelHook</code></label>
-      <label><input type="checkbox" id="postModelHook"> <code>postModelHook</code></label>
-      <label><input type="checkbox" id="responseFormat"> <code>responseFormat</code></label>
-    </div>
-  </div>
-
-  <div class="agent-graph-container">
-    <h3 class="agent-section-title">Graph</h3>
-    <img id="agent-graph-img" src="../assets/react_agent_graphs/0001.svg" alt="graph image" style="max-width: 100%;"/>
-  </div>
-</div>
-
-The following code snippet shows how to create the above agent (and underlying graph) with [`createReactAgent`](/langgraphjs/reference/functions/langgraph_prebuilt.createReactAgent.html):
-
-<div class="language-typescript">
-  <pre><code id="agent-code" class="language-typescript"></code></pre>
-</div>
-
-<script>
-function getCheckedValue(id) {
-  return document.getElementById(id).checked ? "1" : "0";
-}
-
-function getKey() {
-  return [
-    getCheckedValue("responseFormat"),
-    getCheckedValue("postModelHook"),
-    getCheckedValue("preModelHook"),
-    getCheckedValue("tools")
-  ].join("");
-}
-
-function dedent(strings, ...values) {
-  const str = String.raw({ raw: strings }, ...values)
-  const [space] = str.split("\n").filter(Boolean).at(0).match(/^(\s*)/)
-  const spaceLen = space.length
-  return str.split("\n").map(line => line.slice(spaceLen)).join("\n").trim()
-}
-
-Object.assign(dedent, {
-  offset: (size) => (strings, ...values) => {
-    return dedent(strings, ...values).split("\n").map(line => " ".repeat(size) + line).join("\n")
-  }
-})
-
-
-
-
-function generateCodeSnippet({ tools, pre, post, response }) {
-  const lines = []
-
-  lines.push(dedent`
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-    import { ChatOpenAI } from "@langchain/openai";
-  `)
-
-  if (tools) lines.push(`import { tool } from "@langchain/core/tools";`);  
-  if (response || tools) lines.push(`import { z } from "zod";`);
-
-  lines.push("", dedent`
-    const agent = createReactAgent({
-      llm: new ChatOpenAI({ model: "o4-mini" }),
-  `)
-
-  if (tools) {
-    lines.push(dedent.offset(2)`
-      tools: [
-        tool(() => "Sample tool output", {
-          name: "sampleTool",
-          schema: z.object({}),
-        }),
-      ],
-    `)
-  }
-
-  if (pre) {
-    lines.push(dedent.offset(2)`
-      preModelHook: (state) => ({ llmInputMessages: state.messages }),
-    `)
-  }
-
-  if (post) {
-    lines.push(dedent.offset(2)`
-      postModelHook: (state) => state,
-    `)
-  }
-
-  if (response) {
-    lines.push(dedent.offset(2)`
-      responseFormat: z.object({ result: z.string() }),
-    `)
-  }
-
-  lines.push(`});`);
-
-  return lines.join("\n");
-}
-
-function render() {
-  const key = getKey();
-  document.getElementById("agent-graph-img").src = `../assets/react_agent_graphs/${key}.svg`;
-
-  const state = {
-    tools: document.getElementById("tools").checked,
-    pre: document.getElementById("preModelHook").checked,
-    post: document.getElementById("postModelHook").checked,
-    response: document.getElementById("responseFormat").checked
-  };
-
-  document.getElementById("agent-code").textContent = generateCodeSnippet(state);
-}
-
-function initializeWidget() {
-  render(); // no need for `await` here
-  document.querySelectorAll(".agent-graph-features input").forEach((input) => {
-    input.addEventListener("change", render);
-  });
-}
-
-// Init for both full reload and SPA nav (used by MkDocs Material)
-window.addEventListener("DOMContentLoaded", initializeWidget);
-document$.subscribe(initializeWidget);
-</script>
-
-:::

docs/docs/agents/prebuilt.md

@@ -1,13 +1,12 @@
 [//]: # (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
-[//]: # (This file is automatically generated using a script in docs/_scripts. Do not edit this file directly!)
+## 📚 Available libraries
 
-:::python
+[//]: # (This file is automatically generated using a script in docs/_scripts. Do not edit this file directly!)
 | Name | GitHub URL | Description | Weekly Downloads | Stars |
 | --- | --- | --- | --- | --- |
 | **trustcall** | [hinthornw/trustcall](https://github.com/hinthornw/trustcall) | Tenacious tool calling built on LangGraph. | -12345 | ![GitHub stars](https://img.shields.io/github/stars/hinthornw/trustcall?style=social)
@@ -24,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! 🏆
@@ -33,41 +32,13 @@ To share your project, simply open a Pull Request adding an entry for your packa
 
 **Guidelines**
 
-- Your repo must be distributed as an installable package on PyPI 📦
+- Your repo must be distributed as an installable package (e.g., PyPI for Python, npm 
+  for JavaScript/TypeScript, etc.) 📦
 - The repo should either use the Graph API (exposing a `StateGraph` instance) or 
   the Functional API (exposing an `entrypoint`).
 - The package must include documentation (e.g., a `README.md` or docs site) 
   explaining how to use it.
-
+  
 We'll review your contribution and merge it in!
 
 Thanks for contributing! 🚀
-:::
-
-:::js
-| Name | GitHub URL | Description | Weekly Downloads | Stars |
-| --- | --- | --- | --- | --- |
-| **@langchain/mcp-adapters** | [langchain-ai/langchainjs](https://github.com/langchain-ai/langchainjs) | Make Anthropic Model Context Protocol (MCP) tools compatible with LangGraph agents. | -12345 | ![GitHub stars](https://img.shields.io/github/stars/langchain-ai/langchainjs?style=social)
-| **@langchain/langgraph-supervisor** | [langchain-ai/langgraphjs](https://github.com/langchain-ai/langgraphjs) | Build supervisor multi-agent systems with LangGraph | -12345 | ![GitHub stars](https://img.shields.io/github/stars/langchain-ai/langgraphjs?style=social)
-| **@langchain/langgraph-swarm** | [langchain-ai/langgraphjs](https://github.com/langchain-ai/langgraphjs) | Build multi-agent swarms with LangGraph | -12345 | ![GitHub stars](https://img.shields.io/github/stars/langchain-ai/langgraphjs?style=social)
-| **@langchain/langgraph-cua** | [langchain-ai/langgraphjs](https://github.com/langchain-ai/langgraphjs) | Build computer use agents with LangGraph | -12345 | ![GitHub stars](https://img.shields.io/github/stars/langchain-ai/langgraphjs?style=social)
-
-## ✨ 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! 🏆
-
-To share your project, simply open a Pull Request adding an entry for your package in our [packages.yml](https://github.com/langchain-ai/langgraph/blob/main/docs/_scripts/third_party_page/packages.yml) file.
-
-**Guidelines**
-
-- Your repo must be distributed as an installable package on npm 📦
-- The repo should either use the Graph API (exposing a `StateGraph` instance) or 
-  the Functional API (exposing an `entrypoint`).
-- The package must include documentation (e.g., a `README.md` or docs site) 
-  explaining how to use it.
-
-We'll review your contribution and merge it in!
-
-Thanks for contributing! 🚀
-:::

docs/docs/agents/run_agents.md

@@ -9,28 +9,19 @@ 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
 
 Agents can be executed in two primary modes:
 
-:::python
-
 - **Synchronous** using `.invoke()` or `.stream()`
 - **Asynchronous** using `await .ainvoke()` or `async for` with `.astream()`
-  :::
 
-:::js
-
-- **Synchronous** using `.invoke()` or `.stream()`
-- **Asynchronous** using `await .invoke()` or `for await` with `.stream()`
-  :::
-
-:::python
 === "Sync invocation"
-
-    ````python
+    ```python
     from langgraph.prebuilt import create_react_agent
 
     agent = create_react_agent(...)
@@ -40,33 +31,14 @@ Agents can be executed in two primary modes:
     ```
 
 === "Async invocation"
-
-````python
-from langgraph.prebuilt import create_react_agent
+    ```python
+    from langgraph.prebuilt import create_react_agent
 
     agent = create_react_agent(...)
     # highlight-next-line
     response = await agent.ainvoke({"messages": [{"role": "user", "content": "what is the weather in sf"}]})
     ```
 
-:::
-
-:::js
-
-```typescript
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-const agent = createReactAgent(...);
-// highlight-next-line
-const response = await agent.invoke({
-    "messages": [
-        { "role": "user", "content": "what is the weather in sf" }
-    ]
-});
-````
-
-:::
-
 ## Inputs and outputs
 
 Agents use a language model that expects a list of `messages` as an input. Therefore, agent inputs and outputs are stored as a list of `messages` under the `messages` key in the agent [state](../concepts/low_level.md#working-with-messages-in-graph-state).
@@ -75,73 +47,33 @@ Agents use a language model that expects a list of `messages` as an input. There
 
 Agent input must be a dictionary with a `messages` key. Supported formats are:
 
-:::python
-| Format | Example |
+| Format             | Example                                                                                                                       |
 |--------------------|-------------------------------------------------------------------------------------------------------------------------------|
-| String | `{"messages": "Hello"}` — Interpreted as a [HumanMessage](https://python.langchain.com/docs/concepts/messages/#humanmessage) |
-| Message dictionary | `{"messages": {"role": "user", "content": "Hello"}}` |
-| List of messages | `{"messages": [{"role": "user", "content": "Hello"}]}` |
-| With custom state | `{"messages": [{"role": "user", "content": "Hello"}], "user_name": "Alice"}` — If using a custom `state_schema` |
-:::
+| String             | `{"messages": "Hello"}`  — Interpreted as a [HumanMessage](https://python.langchain.com/docs/concepts/messages/#humanmessage) |
+| Message dictionary | `{"messages": {"role": "user", "content": "Hello"}}`                                                                          |
+| List of messages   | `{"messages": [{"role": "user", "content": "Hello"}]}`                                                                        |
+| With custom state  | `{"messages": [{"role": "user", "content": "Hello"}], "user_name": "Alice"}` — If using a custom `state_schema`               |
 
-:::js
-| Format | Example |
-|--------------------|-------------------------------------------------------------------------------------------------------------------------------|
-| String | `{"messages": "Hello"}` — Interpreted as a [HumanMessage](https://js.langchain.com/docs/concepts/messages/#humanmessage) |
-| Message dictionary | `{"messages": {"role": "user", "content": "Hello"}}` |
-| List of messages | `{"messages": [{"role": "user", "content": "Hello"}]}` |
-| With custom state | `{"messages": [{"role": "user", "content": "Hello"}], "user_name": "Alice"}` — If using a custom state definition |
-:::
-
-:::python
 Messages are automatically converted into LangChain's internal message format. You can read
 more about [LangChain messages](https://python.langchain.com/docs/concepts/messages/#langchain-messages) in the LangChain documentation.
-:::
-
-:::js
-Messages are automatically converted into LangChain's internal message format. You can read
-more about [LangChain messages](https://js.langchain.com/docs/concepts/messages/#langchain-messages) in the LangChain documentation.
-:::
 
 !!! tip "Using custom agent state"
 
-:::python
-You can provide additional fields defined in your agent's state schema directly in the input dictionary. This allows dynamic behavior based on runtime data or prior tool outputs.
-See the [context guide](./context.md) for full details.
-:::
-
-:::js
-You can provide additional fields defined in your agent's state directly in the state definition. This allows dynamic behavior based on runtime data or prior tool outputs.
-See the [context guide](./context.md) for full details.
-:::
+    You can provide additional fields defined in your agent’s state schema directly in the input dictionary. This allows dynamic behavior based on runtime data or prior tool outputs.  
+    See the [context guide](./context.md) for full details.
 
 !!! note
 
-:::python
-A string input for `messages` is converted to a [HumanMessage](https://python.langchain.com/docs/concepts/messages/#humanmessage). This behavior differs from the `prompt` parameter in `create_react_agent`, which is interpreted as a [SystemMessage](https://python.langchain.com/docs/concepts/messages/#systemmessage) when passed as a string.
-:::
+    A string input for `messages` is converted to a [HumanMessage](https://python.langchain.com/docs/concepts/messages/#humanmessage). This behavior differs from the `prompt` parameter in `create_react_agent`, which is interpreted as a [SystemMessage](https://python.langchain.com/docs/concepts/messages/#systemmessage) when passed as a string.
 
-:::js
-A string input for `messages` is converted to a [HumanMessage](https://js.langchain.com/docs/concepts/messages/#humanmessage). This behavior differs from the `prompt` parameter in `createReactAgent`, which is interpreted as a [SystemMessage](https://js.langchain.com/docs/concepts/messages/#systemmessage) when passed as a string.
-:::
 
 ## Output format
 
-:::python
 Agent output is a dictionary containing:
 
 - `messages`: A list of all messages exchanged during execution (user input, assistant replies, tool invocations).
 - Optionally, `structured_response` if [structured output](./agents.md#6-configure-structured-output) is configured.
 - If using a custom `state_schema`, additional keys corresponding to your defined fields may also be present in the output. These can hold updated state values from tool execution or prompt logic.
-  :::
-
-:::js
-Agent output is a dictionary containing:
-
-- `messages`: A list of all messages exchanged during execution (user input, assistant replies, tool invocations).
-- Optionally, `structuredResponse` if [structured output](./agents.md#6-configure-structured-output) is configured.
-- If using a custom state definition, additional keys corresponding to your defined fields may also be present in the output. These can hold updated state values from tool execution or prompt logic.
-  :::
 
 See the [context guide](./context.md) for more details on working with custom state schemas and accessing context.
 
@@ -155,7 +87,6 @@ Agents support streaming responses for more responsive applications. This includ
 
 Streaming is available in both sync and async modes:
 
-:::python
 === "Sync streaming"
 
     ```python
@@ -176,36 +107,14 @@ Streaming is available in both sync and async modes:
         print(chunk)
     ```
 
-:::
-
-:::js
-
-```typescript
-for await (const chunk of agent.stream(
-  { messages: [{ role: "user", content: "what is the weather in sf" }] },
-  { streamMode: "updates" }
-)) {
-  console.log(chunk);
-}
-```
-
-:::
-
 !!! tip
 
-    For full details, see the [streaming guide](../how-tos/streaming.md).
+    For full details, see the [streaming guide](./streaming.md).
 
 ## Max iterations
 
-:::python
 To control agent execution and avoid infinite loops, set a recursion limit. This defines the maximum number of steps the agent can take before raising a `GraphRecursionError`. You can configure `recursion_limit` at runtime or when defining agent via `.with_config()`:
-:::
 
-:::js
-To control agent execution and avoid infinite loops, set a recursion limit. This defines the maximum number of steps the agent can take before raising a `GraphRecursionError`. You can configure `recursionLimit` at runtime or when defining agent via `.withConfig()`:
-:::
-
-:::python
 === "Runtime"
 
     ```python
@@ -254,70 +163,6 @@ To control agent execution and avoid infinite loops, set a recursion limit. This
         print("Agent stopped due to max iterations.")
     ```
 
-:::
-
-:::js
-=== "Runtime"
-
-    ```typescript
-    import { GraphRecursionError } from "@langchain/langgraph";
-    import { ChatAnthropic } from "@langchain/langgraph/prebuilt";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-    const maxIterations = 3;
-    // highlight-next-line
-    const recursionLimit = 2 * maxIterations + 1;
-    const agent = createReactAgent({
-        llm: new ChatAnthropic({ model: "claude-3-5-haiku-latest" }),
-        tools: [getWeather]
-    });
-
-    try {
-        const response = await agent.invoke(
-            {"messages": [{"role": "user", "content": "what's the weather in sf"}]},
-            // highlight-next-line
-            { recursionLimit }
-        );
-    } catch (error) {
-        if (error instanceof GraphRecursionError) {
-            console.log("Agent stopped due to max iterations.");
-        }
-    }
-    ```
-
-=== "`.withConfig()`"
-
-    ```typescript
-    import { GraphRecursionError } from "@langchain/langgraph";
-    import { ChatAnthropic } from "@langchain/langgraph/prebuilt";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-    const maxIterations = 3;
-    // highlight-next-line
-    const recursionLimit = 2 * maxIterations + 1;
-    const agent = createReactAgent({
-        llm: new ChatAnthropic({ model: "claude-3-5-haiku-latest" }),
-        tools: [getWeather]
-    });
-    // highlight-next-line
-    const agentWithRecursionLimit = agent.withConfig({ recursionLimit });
-
-    try {
-        const response = await agentWithRecursionLimit.invoke(
-            {"messages": [{"role": "user", "content": "what's the weather in sf"}]},
-        );
-    } catch (error) {
-        if (error instanceof GraphRecursionError) {
-            console.log("Agent stopped due to max iterations.");
-        }
-    }
-    ```
-
-:::
-
-:::python
-
 ## Additional Resources
 
-- [Async programming in LangChain](https://python.langchain.com/docs/concepts/async)
-  :::
+* [Async programming in LangChain](https://python.langchain.com/docs/concepts/async)

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

@@ -9,7 +9,6 @@ hide:
 
 # Tools
 
-:::python
 [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.
 
 You can either [define your own tools](#define-simple-tools) or use [prebuilt integrations](#prebuilt-tools) that LangChain provides.
@@ -32,37 +31,9 @@ create_react_agent(
 ```
 
 `create_react_agent` automatically converts vanilla functions to [LangChain tools](https://python.langchain.com/docs/concepts/tools/#tool-interface).
-:::
-
-:::js
-[Tools](https://js.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.
-
-You can either [define your own tools](#define-simple-tools) or use [prebuilt integrations](#prebuilt-tools) that LangChain provides.
-
-## Define simple tools
-
-You can pass a vanilla function to `createReactAgent` to use as a tool:
-
-```typescript
-import { ChatAnthropic } from "@langchain/anthropic";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-function multiply(a: number, b: number): number {
-  return a * b;
-}
-
-createReactAgent({
-  llm: new ChatAnthropic({ model: "anthropic:claude-3-7-sonnet" }),
-  tools: [multiply],
-});
-```
-
-`createReactAgent` automatically converts vanilla functions to [LangChain tools](https://js.langchain.com/docs/concepts/tools/#tool-interface).
-:::
 
 ## Customize tools
 
-:::python
 For more control over tool behavior, use the `@tool` decorator:
 
 ```python
@@ -98,34 +69,6 @@ def multiply(a: int, b: int) -> int:
 ```
 
 For additional customization, refer to the [custom tools guide](https://python.langchain.com/docs/how_to/custom_tools/).
-:::
-
-:::js
-For more control over tool behavior, use the `tool` function:
-
-```typescript
-// highlight-next-line
-import { tool } from "@langchain/core/tools";
-import { z } from "zod";
-
-// highlight-next-line
-const multiply = tool(
-  (input) => {
-    return input.a * input.b;
-  },
-  {
-    name: "multiply_tool",
-    description: "Multiply two numbers",
-    schema: z.object({
-      a: z.number().describe("First operand"),
-      b: z.number().describe("Second operand"),
-    }),
-  }
-);
-```
-
-For additional customization, refer to the [custom tools guide](https://js.langchain.com/docs/how_to/custom_tools/).
-:::
 
 ## Hide arguments from the model
 
@@ -134,8 +77,6 @@ Some tools require runtime-only arguments (e.g., user ID or session context) tha
 You can put these arguments in the `state` or `config` of the agent, and access
 this information inside the tool:
 
-:::python
-
 ```python
 from langgraph.prebuilt import InjectedState
 from langgraph.prebuilt.chat_agent_executor import AgentState
@@ -157,49 +98,11 @@ def my_tool(
     ...
 ```
 
-:::
-
-:::js
-
-```typescript
-import { tool } from "@langchain/core/tools";
-import { LangGraphRunnableConfig } from "@langchain/langgraph";
-import { z } from "zod";
-
-const myTool = tool(
-  async (input, config: LangGraphRunnableConfig) => {
-    // This will be populated by an LLM
-    const toolArg = input.toolArg;
-
-    // access information that's dynamically updated inside the agent
-    // highlight-next-line
-    const state = config.store;
-
-    // access static data that is passed at agent invocation
-    // highlight-next-line
-    const userId = config.configurable?.userId;
-
-    // Use state and config in your tool logic
-    return "Tool result";
-  },
-  {
-    name: "my_tool",
-    description: "My tool",
-    schema: z.object({
-      toolArg: z.string().describe("Tool argument"),
-    }),
-  }
-);
-```
-
-:::
-
 ## Disable parallel tool calling
 
 Some model providers support executing multiple tools in parallel, but
 allow users to disable this feature.
 
-:::python
 For supported providers, you can disable parallel tool calling by setting `parallel_tool_calls=False` via the `model.bind_tools()` method:
 
 ```python
@@ -227,58 +130,8 @@ agent.invoke(
 )
 ```
 
-:::
-
-:::js
-For supported providers, you can disable parallel tool calling by setting `parallel_tool_calls: false` via the `bindTools()` method:
-
-```typescript
-import { ChatAnthropic } from "@langchain/anthropic";
-import { tool } from "@langchain/core/tools";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-import { z } from "zod";
-
-const add = tool((input) => input.a + input.b, {
-  name: "add",
-  description: "Add two numbers",
-  schema: z.object({
-    a: z.number(),
-    b: z.number(),
-  }),
-});
-
-const multiply = tool((input) => input.a * input.b, {
-  name: "multiply",
-  description: "Multiply two numbers",
-  schema: z.object({
-    a: z.number(),
-    b: z.number(),
-  }),
-});
-
-const model = new ChatAnthropic({
-  model: "claude-3-5-sonnet-latest",
-  temperature: 0,
-});
-const tools = [add, multiply];
-
-const agent = createReactAgent({
-  // disable parallel tool calls
-  // highlight-next-line
-  llm: model.bindTools(tools, { parallel_tool_calls: false }),
-  tools,
-});
-
-await agent.invoke({
-  messages: [{ role: "user", content: "what's 3 + 5 and 4 * 7?" }],
-});
-```
-
-:::
-
 ## Return tool results directly
 
-:::python
 Use `return_direct=True` to return tool results immediately and stop the agent loop:
 
 ```python
@@ -300,42 +153,8 @@ agent.invoke(
 )
 ```
 
-:::
-
-:::js
-Use `returnDirect: true` to return tool results immediately and stop the agent loop:
-
-```typescript
-import { tool } from "@langchain/core/tools";
-import { z } from "zod";
-
-// highlight-next-line
-const add = tool((input) => input.a + input.b, {
-  name: "add",
-  description: "Add two numbers",
-  schema: z.object({
-    a: z.number(),
-    b: z.number(),
-  }),
-  // highlight-next-line
-  returnDirect: true,
-});
-
-const agent = createReactAgent({
-  llm: model,
-  tools: [add],
-});
-
-await agent.invoke({
-  messages: [{ role: "user", content: "what's 3 + 5?" }],
-});
-```
-
-:::
-
 ## Force tool use
 
-:::python
 To force the agent to use specific tools, you can set the `tool_choice` option in `model.bind_tools()`:
 
 ```python
@@ -360,41 +179,6 @@ agent.invoke(
 )
 ```
 
-:::
-
-:::js
-To force the agent to use specific tools, you can set the `tool_choice` option in `bindTools()`:
-
-```typescript
-import { tool } from "@langchain/core/tools";
-import { z } from "zod";
-
-// highlight-next-line
-const greet = tool((input) => `Hello ${input.userName}!`, {
-  name: "greet",
-  description: "Greet user",
-  schema: z.object({
-    userName: z.string(),
-  }),
-  // highlight-next-line
-  returnDirect: true,
-});
-
-const tools = [greet];
-
-const agent = createReactAgent({
-  // highlight-next-line
-  llm: model.bindTools(tools, { tool_choice: { type: "tool", name: "greet" } }),
-  tools,
-});
-
-await agent.invoke({
-  messages: [{ role: "user", content: "Hi, I am Bob" }],
-});
-```
-
-:::
-
 !!! Warning "Avoid infinite loops"
 
     Forcing tool usage without stopping conditions can create infinite loops. Use one of the following safeguards:
@@ -404,17 +188,10 @@ await agent.invoke({
 
 ## Handle tool errors
 
-:::python
 By default, the agent will catch all exceptions raised during tool calls and will pass those as tool messages to the LLM. To control how the errors are handled, you can use the prebuilt [`ToolNode`][langgraph.prebuilt.tool_node.ToolNode] — the node that executes tools inside `create_react_agent` — via its `handle_tool_errors` parameter:
-:::
-
-:::js
-By default, the agent will catch all exceptions raised during tool calls and will pass those as tool messages to the LLM. To control how the errors are handled, you can use the prebuilt [`ToolNode`][<insert-ref>] — the node that executes tools inside `createReactAgent` — via its `handleToolErrors` parameter:
-:::
 
 === "Enable error handling (default)"
 
-    :::python
     ```python
     from langgraph.prebuilt import create_react_agent
 
@@ -433,47 +210,9 @@ By default, the agent will catch all exceptions raised during tool calls and wil
         {"messages": [{"role": "user", "content": "what's 42 x 7?"}]}
     )
     ```
-    :::
-
-    :::js
-    ```typescript
-    import { ChatAnthropic } from "@langchain/anthropic";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-    import { tool } from "@langchain/core/tools";
-    import { z } from "zod";
-
-    const multiply = tool(
-      (input) => {
-        if (input.a === 42) {
-          throw new Error("The ultimate error");
-        }
-        return input.a * input.b;
-      },
-      {
-        name: "multiply",
-        description: "Multiply two numbers",
-        schema: z.object({
-          a: z.number(),
-          b: z.number(),
-        }),
-      }
-    );
-
-    // Run with error handling (default)
-    const agent = createReactAgent({
-      llm: new ChatAnthropic({ model: "claude-3-7-sonnet-latest" }),
-      tools: [multiply]
-    });
-
-    await agent.invoke({
-      messages: [{ role: "user", content: "what's 42 x 7?" }]
-    });
-    ```
-    :::
 
 === "Disable error handling"
 
-    :::python
     ```python
     from langgraph.prebuilt import create_react_agent, ToolNode
 
@@ -499,58 +238,9 @@ By default, the agent will catch all exceptions raised during tool calls and wil
     ```
 
     1. This disables error handling (enabled by default). See all available strategies in the [API reference][langgraph.prebuilt.tool_node.ToolNode].
-    :::
-
-    :::js
-    ```typescript
-    import { ChatAnthropic } from "@langchain/anthropic";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-    import { ToolNode } from "@langchain/langgraph/prebuilt";
-    import { tool } from "@langchain/core/tools";
-    import { z } from "zod";
-
-    const multiply = tool(
-      (input) => {
-        if (input.a === 42) {
-          throw new Error("The ultimate error");
-        }
-        return input.a * input.b;
-      },
-      {
-        name: "multiply",
-        description: "Multiply two numbers",
-        schema: z.object({
-          a: z.number(),
-          b: z.number(),
-        }),
-      }
-    );
-
-    // highlight-next-line
-    const toolNode = new ToolNode(
-      [multiply],
-      {
-        // highlight-next-line
-        handleToolErrors: false  // (1)!
-      }
-    );
-
-    const agentNoErrorHandling = createReactAgent({
-      llm: new ChatAnthropic({ model: "claude-3-7-sonnet-latest" }),
-      tools: toolNode
-    });
-
-    await agentNoErrorHandling.invoke({
-      messages: [{ role: "user", content: "what's 42 x 7?" }]
-    });
-    ```
-
-    1. This disables error handling (enabled by default). See all available strategies in the [API reference][toolnode].
-    :::
 
 === "Custom error handling"
 
-    :::python
     ```python
     from langgraph.prebuilt import create_react_agent, ToolNode
 
@@ -578,80 +268,25 @@ By default, the agent will catch all exceptions raised during tool calls and wil
     ```
 
     1. This provides a custom message to send to the LLM in case of an exception. See all available strategies in the [API reference][langgraph.prebuilt.tool_node.ToolNode].
-    :::
 
-    :::js
-    ```typescript
-    import { ChatAnthropic } from "@langchain/anthropic";
-    import { createReactAgent } from "@langchain/langgraph/prebuilt";
-    import { ToolNode } from "@langchain/langgraph/prebuilt";
-    import { tool } from "@langchain/core/tools";
-    import { z } from "zod";
-
-    const multiply = tool(
-      (input) => {
-        if (input.a === 42) {
-          throw new Error("The ultimate error");
-        }
-        return input.a * input.b;
-      },
-      {
-        name: "multiply",
-        description: "Multiply two numbers",
-        schema: z.object({
-          a: z.number(),
-          b: z.number(),
-        }),
-      }
-    );
-
-    // highlight-next-line
-    const toolNode = new ToolNode(
-      [multiply],
-      {
-        // highlight-next-line
-        handleToolErrors: "Can't use 42 as a first operand, you must switch operands!"  // (1)!
-      }
-    );
-
-    const agentCustomErrorHandling = createReactAgent({
-      llm: new ChatAnthropic({ model: "claude-3-7-sonnet-latest" }),
-      tools: toolNode
-    });
-
-    await agentCustomErrorHandling.invoke({
-      messages: [{ role: "user", content: "what's 42 x 7?" }]
-    });
-    ```
-
-    1. This provides a custom message to send to the LLM in case of an exception. See all available strategies in the [API reference][toolnode].
-    :::
-
-:::python
 See [API reference][langgraph.prebuilt.tool_node.ToolNode] for more information on different tool error handling options.
-:::
-
-:::js
-See [API reference][toolnode] for more information on different tool error handling options.
-:::
 
 ## 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
 
-:::python
 You can use prebuilt tools from model providers by passing a dictionary with tool specs to the `tools` parameter of `create_react_agent`. For example, to use the `web_search_preview` tool from OpenAI:
 
 ```python
 from langgraph.prebuilt import create_react_agent
 
 agent = create_react_agent(
-    model="openai:gpt-4o-mini",
+    model="openai:gpt-4o-mini", 
     tools=[{"type": "web_search_preview"}]
 )
 response = agent.invoke(
@@ -662,31 +297,6 @@ response = agent.invoke(
 Additionally, 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.
 
 You can browse the full list of available integrations in the [LangChain integrations directory](https://python.langchain.com/docs/integrations/tools/).
-:::
-
-:::js
-You can use prebuilt tools from model providers by passing a dictionary with tool specs to the `tools` parameter of `createReactAgent`. For example, to use the `web_search_preview` tool from OpenAI:
-
-```typescript
-import { ChatAnthropic } from "@langchain/anthropic";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-
-const agent = createReactAgent({
-  llm: new ChatAnthropic({ model: "claude-3-7-sonnet-latest" }),
-  tools: [{ type: "web_search_preview" }],
-});
-
-const response = await agent.invoke({
-  messages: [
-    { role: "user", content: "What was a positive news story from today?" },
-  ],
-});
-```
-
-Additionally, 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.
-
-You can browse the full list of available integrations in the [LangChain integrations directory](https://js.langchain.com/docs/integrations/tools/).
-:::
 
 Some commonly used tool categories include:
 
@@ -697,3 +307,4 @@ Some commonly used tool categories include:
 - **APIs**: OpenWeatherMap, NewsAPI, and others
 
 These integrations can be configured and added to your agents using the same `tools` parameter shown in the examples above.
+

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/custom_docker.md

@@ -16,4 +16,4 @@ Users can add an array of additional lines to add to the Dockerfile following th
 }
 ```
 
-This would install the system packages required to use Pillow if we were working with `jpeg` or `png` image formats. 
+This would install the system packages required to use Pillow if we were working with `jpeq` or `png` image formats. 

docs/docs/cloud/deployment/self_hosted_control_plane.md

@@ -30,17 +30,18 @@ Before deploying, review the [conceptual guide for the Self-Hosted Control Plane
     1. `LangGraphPlatform CRD`: A CRD for LangGraph Platform deployments. This contains the spec for managing an instance of a LangGraph platform deployment.
     1. `operator`: This operator handles changes to your LangGraph Platform CRDs.
     1. `host-backend`: This is the [control plane](../../concepts/langgraph_control_plane.md).
-1. Two additional images will be used by the chart. Use the images that are specified in the latest release.
+1. Two additional images will be used by the chart.
 
         hostBackendImage:
           repository: "docker.io/langchain/hosted-langserve-backend"
           pullPolicy: IfNotPresent
+          tag: "0.9.80"
         operatorImage:
           repository: "docker.io/langchain/langgraph-operator"
           pullPolicy: IfNotPresent
+          tag: "aa9dff4"
 
-1. In your config file for langsmith (usually `langsmith_config.yaml`, enable the `langgraphPlatform` option. Note that you must also have a valid ingress setup:
-
+1. In your `values.yaml` file, enable the `langgraphPlatform` option. Note that you must also have a valid ingress setup:
         config:
           langgraphPlatform:
             enabled: true

docs/docs/cloud/deployment/setup.md

@@ -95,7 +95,7 @@ my-app/
 
 ## Define Graphs
 
-Implement your graphs! Graphs can be defined in a single file or multiple files. Make note of the variable names of each [CompiledStateGraph][langgraph.graph.state.CompiledStateGraph] to be included in the LangGraph application. The variable names will be used later when creating the [LangGraph configuration file](../reference/cli.md#configuration-file).
+Implement your graphs! Graphs can be defined in a single file or multiple files. Make note of the variable names of each [CompiledGraph][langgraph.graph.graph.CompiledGraph] to be included in the LangGraph application. The variable names will be used later when creating the [LangGraph configuration file](../reference/cli.md#configuration-file).
 
 Example `agent.py` file, which shows how to import from other modules you define (code for the modules is not shown here, please see [this repository](https://github.com/langchain-ai/langgraph-example) to see their implementation):
 

docs/docs/cloud/deployment/setup_pyproject.md

@@ -108,7 +108,7 @@ my-app/
 
 ## Define Graphs
 
-Implement your graphs! Graphs can be defined in a single file or multiple files. Make note of the variable names of each [CompiledStateGraph][langgraph.graph.state.CompiledStateGraph] to be included in the LangGraph application. The variable names will be used later when creating the [LangGraph configuration file](../reference/cli.md#configuration-file).
+Implement your graphs! Graphs can be defined in a single file or multiple files. Make note of the variable names of each [CompiledGraph][langgraph.graph.graph.CompiledGraph] to be included in the LangGraph application. The variable names will be used later when creating the [LangGraph configuration file](../reference/cli.md#configuration-file).
 
 Example `agent.py` file, which shows how to import from other modules you define (code for the modules is not shown here, please see [this repository](https://github.com/langchain-ai/langgraph-example-pyproject) to see their implementation):
 

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/manage_assistants.md

@@ -2,7 +2,7 @@
 
 !!! info "Prerequisites"
 
-    - [Assistants Overview](../../../concepts/assistants.md)
+    - [Assistants Overview](../../concepts/assistants.md)
 
 LangGraph Studio lets you view, edit, and update your assistants, and allows you to run your graph using these assistant configurations.
 

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_stream_react.md

@@ -1,8 +1,8 @@
-How to integrate LangGraph into your React application# How to integrate LangGraph into your React application
+# How to integrate LangGraph into your React application
 
-!!! info "Prerequisites"
+!!! info "Prerequisites" 
 
-    - [LangGraph Platform](../../concepts/langgraph_platform.md)
+    - [LangGraph Platform](../../concepts/langgraph_platform.md) 
     - [LangGraph Server](../../concepts/langgraph_server.md)
 
 The `useStream()` React hook provides a seamless way to integrate LangGraph into your React applications. It handles all the complexities of streaming, state management, and branching logic, letting you focus on building great chat experiences.
@@ -113,115 +113,6 @@ export default function App() {
 }
 ```
 
-### Resume a stream after page refresh
-
-The `useStream()` hook can automatically resume an ongoing run upon mounting by setting `reconnectOnMount: true`. This is useful for continuing a stream after a page refresh, ensuring no messages and events generated during the downtime are lost.
-
-```tsx
-const thread = useStream<{ messages: Message[] }>({
-  apiUrl: "http://localhost:2024",
-  assistantId: "agent",
-  reconnectOnMount: true,
-});
-```
-
-By default the ID of the created run is stored in `window.sessionStorage`, which can be swapped by passing a custom storage in `reconnectOnMount` instead. The storage is used to persist the in-flight run ID for a thread (under `lg:stream:${threadId}` key).
-
-```tsx
-const thread = useStream<{ messages: Message[] }>({
-  apiUrl: "http://localhost:2024",
-  assistantId: "agent",
-  reconnectOnMount: () => window.localStorage,
-});
-```
-
-You can also manually manage the resuming process by using the run callbacks to persist the run metadata and the `joinStream` function to resume the stream. Make sure to pass `streamResumable: true` when creating the run; otherwise some events might be lost.
-
-````tsx
-import type { Message } from "@langchain/langgraph-sdk";
-import { useStream } from "@langchain/langgraph-sdk/react";
-import { useCallback, useState, useEffect, useRef } from "react";
-
-export default function App() {
-  const [threadId, onThreadId] = useSearchParam("threadId");
-
-  const thread = useStream<{ messages: Message[] }>({
-    apiUrl: "http://localhost:2024",
-    assistantId: "agent",
-
-    threadId,
-    onThreadId,
-
-    onCreated: (run) => {
-      window.sessionStorage.setItem(`resume:${run.thread_id}`, run.run_id);
-    },
-    onFinish: (_, run) => {
-      window.sessionStorage.removeItem(`resume:${run?.thread_id}`);
-    },
-  });
-
-  // Ensure that we only join the stream once per thread.
-  const joinedThreadId = useRef<string | null>(null);
-  useEffect(() => {
-    if (!threadId) return;
-
-    const resume = window.sessionStorage.getItem(`resume:${threadId}`);
-    if (resume && joinedThreadId.current !== threadId) {
-      thread.joinStream(resume);
-      joinedThreadId.current = threadId;
-    }
-  }, [threadId]);
-
-  return (
-    <form
-      onSubmit={(e) => {
-        e.preventDefault();
-        const form = e.target as HTMLFormElement;
-        const message = new FormData(form).get("message") as string;
-        thread.submit(
-          { messages: [{ type: "human", content: message }] },
-          { streamResumable: true }
-        );
-      }}
-    >
-      <div>
-        {thread.messages.map((message) => (
-          <div key={message.id}>{message.content as string}</div>
-        ))}
-      </div>
-      <input type="text" name="message" />
-      <button type="submit">Send</button>
-    </form>
-  );
-}
-
-// Utility method to retrieve and persist data in URL as search param
-function useSearchParam(key: string) {
-  const [value, setValue] = useState<string | null>(() => {
-    const params = new URLSearchParams(window.location.search);
-    return params.get(key) ?? null;
-  });
-
-  const update = useCallback(
-    (value: string | null) => {
-      setValue(value);
-
-      const url = new URL(window.location.href);
-      if (value == null) {
-        url.searchParams.delete(key);
-      } else {
-        url.searchParams.set(key, value);
-      }
-
-      window.history.pushState({}, "", url.toString());
-    },
-    [key]
-  );
-
-  return [value, update] as const;
-}
-```
-
 ### Thread Management
 
 Keep track of conversations with built-in thread management. You can access the current thread ID and get notified when new threads are created:
@@ -236,7 +127,7 @@ const thread = useStream<{ messages: Message[] }>({
   threadId: threadId,
   onThreadId: setThreadId,
 });
-````
+```
 
 We recommend storing the `threadId` in your URL's query parameters to let users resume conversations after page refreshes.
 

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",
@@ -3836,14 +3818,6 @@
             "title": "Filter",
             "description": "Optional dictionary of key-value pairs to filter results."
           },
-          "query": {
-            "type": [
-              "string",
-              "null"
-            ],
-            "title": "Query",
-            "description": "Query string for semantic/vector search."
-          },
           "limit": {
             "type": "integer",
             "default": 10,

docs/docs/cloud/reference/cli.md

@@ -43,17 +43,15 @@ The LangGraph CLI requires a JSON configuration file that follows this [schema](
     | <span style="white-space: nowrap;">`graphs`</span>           | **Required**. Mapping from graph ID to path where the compiled graph or a function that makes a graph is defined. Example: <ul><li>`./your_package/your_file.py:variable`, where `variable` is an instance of `langgraph.graph.state.CompiledStateGraph`</li><li>`./your_package/your_file.py:make_graph`, where `make_graph` is a function that takes a config dictionary (`langchain_core.runnables.RunnableConfig`) and returns an instance of `langgraph.graph.state.StateGraph` or `langgraph.graph.state.CompiledStateGraph`. See [how to rebuild a graph at runtime](../../cloud/deployment/graph_rebuild.md) for more details.</li></ul>                                    |
     | <span style="white-space: nowrap;">`auth`</span>             | _(Added in v0.0.11)_ Auth configuration containing the path to your authentication handler. Example: `./your_package/auth.py:auth`, where `auth` is an instance of `langgraph_sdk.Auth`. See [authentication guide](../../concepts/auth.md) for details.                                                                                                                                                                                                                                                                                                                        |
     | <span style="white-space: nowrap;">`base_image`</span>       | Optional. Base image to use for the LangGraph API server. Defaults to `langchain/langgraph-api` or `langchain/langgraphjs-api`. Use this to pin your builds to a particular version of the langgraph API, such as `"langchain/langgraph-server:0.2"`. See https://hub.docker.com/r/langchain/langgraph-server/tags for more details. (added in `langgraph-cli==0.2.8`) |
-    | <span style="white-space: nowrap;">`image_distro`</span>     | Optional. Linux distribution for the base image. Must be either `"debian"` or `"wolfi"`. If omitted, defaults to `"debian"`. Available in `langgraph-cli>=0.2.11`.|
     | <span style="white-space: nowrap;">`env`</span>              | Path to `.env` file or a mapping from environment variable to its value.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
     | <span style="white-space: nowrap;">`store`</span>            | Configuration for adding semantic search and/or time-to-live (TTL) to the BaseStore. Contains the following fields: <ul><li>`index` (optional): Configuration for semantic search indexing with fields `embed`, `dims`, and optional `fields`.</li><li>`ttl` (optional): Configuration for item expiration. An object with optional fields: `refresh_on_read` (boolean, defaults to `true`), `default_ttl` (float, lifespan in **minutes**, defaults to no expiration), and `sweep_interval_minutes` (integer, how often to check for expired items, defaults to no sweeping).</li></ul> |
     | <span style="white-space: nowrap;">`ui`</span>               | Optional. Named definitions of UI components emitted by the agent, each pointing to a JS/TS file. (added in `langgraph-cli==0.1.84`)                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
     | <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"
 
@@ -81,20 +79,6 @@ The LangGraph CLI requires a JSON configuration file that follows this [schema](
     }
     ```
 
-    #### Using Wolfi Base Images
-
-    You can specify the Linux distribution for your base image using the `image_distro` field. Valid options are `debian` or `wolfi`. Wolfi is the recommended option as it provides smaller and more secure images. This is available in `langgraph-cli>=0.2.11`.
-
-    ```json
-    {
-      "dependencies": ["."],
-      "graphs": {
-        "chat": "./chat/graph.py:graph"
-      },
-      "image_distro": "wolfi"
-    }
-    ```
-
     #### Adding semantic search to the store
 
     All deployments come with a DB-backed BaseStore. Adding an "index" configuration to your `langgraph.json` will enable [semantic search](../deployment/semantic_search.md) within the BaseStore of your deployment.
@@ -129,7 +113,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 +346,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 +366,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`
 
@@ -122,12 +123,3 @@ Defaults to `''`.
 Set `REDIS_CLUSTER` to `True` to enable Redis Cluster mode. When enabled, the system will connect to Redis using cluster mode. This is useful when connecting to a Redis Cluster deployment.
 
 Defaults to `False`.
-
-## `MOUNT_PREFIX`
-
-!!! info "Only Allowed in Self-Hosted Deployments"
-    The `MOUNT_PREFIX` environment variable is only allowed in Self-Hosted Deployment models, LangGraph Platform SaaS will not allow this environment variable.
-
-Set `MOUNT_PREFIX` to serve the LangGraph Server under a specific path prefix. This is useful for deployments where the server is behind a reverse proxy or load balancer that requires a specific path prefix.
-
-For example, if the server is to be served under `https://example.com/langgraph`, set `MOUNT_PREFIX` to `/langgraph`.

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/application_structure.md

@@ -22,9 +22,8 @@ To deploy using the LangGraph Platform, the following information should be prov
 
 ## File Structure
 
-Below are examples of directory structures for applications:
+Below are examples of directory structures for Python and JavaScript applications:
 
-:::python
 === "Python (requirements.txt)"
 
     ```plaintext
@@ -33,7 +32,7 @@ Below are examples of directory structures for applications:
     │   ├── utils # utilities for your graph
     │   │   ├── __init__.py
     │   │   ├── tools.py # tools for your graph
-    │   │   ├── nodes.py # node functions for your graph
+    │   │   ├── nodes.py # node functions for you graph
     │   │   └── state.py # state definition of your graph
     │   ├── __init__.py
     │   └── agent.py # code for constructing your graph
@@ -41,7 +40,6 @@ Below are examples of directory structures for applications:
     ├── requirements.txt # package dependencies
     └── langgraph.json # configuration file for LangGraph
     ```
-
 === "Python (pyproject.toml)"
 
     ```plaintext
@@ -59,26 +57,20 @@ Below are examples of directory structures for applications:
     └── pyproject.toml # dependencies for your project
     ```
 
-:::
+=== "JS (package.json)"
 
-:::
-
-:::js
-
-```plaintext
-my-app/
-├── src # all project code lies within here
-│   ├── utils # optional utilities for your graph
-│   │   ├── tools.ts # tools for your graph
-│   │   ├── nodes.ts # node functions for your graph
-│   │   └── state.ts # state definition of your graph
-│   └── agent.ts # code for constructing your graph
-├── package.json # package dependencies
-├── .env # environment variables
-└── langgraph.json # configuration file for LangGraph
-```
-
-:::
+    ```plaintext
+    my-app/
+    ├── src # all project code lies within here
+    │   ├── utils # optional utilities for your graph
+    │   │   ├── tools.ts # tools for your graph
+    │   │   ├── nodes.ts # node functions for you graph
+    │   │   └── state.ts # state definition of your graph
+    │   └── agent.ts # code for constructing your graph
+    ├── package.json # package dependencies
+    ├── .env # environment variables
+    └── langgraph.json # configuration file for LangGraph
+    ```
 
 !!! note
 
@@ -96,66 +88,52 @@ See the [LangGraph configuration file reference](../cloud/reference/cli.md#confi
 
 ### Examples
 
-:::python
+=== "Python"
 
-- The dependencies involve a custom local package and the `langchain_openai` package.
-- A single graph will be loaded from the file `./your_package/your_file.py` with the variable `variable`.
-- The environment variables are loaded from the `.env` file.
+    * The dependencies involve a custom local package and the `langchain_openai` package.
+    * A single graph will be loaded from the file `./your_package/your_file.py` with the variable `variable`.
+    * The environment variables are loaded from the `.env` file.
 
-```json
-{
-  "dependencies": ["langchain_openai", "./your_package"],
-  "graphs": {
-    "my_agent": "./your_package/your_file.py:agent"
-  },
-  "env": "./.env"
-}
-```
+    ```json
+    {
+        "dependencies": [
+            "langchain_openai",
+            "./your_package"
+        ],
+        "graphs": {
+            "my_agent": "./your_package/your_file.py:agent"
+        },
+        "env": "./.env"
+    }
+    ```
 
-:::
+=== "JavaScript"
 
-:::js
+    * The dependencies will be loaded from a dependency file in the local directory (e.g., `package.json`).
+    * A single graph will be loaded from the file `./your_package/your_file.js` with the function `agent`.
+    * The environment variable `OPENAI_API_KEY` is set inline.
 
-- The dependencies will be loaded from a dependency file in the local directory (e.g., `package.json`).
-- A single graph will be loaded from the file `./your_package/your_file.js` with the function `agent`.
-- The environment variable `OPENAI_API_KEY` is set inline.
-
-```json
-{
-  "dependencies": ["."],
-  "graphs": {
-    "my_agent": "./your_package/your_file.js:agent"
-  },
-  "env": {
-    "OPENAI_API_KEY": "secret-key"
-  }
-}
-```
-
-:::
+    ```json
+    {
+        "dependencies": [
+            "."
+        ],
+        "graphs": {
+            "my_agent": "./your_package/your_file.js:agent"
+        },
+        "env": {
+            "OPENAI_API_KEY": "secret-key"
+        }
+    }
+    ```
 
 ## Dependencies
 
-:::python
-A LangGraph application may depend on other Python packages.
-:::
-
-:::js
-A LangGraph application may depend on other TypeScript/JavaScript libraries.
-:::
+A LangGraph application may depend on other Python packages or JavaScript libraries (depending on the programming language in which the application is written).
 
 You will generally need to specify the following information for dependencies to be set up correctly:
 
-:::python
-
 1. A file in the directory that specifies the dependencies (e.g. `requirements.txt`, `pyproject.toml`, or `package.json`).
-   :::
-
-:::js
-
-1. A file in the directory that specifies the dependencies (e.g. `package.json`).
-   :::
-
 2. A `dependencies` key in the [LangGraph configuration file](#configuration-file-concepts) that specifies the dependencies required to run the LangGraph application.
 3. Any additional binaries or system libraries can be specified using `dockerfile_lines` key in the [LangGraph configuration file](#configuration-file-concepts).
 

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 their versions. See the [API reference](../cloud/reference/api/api_ref.html#tag/assistants) for more details.

docs/docs/concepts/auth.md

@@ -16,13 +16,7 @@ While often used interchangeably, these terms represent distinct security concep
 - [**Authentication**](#authentication) ("AuthN") verifies _who_ you are. This runs as middleware for every request.
 - [**Authorization**](#authorization) ("AuthZ") determines _what you can do_. This validates the user's privileges and roles on a per-resource basis.
 
-:::python
 In LangGraph Platform, authentication is handled by your [`@auth.authenticate`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.authenticate) handler, and authorization is handled by your [`@auth.on`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.on) handlers.
-:::
-
-:::js
-In LangGraph Platform, authentication is handled by your [`@auth.authenticate`](../cloud/reference/sdk/typescript_sdk_ref.md#auth.authenticate) handler, and authorization is handled by your [`@auth.on`](../cloud/reference/sdk/typescript_sdk_ref.md#auth.on) handlers.
-:::
 
 ## Default Security Models
 
@@ -35,7 +29,7 @@ LangGraph Platform provides different security defaults:
 - Can be customized with your auth handler
 
 !!! note "Custom auth"
-Custom auth **is supported** for all plans in LangGraph Platform.
+    Custom auth **is supported** for all plans in LangGraph Platform.
 
 ### Self-Hosted
 
@@ -44,8 +38,8 @@ Custom auth **is supported** for all plans in LangGraph Platform.
 - You control all aspects of authentication and authorization
 
 !!! note "Custom auth"
-Custom auth is supported for **Enterprise** self-hosted deployments.
-Standalone Container (Lite) deployments do not support custom auth natively.
+    Custom auth is supported for **Enterprise** self-hosted deployments.
+    Standalone Container (Lite) deployments do not support custom auth natively.
 
 ## System Architecture
 
@@ -53,24 +47,24 @@ A typical authentication setup involves three main components:
 
 1. **Authentication Provider** (Identity Provider/IdP)
 
-   - A dedicated service that manages user identities and credentials
-   - Handles user registration, login, password resets, etc.
-   - Issues tokens (JWT, session tokens, etc.) after successful authentication
-   - Examples: Auth0, Supabase Auth, Okta, or your own auth server
+    * A dedicated service that manages user identities and credentials
+    * Handles user registration, login, password resets, etc.
+    * Issues tokens (JWT, session tokens, etc.) after successful authentication
+    * Examples: Auth0, Supabase Auth, Okta, or your own auth server
 
 2. **LangGraph Backend** (Resource Server)
 
-   - Your LangGraph application that contains business logic and protected resources
-   - Validates tokens with the auth provider
-   - Enforces access control based on user identity and permissions
-   - Doesn't store user credentials directly
+    * Your LangGraph application that contains business logic and protected resources
+    * Validates tokens with the auth provider
+    * Enforces access control based on user identity and permissions
+    * Doesn't store user credentials directly
 
 3. **Client Application** (Frontend)
 
-   - Web app, mobile app, or API client
-   - Collects time-sensitive user credentials and sends to auth provider
-   - Receives tokens from auth provider
-   - Includes these tokens in requests to LangGraph backend
+    * Web app, mobile app, or API client
+    * Collects time-sensitive user credentials and sends to auth provider
+    * Receives tokens from auth provider
+    * Includes these tokens in requests to LangGraph backend
 
 Here's how these components typically interact:
 
@@ -90,22 +84,15 @@ sequenceDiagram
     LG-->>Client: 8. Return resources
 ```
 
-:::python
 Your [`@auth.authenticate`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.authenticate) handler in LangGraph handles steps 4-6, while your [`@auth.on`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.on) handlers implement step 7.
-:::
-
-:::js
-Your [`auth.authenticate`](<insert-ref (https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#authenticate)>) handler in LangGraph handles steps 4-6, while your [`auth.on`](<insert-ref https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#on>) handlers implement step 7.
-:::
 
 ## Authentication
 
-:::python
 Authentication in LangGraph runs as middleware on every request. Your [`@auth.authenticate`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.authenticate) handler receives request information and should:
 
 1. Validate the credentials
 2. Return [user info](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.types.MinimalUserDict) containing the user's identity and user information if valid
-3. Raise an [HTTPException](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.exceptions.HTTPException) or AssertionError if invalid
+3. Raise an [HTTP exception](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.exceptions.HTTPException) or AssertionError if invalid
 
 ```python
 from langgraph_sdk import Auth
@@ -139,49 +126,9 @@ The returned user information is available:
 
 - To your authorization handlers via [`ctx.user`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.types.AuthContext)
 - In your application via `config["configuration"]["langgraph_auth_user"]`
-  :::
-
-:::js
-Authentication in LangGraph runs as middleware on every request. Your [`authenticate`](<insert-ref https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#authenticate>) handler receives request information and should:
-
-1. Validate the credentials
-2. Return user information containing the user's identity and user information if valid
-3. Raise an [HTTPException](<insert-ref https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#class-httpexception>) if invalid
-
-```typescript
-import { Auth, HTTPException } from "@langchain/langgraph-sdk";
-
-export const auth = new Auth();
-
-auth.authenticate(async (request) => {
-  // Validate credentials (e.g., API key, JWT token)
-  const apiKey = request.headers.get("x-api-key");
-  if (!apiKey || !isValidKey(apiKey)) {
-    throw new HTTPException(401, "Invalid API key");
-  }
-
-  // Return user info - only identity and isAuthenticated are required
-  // Add any additional fields you need for authorization
-  return {
-    identity: "user-123", // Required: unique user identifier
-    isAuthenticated: true, // Optional: assumed true by default
-    permissions: ["read", "write"], // Optional: for permission-based auth
-    // You can add more custom fields if you want to implement other auth patterns
-    role: "admin",
-    orgId: "org-456",
-  };
-});
-```
-
-The returned user information is available:
-
-- To your authorization handlers via the `user` property in a [callback handler](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#on)
-- In your application via `config.configurable.langgraph_auth_user`
-  :::
 
 ??? tip "Supported Parameters"
 
-    :::python
     The [`@auth.authenticate`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.authenticate) handler can accept any of the following parameters by name:
 
     * request (Request): The raw ASGI request object
@@ -192,36 +139,19 @@ The returned user information is available:
     * query_params (dict[str, str]): URL query parameters, e.g., {"stream": "true"}
     * headers (dict[bytes, bytes]): Request headers
     * authorization (str | None): The Authorization header value (e.g., "Bearer <token>")
-    :::
-
-    :::js
-    The [`authenticate`](<insert-ref https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#authenticate>) handler can accept any of the following parameters:
-
-    * request (Request): The raw request object
-    * body (object): The parsed request body
-    * path (string): The request path, e.g., "/threads/abcd-1234-abcd-1234/runs/abcd-1234-abcd-1234/stream"
-    * method (string): The HTTP method, e.g., "GET"
-    * pathParams (Record<string, string>): URL path parameters, e.g., {"threadId": "abcd-1234-abcd-1234", "runId": "abcd-1234-abcd-1234"}
-    * queryParams (Record<string, string>): URL query parameters, e.g., {"stream": "true"}
-    * headers (Record<string, string>): Request headers
-    * authorization (string | null): The Authorization header value (e.g., "Bearer <token>")
-    :::
-
+    
     In many of our tutorials, we will just show the "authorization" parameter to be concise, but you can opt to accept more information as needed
     to implement your custom authentication scheme.
 
 ## Authorization
 
-After authentication, LangGraph calls your authorization handlers to control access to specific resources (e.g., threads, assistants, crons). These handlers can:
+After authentication, LangGraph calls your [`@auth.on`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.on) handlers to control access to specific resources (e.g., threads, assistants, crons). These handlers can:
 
-1. Add metadata to be saved during resource creation by mutating the metadata. See the [supported actions table](#supported-actions) for the list of types the value can take for each action.
-2. Filter resources by metadata during search/list or read operations by returning a [filter](#filter-operations).
+1. Add metadata to be saved during resource creation by mutating the `value["metadata"]` dictionary directly. See the [supported actions table](#supported-actions) for the list of types the value can take for each action.
+2. Filter resources by metadata during search/list or read operations by returning a [filter dictionary](#filter-operations).
 3. Raise an HTTP exception if access is denied.
 
-If you want to just implement simple user-scoped access control, you can use a single authorization handler for all resources and actions. If you want to have different control depending on the resource and action, you can use [resource-specific handlers](#resource-specific-handlers). See the [Supported Resources](#supported-resources) section for a full list of the resources that support access control.
-
-:::python
-Your [`@auth.on`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.on) handlers control access by mutating the `value["metadata"]` dictionary directly and returning a [filter dictionary](#filter-operations).
+If you want to just implement simple user-scoped access control, you can use a single [`@auth.on`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.on) handler for all resources and actions. If you want to have different control depending on the resource and action, you can use [resource-specific handlers](#resource-specific-handlers). See the [Supported Resources](#supported-resources) section for a full list of the resources that support access control.
 
 ```python
 @auth.on
@@ -263,45 +193,12 @@ async def add_owner(
     return filters
 ```
 
-:::
-
-:::js
-You can granularly control access by mutating the `value.metadata` object directly and returning a [filter object](#filter-operations) when registering an [`on()`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#on) handler.
-
-```typescript
-import { Auth, HTTPException } from "@langchain/langgraph-sdk/auth";
-
-export const auth = new Auth()
-  .authenticate(async (request: Request) => ({
-    identity: "user-123",
-    permissions: [],
-  }))
-  .on("*", ({ value, user }) => {
-    // Create filter to restrict access to just this user's resources
-    const filters = { owner: user.identity };
-
-    // If the operation supports metadata, add the user identity
-    // as metadata to the resource.
-    if ("metadata" in value) {
-      value.metadata ??= {};
-      value.metadata.owner = user.identity;
-    }
-
-    // Return filters to restrict access
-    // These filters are applied to ALL operations (create, read, update, search, etc.)
-    // to ensure users can only access their own resources
-    return filters;
-  });
-```
-
-:::
-
 ### Resource-Specific Handlers {#resource-specific-handlers}
 
-You can register handlers for specific resources and actions by chaining the resource and action names together with the authorization decorator.
+You can register handlers for specific resources and actions by chaining the resource and action names together with the [`@auth.on`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.on) decorator.
 When a request is made, the most specific handler that matches that resource and action is called. Below is an example of how to register handlers for specific resources and actions. For the following setup:
 
-1. Authenticated users are able to create threads, read threads, and create runs on threads
+1. Authenticated users are able to create threads, read thread, create runs on threads
 2. Only users with the "assistants:create" permission are allowed to create new assistants
 3. All other endpoints (e.g., e.g., delete assistant, crons, store) are disabled for all users.
 
@@ -309,8 +206,6 @@ When a request is made, the most specific handler that matches that resource and
 
     For a full list of supported resources and actions, see the [Supported Resources](#supported-resources) section below.
 
-:::python
-
 ```python
 # Generic / global handler catches calls that aren't handled by more specific handlers
 @auth.on
@@ -395,104 +290,11 @@ async def on_assistant_create(
         )
 ```
 
-:::
-
-:::js
-
-```typescript
-import { Auth, HTTPException } from "@langchain/langgraph-sdk/auth";
-
-export const auth = new Auth()
-  .authenticate(async (request: Request) => ({
-    identity: "user-123",
-    permissions: ["threads:write", "threads:read"],
-  }))
-  .on("*", ({ event, user }) => {
-    console.log(`Request for ${event} by ${user.identity}`);
-    throw new HTTPException(403, { message: "Forbidden" });
-  })
-
-  // Matches the "threads" resource and all actions - create, read, update, delete, search
-  // Since this is **more specific** than the generic `on("*")` handler, it will take precedence over the generic handler for all actions on the "threads" resource
-  .on("threads", ({ permissions, value, user }) => {
-    if (!permissions.includes("write")) {
-      throw new HTTPException(403, {
-        message: "User lacks the required permissions.",
-      });
-    }
-
-    // Not all events do include `metadata` property in `value`.
-    // So we need to add this type guard.
-    if ("metadata" in value) {
-      value.metadata ??= {};
-      value.metadata.owner = user.identity;
-    }
-
-    return { owner: user.identity };
-  })
-
-  // Thread creation. This will match only on thread create actions.
-  // Since this is **more specific** than both the generic `on("*")` handler and the `on("threads")` handler, it will take precedence for any "create" actions on the "threads" resources
-  .on("threads:create", ({ value, user, permissions }) => {
-    if (!permissions.includes("write")) {
-      throw new HTTPException(403, {
-        message: "User lacks the required permissions.",
-      });
-    }
-
-    // Setting metadata on the thread being created will ensure that the resource contains an "owner" field
-    // Then any time a user tries to access this thread or runs within the thread,
-    // we can filter by owner
-    value.metadata ??= {};
-    value.metadata.owner = user.identity;
-
-    return { owner: user.identity };
-  })
-
-  // Reading a thread. Since this is also more specific than the generic `on("*")` handler, and the `on("threads")` handler,
-  .on("threads:read", ({ user }) => {
-    // Since we are reading (and not creating) a thread,
-    // we don't need to set metadata. We just need to
-    // return a filter to ensure users can only see their own threads.
-    return { owner: user.identity };
-  })
-
-  // Run creation, streaming, updates, etc.
-  // This takes precedence over the generic `on("*")` handler and the `on("threads")` handler
-  .on("threads:create_run", ({ value, user }) => {
-    value.metadata ??= {};
-    value.metadata.owner = user.identity;
-
-    return { owner: user.identity };
-  })
-
-  // Assistant creation. This will match only on assistant create actions.
-  // Since this is **more specific** than both the generic `on("*")` handler and the `on("assistants")` handler, it will take precedence for any "create" actions on the "assistants" resources
-  .on("assistants:create", ({ value, user, permissions }) => {
-    if (!permissions.includes("assistants:create")) {
-      throw new HTTPException(403, {
-        message: "User lacks the required permissions.",
-      });
-    }
-
-    // Setting metadata on the assistant being created will ensure that the resource contains an "owner" field.
-    // Then any time a user tries to access this assistant, we can filter by owner
-    value.metadata ??= {};
-    value.metadata.owner = user.identity;
-
-    return { owner: user.identity };
-  });
-```
-
-:::
-
 Notice that we are mixing global and resource-specific handlers in the above example. Since each request is handled by the most specific handler, a request to create a `thread` would match the `on_thread_create` handler but NOT the `reject_unhandled_requests` handler. A request to `update` a thread, however would be handled by the global handler, since we don't have a more specific handler for that resource and action.
 
 ### Filter Operations {#filter-operations}
 
-:::python
-Authorization handlers can return different types of values:
-
+Authorization handlers can return `None`, a boolean, or a filter dictionary.
 - `None` and `True` mean "authorize access to all underling resources"
 - `False` means "deny access to all underling resources (raises a 403 exception)"
 - A metadata filter dictionary will restrict access to resources
@@ -505,24 +307,6 @@ A filter dictionary is a dictionary with keys that match the resource metadata.
 
 A dictionary with multiple keys is treated using a logical `AND` filter. For example, `{"owner": org_id, "allowed_users": {"$contains": user_id}}` will only match resources with metadata whose "owner" is `org_id` and whose "allowed_users" list contains `user_id`.
 See the reference [here](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.types.FilterType) for more information.
-:::
-
-:::js
-Authorization handlers can return different types of values:
-
-- `null` and `true` mean "authorize access to all underling resources"
-- `false` means "deny access to all underling resources (raises a 403 exception)"
-- A metadata filter object will restrict access to resources
-
-A filter object is an object with keys that match the resource metadata. It supports three operators:
-
-- The default value is a shorthand for exact match, or "$eq", below. For example, `{ owner: userId}` will include only resources with metadata containing `{ owner: userId }`
-- `$eq`: Exact match (e.g., `{ owner: { $eq: userId } }`) - this is equivalent to the shorthand above, `{ owner: userId }`
-- `$contains`: List membership (e.g., `{ allowedUsers: { $contains: userId} }`) The value here must be an element of the list. The metadata in the stored resource must be a list/container type.
-
-An object with multiple keys is treated using a logical `AND` filter. For example, `{ owner: orgId, allowedUsers: { $contains: userId} }` will only match resources with metadata whose "owner" is `orgId` and whose "allowedUsers" list contains `userId`.
-See the reference [here](../cloud/reference/sdk/typescript_sdk_ref.md#auth.types.FilterType) for more information.
-:::
 
 ## Common Access Patterns
 
@@ -532,8 +316,6 @@ Here are some typical authorization patterns:
 
 This common pattern lets you scope all threads, assistants, crons, and runs to a single user. It's useful for common single-user use cases like regular chatbot-style apps.
 
-:::python
-
 ```python
 @auth.on
 async def owner_only(ctx: Auth.types.AuthContext, value: dict):
@@ -542,33 +324,10 @@ async def owner_only(ctx: Auth.types.AuthContext, value: dict):
     return {"owner": ctx.user.identity}
 ```
 
-:::
-
-:::js
-
-```typescript
-export const auth = new Auth()
-  .authenticate(async (request: Request) => ({
-    identity: "user-123",
-    permissions: ["threads:write", "threads:read"],
-  }))
-  .on("*", ({ value, user }) => {
-    if ("metadata" in value) {
-      value.metadata ??= {};
-      value.metadata.owner = user.identity;
-    }
-    return { owner: user.identity };
-  });
-```
-
-:::
-
 ### Permission-based Access
 
 This pattern lets you control access based on **permissions**. It's useful if you want certain roles to have broader or more restricted access to resources.
 
-:::python
-
 ```python
 # In your auth handler:
 @auth.authenticate
@@ -605,72 +364,19 @@ async def rbac_create(ctx: Auth.types.AuthContext, value: dict):
     return _default(ctx, value)
 ```
 
-:::
-
-:::js
-
-```typescript
-import { Auth, HTTPException } from "@langchain/langgraph-sdk/auth";
-
-export const auth = new Auth()
-  .authenticate(async (request: Request) => ({
-    identity: "user-123",
-    // Define permissions in auth
-    permissions: ["threads:write", "threads:read"],
-  }))
-  .on("threads:create", ({ value, user, permissions }) => {
-    if (!permissions.includes("threads:write")) {
-      throw new HTTPException(403, { message: "Unauthorized" });
-    }
-
-    if ("metadata" in value) {
-      value.metadata ??= {};
-      value.metadata.owner = user.identity;
-    }
-    return { owner: user.identity };
-  })
-  .on("threads:read", ({ user, permissions }) => {
-    if (
-      !permissions.includes("threads:read") &&
-      !permissions.includes("threads:write")
-    ) {
-      throw new HTTPException(403, { message: "Unauthorized" });
-    }
-
-    return { owner: user.identity };
-  });
-```
-
-:::
-
 ## Supported Resources
 
 LangGraph provides three levels of authorization handlers, from most general to most specific:
 
-:::python
-
 1. **Global Handler** (`@auth.on`): Matches all resources and actions
 2. **Resource Handler** (e.g., `@auth.on.threads`, `@auth.on.assistants`, `@auth.on.crons`): Matches all actions for a specific resource
 3. **Action Handler** (e.g., `@auth.on.threads.create`, `@auth.on.threads.read`): Matches a specific action on a specific resource
 
 The most specific matching handler will be used. For example, `@auth.on.threads.create` takes precedence over `@auth.on.threads` for thread creation.
 If a more specific handler is registered, the more general handler will not be called for that resource and action.
-:::
 
-:::js
-
-1. **Global Handler** (`on("*")`): Matches all resources and actions
-2. **Resource Handler** (e.g., `on("threads")`, `on("assistants")`, `on("crons")`): Matches all actions for a specific resource
-3. **Action Handler** (e.g., `on("threads:create")`, `on("threads:read")`): Matches a specific action on a specific resource
-
-The most specific matching handler will be used. For example, `on("threads:create")` takes precedence over `on("threads")` for thread creation.
-If a more specific handler is registered, the more general handler will not be called for that resource and action.
-:::
-
-:::python
 ???+ tip "Type Safety"
-Each handler has type hints available for its `value` parameter. For example:
-
+    Each handler has type hints available for its `value` parameter at `Auth.types.on.<resource>.<action>.value`. For example:
     ```python
     @auth.on.threads.create
     async def on_thread_create(
@@ -678,14 +384,14 @@ Each handler has type hints available for its `value` parameter. For example:
         value: Auth.types.on.threads.create.value  # Specific type for thread creation
     ):
         ...
-
+    
     @auth.on.threads
     async def on_threads(
         ctx: Auth.types.AuthContext,
         value: Auth.types.on.threads.value  # Union type of all thread actions
     ):
         ...
-
+    
     @auth.on
     async def on_all(
         ctx: Auth.types.AuthContext,
@@ -693,17 +399,11 @@ Each handler has type hints available for its `value` parameter. For example:
     ):
         ...
     ```
-    :::
-
     More specific handlers provide better type hints since they handle fewer action types.
 
-:::
-
 #### Supported actions and types {#supported-actions}
-
 Here are all the supported action handlers:
 
-:::python
 | Resource | Handler | Description | Value Type |
 |----------|---------|-------------|------------|
 | **Threads** | `@auth.on.threads.create` | Thread creation | [`ThreadsCreate`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.types.ThreadsCreate) |
@@ -722,40 +422,12 @@ Here are all the supported action handlers:
 | | `@auth.on.crons.update` | Cron job updates | [`CronsUpdate`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.types.CronsUpdate) |
 | | `@auth.on.crons.delete` | Cron job deletion | [`CronsDelete`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.types.CronsDelete) |
 | | `@auth.on.crons.search` | Listing cron jobs | [`CronsSearch`](../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.types.CronsSearch) |
-:::
-
-:::js
-| Resource | Event | Description | Value Type |
-| -------------- | -------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------ |
-| **Threads** | `threads:create` | Thread creation | [`ThreadsCreate`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#threadscreate) |
-| | `threads:read` | Thread retrieval | [`ThreadsRead`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#threadsread) |
-| | `threads:update` | Thread updates | [`ThreadsUpdate`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#threadsupdate) |
-| | `threads:delete` | Thread deletion | [`ThreadsDelete`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#threadsdelete) |
-| | `threads:search` | Listing threads | [`ThreadsSearch`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#threadssearch) |
-| | `threads:create_run` | Creating or updating a run | [`RunsCreate`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#threadscreate_run) |
-| **Assistants** | `assistants:create` | Assistant creation | [`AssistantsCreate`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#assistantscreate) |
-| | `assistants:read` | Assistant retrieval | [`AssistantsRead`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#assistantsread) |
-| | `assistants:update` | Assistant updates | [`AssistantsUpdate`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#assistantsupdate) |
-| | `assistants:delete` | Assistant deletion | [`AssistantsDelete`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#assistantsdelete) |
-| | `assistants:search` | Listing assistants | [`AssistantsSearch`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#assistantssearch) |
-| **Crons** | `crons:create` | Cron job creation | [`CronsCreate`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#cronscreate) |
-| | `crons:read` | Cron job retrieval | [`CronsRead`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#cronsread) |
-| | `crons:update` | Cron job updates | [`CronsUpdate`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#cronsupdate) |
-| | `crons:delete` | Cron job deletion | [`CronsDelete`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#cronsdelete) |
-| | `crons:search` | Listing cron jobs | [`CronsSearch`](https://langchain-ai.github.io/langgraph/cloud/reference/sdk/js_ts_sdk_ref/#cronssearch) |
-:::
 
 ???+ note "About Runs"
 
     Runs are scoped to their parent thread for access control. This means permissions are typically inherited from the thread, reflecting the conversational nature of the data model. All run operations (reading, listing) except creation are controlled by the thread's handlers.
-
-    :::python
     There is a specific `create_run` handler for creating new runs because it had more arguments that you can view in the handler.
-    :::
 
-    :::js
-    There is a specific `threads:create_run` handler for creating new runs because it had more arguments that you can view in the handler.
-    :::
 
 ## Next Steps
 

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 |
@@ -68,7 +59,7 @@ For more information, please see:
 !!! info "Important"
     The Self-Hosted Control Plane deployment option is currently in beta stage and requires an [Enterprise](../concepts/plans.md) plan.
 
-The [Self-Hosted Control Plane](./langgraph_self_hosted_control_plane.md) deployment option is a fully self-hosted model for deployment where you manage the [control plane](./langgraph_control_plane.md) and [data plane](./langgraph_data_plane.md) in your cloud. This option gives you full control and responsibility of the control plane and data plane infrastructure.
+The [Self-Hosted Control Plane](./langgraph_self_hosted_control_plane.md) deployment option is a fully self-hosted model for deployment where you manage the [control plane](./langgraph_control_plane.md) and [data plane](./langgraph_data_plane.md) in your cloud. This option give you full control and responsibility of the control plane and data plane infrastructure.
 
 Build a Docker image using the [LangGraph CLI](./langgraph_cli.md) and deploy your LangGraph Server from the [control plane UI](./langgraph_control_plane.md#control-plane-ui).
 

docs/docs/concepts/durable_execution.md

@@ -5,7 +5,7 @@ search:
 
 # Durable Execution
 
-**Durable execution** is a technique in which a process or workflow saves its progress at key points, allowing it to pause and later resume exactly where it left off. This is particularly useful in scenarios that require [human-in-the-loop](./human_in_the_loop.md), where users can inspect, validate, or modify the process before continuing, and in long-running tasks that might encounter interruptions or errors (e.g., calls to an LLM timing out). By preserving completed work, durable execution enables a process to resume without reprocessing previous steps -- even after a significant delay (e.g., a week later).
+**Durable execution** is a technique in which a process or workflow saves its progress at key points, allowing it to pause and later resume exactly where it left off. This is particularly useful in scenarios that require [human-in-the-loop](./human_in_the_loop.md), where users can inspect, validate, or modify the process before continuing, and in long-running tasks that might encounter interruptions or errors (e.g., calls to an LLM timing out). By preserving completed work, durable execution enables a process to resume without reprocessing previous steps -- even after a significant delay (e.g., a week later). 
 
 LangGraph's built-in [persistence](./persistence.md) layer provides durable execution for workflows, ensuring that the state of each execution step is saved to a durable store. This capability guarantees that if a workflow is interrupted -- whether by a system failure or for [human-in-the-loop](./human_in_the_loop.md) interactions -- it can be resumed from its last recorded state.
 
@@ -20,12 +20,7 @@ To leverage durable execution in LangGraph, you need to:
 
 1. Enable [persistence](./persistence.md) in your workflow by specifying a [checkpointer](./persistence.md#checkpointer-libraries) that will save workflow progress.
 2. Specify a [thread identifier](./persistence.md#threads) when executing a workflow. This will track the execution history for a particular instance of the workflow.
-
-:::python 3. Wrap any non-deterministic operations (e.g., random number generation) or operations with side effects (e.g., file writes, API calls) inside [tasks][langgraph.func.task] to ensure that when a workflow is resumed, these operations are not repeated for the particular run, and instead their results are retrieved from the persistence layer. For more information, see [Determinism and Consistent Replay](#determinism-and-consistent-replay).
-:::
-
-:::js 3. Wrap any non-deterministic operations (e.g., random number generation) or operations with side effects (e.g., file writes, API calls) inside [tasks][<insert-ref>] to ensure that when a workflow is resumed, these operations are not repeated for the particular run, and instead their results are retrieved from the persistence layer. For more information, see [Determinism and Consistent Replay](#determinism-and-consistent-replay).
-:::
+3. Wrap any non-deterministic operations (e.g., random number generation) or operations with side effects (e.g., file writes, API calls) inside [tasks][langgraph.func.task] to ensure that when a workflow is resumed, these operations are not repeated for the particular run, and instead their results are retrieved from the persistence layer. For more information, see [Determinism and Consistent Replay](#determinism-and-consistent-replay).
 
 ## Determinism and Consistent Replay
 
@@ -35,25 +30,17 @@ As a result, when you are writing a workflow for durable execution, you must wra
 
 To ensure that your workflow is deterministic and can be consistently replayed, follow these guidelines:
 
-- **Avoid Repeating Work**: If a [node](./low_level.md#nodes) contains multiple operations with side effects (e.g., logging, file writes, or network calls), wrap each operation in a separate **task**. This ensures that when the workflow is resumed, the operations are not repeated, and their results are retrieved from the persistence layer.
-- **Encapsulate Non-Deterministic Operations:** Wrap any code that might yield non-deterministic results (e.g., random number generation) inside **tasks** or **nodes**. This ensures that, upon resumption, the workflow follows the exact recorded sequence of steps with the same outcomes.
+- **Avoid Repeating Work**:  If a [node](./low_level.md#nodes) contains multiple operations with side effects (e.g., logging, file writes, or network calls), wrap each operation in a separate **task**. This ensures that when the workflow is resumed, the operations are not repeated, and their results are retrieved from the persistence layer.
+- **Encapsulate Non-Deterministic Operations:**  Wrap any code that might yield non-deterministic results (e.g., random number generation) inside **tasks** or **nodes**. This ensures that, upon resumption, the workflow follows the exact recorded sequence of steps with the same outcomes.
 - **Use Idempotent Operations**: When possible ensure that side effects (e.g., API calls, file writes) are idempotent. This means that if an operation is retried after a failure in the workflow, it will have the same effect as the first time it was executed. This is particularly important for operations that result in data writes. In the event that a **task** starts but fails to complete successfully, the workflow's resumption will re-run the **task**, relying on recorded outcomes to maintain consistency. Use idempotency keys or verify existing results to avoid unintended duplication, ensuring a smooth and predictable workflow execution.
 
-:::python
 For some examples of pitfalls to avoid, see the [Common Pitfalls](./functional_api.md#common-pitfalls) section in the functional API, which shows
 how to structure your code using **tasks** to avoid these issues. The same principles apply to the [StateGraph (Graph API)][langgraph.graph.state.StateGraph].
-:::
-
-:::js
-For some examples of pitfalls to avoid, see the [Common Pitfalls](./functional_api.md#common-pitfalls) section in the functional API, which shows
-how to structure your code using **tasks** to avoid these issues. The same principles apply to the [StateGraph (Graph API)][<insert-ref>].
-:::
 
 ## Using tasks in nodes
 
 If a [node](./low_level.md#nodes) contains multiple operations, you may find it easier to convert each operation into a **task** rather than refactor the operations into individual nodes.
 
-:::python
 === "Original"
 
     ```python
@@ -155,136 +142,16 @@ If a [node](./low_level.md#nodes) contains multiple operations, you may find it
     graph.invoke({"urls": ["https://www.example.com"]}, config)
     ```
 
-:::
-
-:::js
-=== "Original"
-
-    ```typescript
-    import { StateGraph, START, END } from "@langchain/langgraph";
-    import { MemorySaver } from "@langchain/langgraph";
-    import { v4 as uuidv4 } from "uuid";
-    import { z } from "zod";
-
-    // Define a Zod schema to represent the state
-    const State = z.object({
-      url: z.string(),
-      result: z.string().optional(),
-    });
-
-    const callApi = async (state: z.infer<typeof State>) => {
-      // highlight-next-line
-      const response = await fetch(state.url);
-      const text = await response.text();
-      const result = text.slice(0, 100); // Side-effect
-      return {
-        result,
-      };
-    };
-
-    // Create a StateGraph builder and add a node for the callApi function
-    const builder = new StateGraph(State)
-      .addNode("callApi", callApi)
-      .addEdge(START, "callApi")
-      .addEdge("callApi", END);
-
-    // Specify a checkpointer
-    const checkpointer = new MemorySaver();
-
-    // Compile the graph with the checkpointer
-    const graph = builder.compile({ checkpointer });
-
-    // Define a config with a thread ID.
-    const threadId = uuidv4();
-    const config = { configurable: { thread_id: threadId } };
-
-    // Invoke the graph
-    await graph.invoke({ url: "https://www.example.com" }, config);
-    ```
-
-=== "With task"
-
-    ```typescript
-    import { StateGraph, START, END } from "@langchain/langgraph";
-    import { MemorySaver } from "@langchain/langgraph";
-    import { task } from "@langchain/langgraph";
-    import { v4 as uuidv4 } from "uuid";
-    import { z } from "zod";
-
-    // Define a Zod schema to represent the state
-    const State = z.object({
-      urls: z.array(z.string()),
-      results: z.array(z.string()).optional(),
-    });
-
-    const makeRequest = task("makeRequest", async (url: string) => {
-      // highlight-next-line
-      const response = await fetch(url);
-      const text = await response.text();
-      return text.slice(0, 100);
-    });
-
-    const callApi = async (state: z.infer<typeof State>) => {
-      // highlight-next-line
-      const requests = state.urls.map((url) => makeRequest(url));
-      const results = await Promise.all(requests);
-      return {
-        results,
-      };
-    };
-
-    // Create a StateGraph builder and add a node for the callApi function
-    const builder = new StateGraph(State)
-      .addNode("callApi", callApi)
-      .addEdge(START, "callApi")
-      .addEdge("callApi", END);
-
-    // Specify a checkpointer
-    const checkpointer = new MemorySaver();
-
-    // Compile the graph with the checkpointer
-    const graph = builder.compile({ checkpointer });
-
-    // Define a config with a thread ID.
-    const threadId = uuidv4();
-    const config = { configurable: { thread_id: threadId } };
-
-    // Invoke the graph
-    await graph.invoke({ urls: ["https://www.example.com"] }, config);
-    ```
-
-:::
-
 ## Resuming Workflows
 
 Once you have enabled durable execution in your workflow, you can resume execution for the following scenarios:
 
-:::python
-
 - **Pausing and Resuming Workflows:** Use the [interrupt][langgraph.types.interrupt] function to pause a workflow at specific points and the [Command][langgraph.types.Command] primitive to resume it with updated state. See [**Human-in-the-Loop**](./human_in_the_loop.md) for more details.
 - **Recovering from Failures:** Automatically resume workflows from the last successful checkpoint after an exception (e.g., LLM provider outage). This involves executing the workflow with the same thread identifier by providing it with a `None` as the input value (see this [example](../how-tos/use-functional-api.md#resuming-after-an-error) with the functional API).
-  :::
-
-:::js
-
-- **Pausing and Resuming Workflows:** Use the [interrupt](insert-ref) function to pause a workflow at specific points and the [Command](insert-ref) primitive to resume it with updated state. See [**Human-in-the-Loop**](./human_in_the_loop.md) for more details.
-- **Recovering from Failures:** Automatically resume workflows from the last successful checkpoint after an exception (e.g., LLM provider outage). This involves executing the workflow with the same thread identifier by providing it with a `null` as the input value (see this [example](../how-tos/use-functional-api.md#resuming-after-an-error) with the functional API).
-  :::
 
 ## Starting Points for Resuming Workflows
 
-:::python
-
-- If you're using a [StateGraph (Graph API)][langgraph.graph.state.StateGraph], the starting point is the beginning of the [**node**](./low_level.md#nodes) where execution stopped.
-- If you're making a subgraph call inside a node, the starting point will be the **parent** node that called the subgraph that was halted.
-  Inside the subgraph, the starting point will be the specific [**node**](./low_level.md#nodes) where execution stopped.
-- If you're using the Functional API, the starting point is the beginning of the [**entrypoint**](./functional_api.md#entrypoint) where execution stopped.
-  :::
-
-:::js
-
-- If you're using a [StateGraph (Graph API)](./low_level.md), the starting point is the beginning of the [**node**](./low_level.md#nodes) where execution stopped.
-- If you're making a subgraph call inside a node, the starting point will be the **parent** node that called the subgraph that was halted.
-  Inside the subgraph, the starting point will be the specific [**node**](./low_level.md#nodes) where execution stopped.
-- If you're using the Functional API, the starting point is the beginning of the [**entrypoint**](./functional_api.md#entrypoint) where execution stopped.
-  :::
+* If you're using a [StateGraph (Graph API)][langgraph.graph.state.StateGraph], the starting point is the beginning of the [**node**](./low_level.md#nodes) where execution stopped. 
+* If you're making a subgraph call inside a node, the starting point will be the **parent** node that called the subgraph that was halted.
+Inside the subgraph, the starting point will be the specific [**node**](./low_level.md#nodes) where execution stopped.
+* If you're using the Functional API, the starting point is the beginning of the [**entrypoint**](./functional_api.md#entrypoint) where execution stopped.

docs/docs/concepts/faq.md

@@ -13,7 +13,7 @@ No. LangGraph is an orchestration framework for complex agentic systems and is m
 
 ## How is LangGraph different from other agent frameworks?
 
-Other agentic frameworks can work for simple, generic tasks but fall short for complex tasks. LangGraph provides a more expressive framework to handle your unique tasks without restricting you to a single black-box cognitive architecture.
+Other agentic frameworks can work for simple, generic tasks but fall short for complex tasks bespoke to a company’s needs. LangGraph provides a more expressive framework to handle companies’ unique tasks without restricting users to a single black-box cognitive architecture.
 
 ## Does LangGraph impact the performance of my app?
 
@@ -28,14 +28,14 @@ Yes. LangGraph is an MIT-licensed open-source library and is free to use.
 LangGraph is a stateful, orchestration framework that brings added control to agent workflows. LangGraph Platform is a service for deploying and scaling LangGraph applications, with an opinionated API for building agent UXs, plus an integrated developer studio.
 
 | Features            | LangGraph (open source)                                   | LangGraph Platform                                                                                     |
-| ------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
+|---------------------|-----------------------------------------------------------|--------------------------------------------------------------------------------------------------------|
 | Description         | Stateful orchestration framework for agentic applications | Scalable infrastructure for deploying LangGraph applications                                           |
 | SDKs                | Python and JavaScript                                     | Python and JavaScript                                                                                  |
 | HTTP APIs           | None                                                      | Yes - useful for retrieving & updating state or long-term memory, or creating a configurable assistant |
 | Streaming           | Basic                                                     | Dedicated mode for token-by-token messages                                                             |
 | Checkpointer        | Community contributed                                     | Supported out-of-the-box                                                                               |
 | Persistence Layer   | Self-managed                                              | Managed Postgres with efficient storage                                                                |
-| Deployment          | Self-managed                                              | • Cloud SaaS <br> • Free self-hosted <br> • Enterprise (paid self-hosted)                              |
+| Deployment          | Self-managed                                              | • Cloud SaaS <br> • Free self-hosted <br> • Enterprise (paid self-hosted)                      |
 | Scalability         | Self-managed                                              | Auto-scaling of task queues and servers                                                                |
 | Fault-tolerance     | Self-managed                                              | Automated retries                                                                                      |
 | Concurrency Control | Simple threading                                          | Supports double-texting                                                                                |
@@ -47,7 +47,7 @@ LangGraph is a stateful, orchestration framework that brings added control to ag
 
 No. LangGraph Platform is proprietary software.
 
-There is a free, self-hosted version of LangGraph Platform with access to basic features. The Self-Hosted deployment options are paid services. [Contact our sales team](https://www.langchain.com/contact-sales) to learn more.
+There is a free, self-hosted version of LangGraph Platform with access to basic features. The Cloud SaaS deployment option is free while in beta, but will eventually be a paid service. We will always give ample notice before charging for a service and reward our early adopters with preferential pricing. The Self-Hosted deployment options are paid services. [Contact our sales team](https://www.langchain.com/contact-sales) to learn more.
 
 For more information, see our [LangGraph Platform pricing page](https://www.langchain.com/pricing-langgraph-platform).
 
@@ -59,12 +59,8 @@ Yes! You can use LangGraph with any LLMs. The main reason we use LLMs that suppo
 
 Yes! LangGraph is totally ambivalent to what LLMs are used under the hood. The main reason we use closed LLMs in most of the tutorials is that they seamlessly support tool calling, while OSS LLMs often don't. But tool calling is not necessary (see [this section](#does-langgraph-work-with-llms-that-dont-support-tool-calling)) so you can totally use LangGraph with OSS LLMs.
 
-## Can I use LangGraph Studio without logging in to LangSmith
+## Can I use LangGraph Studio without logging to LangSmith
 
 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,27 +7,18 @@ 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.
+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.  
 
-The Functional API uses two key building blocks:
+The Functional API uses two key building blocks:  
 
-:::python
-
-- **`@entrypoint`** – Marks a function as the starting point of a workflow, encapsulating logic and managing execution flow, including handling long-running tasks and interrupts.
+- **`@entrypoint`** – Marks a function as the starting point of a workflow, encapsulating logic and managing execution flow, including handling long-running tasks and interrupts.  
 - **`@task`** – Represents a discrete unit of work, such as an API call or data processing step, that can be executed asynchronously within an entrypoint. Tasks return a future-like object that can be awaited or resolved synchronously.  
-  :::
-
-:::js
-
-- **`entrypoint`** – An entrypoint encapsulates workflow logic and manages execution flow, including handling long-running tasks and interrupts.
-- **`task`** – Represents a discrete unit of work, such as an API call or data processing step, that can be executed asynchronously within an entrypoint. Tasks return a future-like object that can be awaited or resolved synchronously.  
-  :::
 
 This provides a minimal abstraction for building workflows with state management and streaming.
 
-!!! tip
+!!! 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.
@@ -36,13 +27,12 @@ This provides a minimal abstraction for building workflows with state management
 
 Below we demonstrate a simple application that writes an essay and [interrupts](human_in_the_loop.md) to request human review.
 
-:::python
-
 ```python
 from langgraph.checkpoint.memory import MemorySaver
 from langgraph.func import entrypoint, task
 from langgraph.types import interrupt
 
+
 @task
 def write_essay(topic: str) -> str:
     """Write an essay about the given topic."""
@@ -69,50 +59,12 @@ def workflow(topic: str) -> dict:
     }
 ```
 
-:::
-
-:::js
-
-```typescript
-import { MemorySaver, entrypoint, task, interrupt } from "@langchain/langgraph";
-
-const writeEssay = task("writeEssay", async (topic: string) => {
-  // A placeholder for a long-running task.
-  await new Promise((resolve) => setTimeout(resolve, 1000));
-  return `An essay about topic: ${topic}`;
-});
-
-const workflow = entrypoint(
-  { checkpointer: new MemorySaver(), name: "workflow" },
-  async (topic: string) => {
-    const essay = await writeEssay(topic);
-    const isApproved = interrupt({
-      // Any json-serializable payload provided to interrupt as argument.
-      // It will be surfaced on the client side as an Interrupt when streaming data
-      // from the workflow.
-      essay, // The essay we want reviewed.
-      // We can add any additional information that we need.
-      // For example, introduce a key called "action" with some instructions.
-      action: "Please approve/reject the essay",
-    });
-
-    return {
-      essay, // The essay that was generated
-      isApproved, // Response from HIL
-    };
-  }
-);
-```
-
-:::
-
 ??? example "Detailed Explanation"
 
     This workflow will write an essay about the topic "cat" and then pause to get a review from a human. The workflow can be interrupted for an indefinite amount of time until a review is provided.
 
-    When the workflow is resumed, it executes from the very start, but because the result of the `writeEssay` task was already saved, the task result will be loaded from the checkpoint instead of being recomputed.
+    When the workflow is resumed, it executes from the very start, but because the result of the `write_essay` task was already saved, the task result will be loaded from the checkpoint instead of being recomputed.
 
-    :::python
     ```python
     import time
     import uuid
@@ -181,100 +133,14 @@ const workflow = entrypoint(
     ```
 
     The workflow has been completed and the review has been added to the essay.
-    :::
-
-    :::js
-    ```typescript
-    import { v4 as uuidv4 } from "uuid";
-    import { MemorySaver, entrypoint, task, interrupt } from "@langchain/langgraph";
-
-    const writeEssay = task("writeEssay", async (topic: string) => {
-      // This is a placeholder for a long-running task.
-      await new Promise(resolve => setTimeout(resolve, 1000));
-      return `An essay about topic: ${topic}`;
-    });
-
-    const workflow = entrypoint(
-      { checkpointer: new MemorySaver(), name: "workflow" },
-      async (topic: string) => {
-        const essay = await writeEssay(topic);
-        const isApproved = interrupt({
-          // Any json-serializable payload provided to interrupt as argument.
-          // It will be surfaced on the client side as an Interrupt when streaming data
-          // from the workflow.
-          essay, // The essay we want reviewed.
-          // We can add any additional information that we need.
-          // For example, introduce a key called "action" with some instructions.
-          action: "Please approve/reject the essay",
-        });
-
-        return {
-          essay, // The essay that was generated
-          isApproved, // Response from HIL
-        };
-      }
-    );
-
-    const threadId = uuidv4();
-
-    const config = {
-      configurable: {
-        thread_id: threadId
-      }
-    };
-
-    for await (const item of workflow.stream("cat", config)) {
-      console.log(item);
-    }
-    ```
-
-    ```console
-    { writeEssay: 'An essay about topic: cat' }
-    {
-      __interrupt__: [{
-        value: { essay: 'An essay about topic: cat', action: 'Please approve/reject the essay' },
-        resumable: true,
-        ns: ['workflow:f7b8508b-21c0-8b4c-5958-4e8de74d2684'],
-        when: 'during'
-      }]
-    }
-    ```
-
-    An essay has been written and is ready for review. Once the review is provided, we can resume the workflow:
-
-    ```typescript
-    import { Command } from "@langchain/langgraph";
-
-    // Get review from a user (e.g., via a UI)
-    // In this case, we're using a bool, but this can be any json-serializable value.
-    const humanReview = true;
-
-    for await (const item of workflow.stream(new Command({ resume: humanReview }), config)) {
-      console.log(item);
-    }
-    ```
-
-    ```console
-    { workflow: { essay: 'An essay about topic: cat', isApproved: true } }
-    ```
-
-    The workflow has been completed and the review has been added to the essay.
-    :::
 
 ## Entrypoint
 
-:::python
-The [`@entrypoint`][langgraph.func.entrypoint] decorator can be used to create a workflow from a function. It encapsulates workflow logic and manages execution flow, including handling _long-running tasks_ and [interrupts](./human_in_the_loop.md).
-:::
-
-:::js
-The [`entrypoint`][<insert-ref>] function can be used to create a workflow from a function. It encapsulates workflow logic and manages execution flow, including handling _long-running tasks_ and [interrupts](./human_in_the_loop.md).
-:::
+The [`@entrypoint`][langgraph.func.entrypoint] decorator can be used to create a workflow from a function. It encapsulates workflow logic and manages execution flow, including handling *long-running tasks* and [interrupts](./human_in_the_loop.md).
 
 ### Definition
 
-:::python
-An **entrypoint** is defined by decorating a function with the `@entrypoint` decorator.
+An **entrypoint** is defined by decorating a function with the `@entrypoint` decorator. 
 
 The function **must accept a single positional argument**, which serves as the workflow input. If you need to pass multiple pieces of data, use a dictionary as the input type for the first argument.
 
@@ -305,60 +171,25 @@ You will usually want to pass a **checkpointer** to the `@entrypoint` decorator
         # some logic that may involve long-running tasks like API calls,
         # and may be interrupted for human-in-the-loop
         ...
-        return result
+        return result 
     ```
 
-:::
-
-:::js
-An **entrypoint** is defined by calling the `entrypoint` function with configuration and a function.
-
-The function **must accept a single positional argument**, which serves as the workflow input. If you need to pass multiple pieces of data, use an object as the input type for the first argument.
-
-Creating an entrypoint with a function produces a workflow instance which helps to manage the execution of the workflow (e.g., handles streaming, resumption, and checkpointing).
-
-You will often want to pass a **checkpointer** to the `entrypoint` function to enable persistence and use features like **human-in-the-loop**.
-
-```typescript
-import { entrypoint } from "@langchain/langgraph";
-
-const myWorkflow = entrypoint(
-  { checkpointer, name: "workflow" },
-  async (someInput: Record<string, any>): Promise<number> => {
-    // some logic that may involve long-running tasks like API calls,
-    // and may be interrupted for human-in-the-loop
-    return result;
-  }
-);
-```
-
-:::
-
 !!! important "Serialization"
 
     The **inputs** and **outputs** of entrypoints must be JSON-serializable to support checkpointing. Please see the [serialization](#serialization) section for more details.
 
+
 ### Injectable parameters
 
-When declaring an `entrypoint`, you can request access to additional parameters that will be injected automatically at run time by using the [`getPreviousState()`](<insert-ref https://langchain-ai.github.io/langgraphjs/reference/functions/langgraph.getPreviousState.html>) function. These parameters include:
+When declaring an `entrypoint`, you can request access to additional parameters that will be injected automatically at run time. These parameters include:
 
-:::python
-| Parameter | Description |
+
+| Parameter    | Description                                                                                                                                                        |
 |--------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| **previous** | Access the state associated with the previous `checkpoint` for the given thread. See [short-term-memory](#short-term-memory). |
-| **store** | An instance of [BaseStore][langgraph.store.base.BaseStore]. Useful for [long-term memory](../how-tos/use-functional-api.md#long-term-memory). |
-| **writer** | Use to access the StreamWriter when working with Async Python < 3.11. See [streaming with functional API for details](../how-tos/use-functional-api.md#streaming). |
-| **config** | For accessing run time configuration. See [RunnableConfig](https://python.langchain.com/docs/concepts/runnables/#runnableconfig) for information. |
-:::
-
-:::js
-| Parameter | Description |
-| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **config** | For accessing runtime configuration. Automatically populated as the second argument to the `entrypoint` function (but not `task`, since tasks can have a variable number of arguments). See [RunnableConfig](https://js.langchain.com/docs/concepts/runnables/#runnableconfig) for information. |
-| **config.store** | An instance of [BaseStore](/langgraphjs/reference/classes/checkpoint.BaseStore.html). Useful for [long-term memory](#long-term-memory). |
-| **config.writer** | A `writer` used for streaming back custom data. See the [guide on streaming custom data](../how-tos/streaming-content.ipynb) |
-| **getPreviousState()** | Access the state associated with the previous `checkpoint` for the given thread using [`getPreviousState`](/langgraphjs/reference/functions/langgraph.getPreviousState.html). See [state management](#state-management). |
-:::
+| **previous** | Access the the state associated with the previous `checkpoint` for the given thread. See [short-term-memory](#short-term-memory).                                  |
+| **store**    | An instance of [BaseStore][langgraph.store.base.BaseStore]. Useful for [long-term memory](../how-tos/use-functional-api.md#long-term-memory).                      |
+| **writer**   | Use to access the StreamWriter when working with Async Python < 3.11. See [streaming with functional API for details](../how-tos/use-functional-api.md#streaming). |
+| **config**   | For accessing run time configuration. See [RunnableConfig](https://python.langchain.com/docs/concepts/runnables/#runnableconfig) for information.                  |
 
 !!! important
 
@@ -366,7 +197,6 @@ When declaring an `entrypoint`, you can request access to additional parameters
 
 ??? example "Requesting Injectable Parameters"
 
-    :::python
     ```python
     from langchain_core.runnables import RunnableConfig
     from langgraph.func import entrypoint
@@ -378,7 +208,7 @@ When declaring an `entrypoint`, you can request access to additional parameters
     @entrypoint(
         checkpointer=checkpointer,  # Specify the checkpointer
         store=in_memory_store  # Specify the store
-    )
+    )  
     def my_workflow(
         some_input: dict,  # The input (e.g., passed via `invoke`)
         *,
@@ -388,31 +218,9 @@ When declaring an `entrypoint`, you can request access to additional parameters
         config: RunnableConfig  # For accessing the configuration passed to the entrypoint
     ) -> ...:
     ```
-    :::
-
-    :::js
-    ```typescript
-    import { entrypoint, BaseStore, InMemoryStore, LangGraphRunnableConfig } from "@langchain/langgraph";
-
-    const inMemoryStore = new InMemoryStore(); // An instance of InMemoryStore for long-term memory
-
-    const myWorkflow = entrypoint(
-      {
-        checkpointer, name: "workflow",  // Specify the checkpointer
-        store: inMemoryStore,        // Specify the store
-        name: "myWorkflow",
-      },
-      async (someInput: Record<string, any>) => {
-        const previous = getPreviousState<any>(); // For short-term memory
-        // Rest of workflow logic...
-      }
-    );
-    ```
-    :::
 
 ### Executing
 
-:::python
 Using the [`@entrypoint`](#entrypoint) yields a [`Pregel`][langgraph.pregel.Pregel.stream] object that can be executed using the `invoke`, `ainvoke`, `stream`, and `astream` methods.
 
 === "Invoke"
@@ -438,7 +246,7 @@ Using the [`@entrypoint`](#entrypoint) yields a [`Pregel`][langgraph.pregel.Preg
     ```
 
 === "Stream"
-
+    
     ```python
     config = {
         "configurable": {
@@ -463,41 +271,8 @@ Using the [`@entrypoint`](#entrypoint) yields a [`Pregel`][langgraph.pregel.Preg
         print(chunk)
     ```
 
-:::
-
-:::js
-Using the [`entrypoint`](#entrypoint) function will return an object that can be executed using the `invoke` and `stream` methods.
-
-=== "Invoke"
-
-    ```typescript
-    const config = {
-      configurable: {
-        thread_id: "some_thread_id"
-      }
-    };
-    await myWorkflow.invoke(someInput, config); // Wait for the result
-    ```
-
-=== "Stream"
-
-    ```typescript
-    const config = {
-      configurable: {
-        thread_id: "some_thread_id"
-      }
-    };
-
-    for await (const chunk of myWorkflow.stream(someInput, config)) {
-      console.log(chunk);
-    }
-    ```
-
-:::
-
 ### Resuming
 
-:::python
 Resuming an execution after an [interrupt][langgraph.types.interrupt] can be done by passing a **resume** value to the [Command][langgraph.types.Command] primitive.
 
 === "Invoke"
@@ -510,7 +285,7 @@ Resuming an execution after an [interrupt][langgraph.types.interrupt] can be don
             "thread_id": "some_thread_id"
         }
     }
-
+    
     my_workflow.invoke(Command(resume=some_resume_value), config)
     ```
 
@@ -524,7 +299,7 @@ Resuming an execution after an [interrupt][langgraph.types.interrupt] can be don
             "thread_id": "some_thread_id"
         }
     }
-
+    
     await my_workflow.ainvoke(Command(resume=some_resume_value), config)
     ```
 
@@ -538,7 +313,7 @@ Resuming an execution after an [interrupt][langgraph.types.interrupt] can be don
             "thread_id": "some_thread_id"
         }
     }
-
+    
     for chunk in my_workflow.stream(Command(resume=some_resume_value), config):
         print(chunk)
     ```
@@ -558,57 +333,13 @@ Resuming an execution after an [interrupt][langgraph.types.interrupt] can be don
         print(chunk)
     ```
 
-:::
-
-:::js
-Resuming an execution after an [`interrupt`](insert-ref) can be done by passing a **resume** value to the [`Command`](insert-ref) primitive.
-
-=== "Invoke"
-
-    ```typescript
-    import { Command } from "@langchain/langgraph";
-
-    const config = {
-      configurable: {
-        thread_id: "some_thread_id"
-      }
-    };
-
-    await myWorkflow.invoke(new Command({ resume: someResumeValue }), config);
-    ```
-
-=== "Stream"
-
-    ```typescript
-    import { Command } from "@langchain/langgraph";
-
-    const config = {
-      configurable: {
-        thread_id: "some_thread_id"
-      }
-    };
-
-    const stream = await myWorkflow.stream(
-      new Command({ resume: someResumableValue }),
-      config,
-    )
-
-    for await (const chunk of stream) {
-      console.log(chunk);
-    }
-    ```
-
-:::
-
-:::python
-
 **Resuming after an error**
 
+
 To resume after an error, run the `entrypoint` with a `None` and the same **thread id** (config).
 
 This assumes that the underlying **error** has been resolved and execution can proceed successfully.
 
-:::python
 === "Invoke"
 
     ```python
@@ -618,7 +349,7 @@ This assumes that the underlying **error** has been resolved and execution can p
             "thread_id": "some_thread_id"
         }
     }
-
+    
     my_workflow.invoke(None, config)
     ```
 
@@ -631,7 +362,7 @@ This assumes that the underlying **error** has been resolved and execution can p
             "thread_id": "some_thread_id"
         }
     }
-
+    
     await my_workflow.ainvoke(None, config)
     ```
 
@@ -644,7 +375,7 @@ This assumes that the underlying **error** has been resolved and execution can p
             "thread_id": "some_thread_id"
         }
     }
-
+    
     for chunk in my_workflow.stream(None, config):
         print(chunk)
     ```
@@ -663,49 +394,10 @@ This assumes that the underlying **error** has been resolved and execution can p
         print(chunk)
     ```
 
-:::
-
-:::js
-
-**Resuming after an error**
-
-To resume after an error, run the `entrypoint` with `null` and the same **thread id** (config).
-
-This assumes that the underlying **error** has been resolved and execution can proceed successfully.
-
-=== "Invoke"
-
-    ```typescript
-    const config = {
-      configurable: {
-        thread_id: "some_thread_id"
-      }
-    };
-
-    await myWorkflow.invoke(null, config);
-    ```
-
-=== "Stream"
-
-    ```typescript
-    const config = {
-      configurable: {
-        thread_id: "some_thread_id"
-      }
-    };
-
-    for await (const chunk of myWorkflow.stream(null, config)) {
-      console.log(chunk);
-    }
-    ```
-
-:::
-
 ### Short-term memory
 
-When an `entrypoint` is defined with a `checkpointer`, it stores information between successive invocations on the same **thread id** in [checkpoints](persistence.md#checkpoints).
+When an `entrypoint` is defined with a `checkpointer`, it stores information between successive invocations on the same **thread id** in [checkpoints](persistence.md#checkpoints). 
 
-:::python
 This allows accessing the state from the previous invocation using the `previous` parameter.
 
 By default, the `previous` parameter is the return value of the previous invocation.
@@ -726,40 +418,9 @@ my_workflow.invoke(1, config)  # 1 (previous was None)
 my_workflow.invoke(2, config)  # 3 (previous was 1 from the previous invocation)
 ```
 
-:::
-
-:::js
-This allows accessing the state from the previous invocation using the `getPreviousState` function.
-
-By default, the `getPreviousState` function returns the return value of the previous invocation.
-
-```typescript
-import { entrypoint, getPreviousState } from "@langchain/langgraph";
-
-const myWorkflow = entrypoint(
-  { checkpointer, name: "workflow" },
-  async (number: number) => {
-    const previous = getPreviousState<number>() ?? 0;
-    return number + previous;
-  }
-);
-
-const config = {
-  configurable: {
-    thread_id: "some_thread_id",
-  },
-};
-
-await myWorkflow.invoke(1, config); // 1 (previous was undefined)
-await myWorkflow.invoke(2, config); // 3 (previous was 1 from the previous invocation)
-```
-
-:::
-
 #### `entrypoint.final`
 
-:::python
-[`entrypoint.final`][langgraph.func.entrypoint.final] is a special primitive that can be returned from an entrypoint and allows **decoupling** the value that is **saved in the checkpoint** from the **return value of the entrypoint**.
+[entrypoint.final][langgraph.func.entrypoint.final] is a special primitive that can be returned from an entrypoint and allows **decoupling** the value that is **saved in the checkpoint** from the **return value of the entrypoint**.
 
 The first value is the return value of the entrypoint, and the second value is the value that will be saved in the checkpoint. The type annotation is `entrypoint.final[return_type, save_type]`.
 
@@ -768,7 +429,7 @@ The first value is the return value of the entrypoint, and the second value is t
 def my_workflow(number: int, *, previous: Any = None) -> entrypoint.final[int, int]:
     previous = previous or 0
     # This will return the previous value to the caller, saving
-    # 2 * number to the checkpoint, which will be used in the next invocation
+    # 2 * number to the checkpoint, which will be used in the next invocation 
     # for the `previous` parameter.
     return entrypoint.final(value=previous, save=2 * number)
 
@@ -782,52 +443,15 @@ my_workflow.invoke(3, config)  # 0 (previous was None)
 my_workflow.invoke(1, config)  # 6 (previous was 3 * 2 from the previous invocation)
 ```
 
-:::
-
-:::js
-[`entrypoint.final`](insert-ref) is a special primitive that can be returned from an entrypoint and allows **decoupling** the value that is **saved in the checkpoint** from the **return value of the entrypoint**.
-
-The first value is the return value of the entrypoint, and the second value is the value that will be saved in the checkpoint.
-
-```typescript
-import { entrypoint, getPreviousState } from "@langchain/langgraph";
-
-const myWorkflow = entrypoint(
-  { checkpointer, name: "workflow" },
-  async (number: number) => {
-    const previous = getPreviousState<number>() ?? 0;
-    // This will return the previous value to the caller, saving
-    // 2 * number to the checkpoint, which will be used in the next invocation
-    // for the `previous` parameter.
-    return entrypoint.final({
-      value: previous,
-      save: 2 * number,
-    });
-  }
-);
-
-const config = {
-  configurable: {
-    thread_id: "1",
-  },
-};
-
-await myWorkflow.invoke(3, config); // 0 (previous was undefined)
-await myWorkflow.invoke(1, config); // 6 (previous was 3 * 2 from the previous invocation)
-```
-
-:::
-
 ## Task
 
 A **task** represents a discrete unit of work, such as an API call or data processing step. It has two key characteristics:
 
-- **Asynchronous Execution**: Tasks are designed to be executed asynchronously, allowing multiple operations to run concurrently without blocking.
-- **Checkpointing**: Task results are saved to a checkpoint, enabling resumption of the workflow from the last saved state. (See [persistence](persistence.md) for more details).
+* **Asynchronous Execution**: Tasks are designed to be executed asynchronously, allowing multiple operations to run concurrently without blocking.
+* **Checkpointing**: Task results are saved to a checkpoint, enabling resumption of the workflow from the last saved state. (See [persistence](persistence.md) for more details).
 
 ### Definition
 
-:::python
 Tasks are defined using the `@task` decorator, which wraps a regular Python function.
 
 ```python
@@ -840,37 +464,21 @@ def slow_computation(input_value):
     return result
 ```
 
-:::
-
-:::js
-Tasks are defined using the `task` function, which wraps a regular function.
-
-```typescript
-import { task } from "@langchain/langgraph";
-
-const slowComputation = task("slowComputation", async (inputValue: any) => {
-  // Simulate a long-running operation
-  return result;
-});
-```
-
-:::
-
 !!! important "Serialization"
 
     The **outputs** of tasks must be JSON-serializable to support checkpointing.
 
 ### Execution
 
-**Tasks** can only be called from within an **entrypoint**, another **task**, or a [state graph node](./low_level.md#nodes).
+**Tasks** can only be called from within an **entrypoint**, another **task**, or a [state graph node](./low_level.md#nodes). 
 
-Tasks _cannot_ be called directly from the main application code.
+Tasks *cannot* be called directly from the main application code. 
 
-:::python
-When you call a **task**, it returns _immediately_ with a future object. A future is a placeholder for a result that will be available later.
+When you call a **task**, it returns *immediately* with a future object. A future is a placeholder for a result that will be available later.
 
 To obtain the result of a **task**, you can either wait for it synchronously (using `result()`) or await it asynchronously (using `await`).
 
+
 === "Synchronous Invocation"
 
     ```python
@@ -888,22 +496,6 @@ To obtain the result of a **task**, you can either wait for it synchronously (us
         return await slow_computation(some_input)  # Await result asynchronously
     ```
 
-:::
-
-:::js
-When you call a **task**, it returns a Promise that can be awaited.
-
-```typescript
-const myWorkflow = entrypoint(
-  { checkpointer, name: "workflow" },
-  async (someInput: number): Promise<number> => {
-    return await slowComputation(someInput);
-  }
-);
-```
-
-:::
-
 ## When to use a task
 
 **Tasks** are useful in the following scenarios:
@@ -913,21 +505,16 @@ const myWorkflow = entrypoint(
 - **Parallel Execution**: For I/O-bound tasks, **tasks** enable parallel execution, allowing multiple operations to run concurrently without blocking (e.g., calling multiple APIs).
 - **Observability**: Wrapping operations in **tasks** provides a way to track the progress of the workflow and monitor the execution of individual operations using [LangSmith](https://docs.smith.langchain.com/).
 - **Retryable Work**: When work needs to be retried to handle failures or inconsistencies, **tasks** provide a way to encapsulate and manage the retry logic.
-
+ 
 ## Serialization
 
 There are two key aspects to serialization in LangGraph:
 
-1. `entrypoint` inputs and outputs must be JSON-serializable.
-2. `task` outputs must be JSON-serializable.
+1. `@entrypoint` inputs and outputs must be JSON-serializable.
+2. `@task` outputs must be JSON-serializable.
 
-:::python
-These requirements are necessary for enabling checkpointing and workflow resumption. Use python primitives like dictionaries, lists, strings, numbers, and booleans to ensure that your inputs and outputs are serializable.
-:::
-
-:::js
-These requirements are necessary for enabling checkpointing and workflow resumption. Use primitives like objects, arrays, strings, numbers, and booleans to ensure that your inputs and outputs are serializable.
-:::
+These requirements are necessary for enabling checkpointing and workflow resumption. Use python primitives
+like dictionaries, lists, strings, numbers, and booleans to ensure that your inputs and outputs are serializable.
 
 Serialization ensures that workflow state, such as task results and intermediate values, can be reliably saved and restored. This is critical for enabling human-in-the-loop interactions, fault tolerance, and parallel execution.
 
@@ -935,9 +522,9 @@ Providing non-serializable inputs or outputs will result in a runtime error when
 
 ## Determinism
 
-To utilize features like **human-in-the-loop**, any randomness should be encapsulated inside of **tasks**. This guarantees that when execution is halted (e.g., for human in the loop) and then resumed, it will follow the same _sequence of steps_, even if **task** results are non-deterministic.
+To utilize features like **human-in-the-loop**, any randomness should be encapsulated inside of **tasks**. This guarantees that when execution is halted (e.g., for human in the loop) and then resumed, it will follow the same *sequence of steps*, even if **task** results are non-deterministic.
 
-LangGraph achieves this behavior by persisting **task** and [**subgraph**](./subgraphs.md) results as they execute. A well-designed workflow ensures that resuming execution follows the _same sequence of steps_, allowing previously computed results to be retrieved correctly without having to re-execute them. This is particularly useful for long-running **tasks** or **tasks** with non-deterministic results, as it avoids repeating previously done work and allows resuming from essentially the same.
+LangGraph achieves this behavior by persisting **task** and [**subgraph**](./subgraphs.md) results as they execute. A well-designed workflow ensures that resuming execution follows the *same sequence of steps*, allowing previously computed results to be retrieved correctly without having to re-execute them. This is particularly useful for long-running **tasks** or **tasks** with non-deterministic results, as it avoids repeating previously done work and allows resuming from essentially the same.
 
 While different runs of a workflow can produce different results, resuming a **specific** run should always follow the same sequence of recorded steps. This allows LangGraph to efficiently look up **task** and **subgraph** results that were executed prior to the graph being interrupted and avoid recomputing them.
 
@@ -949,21 +536,10 @@ Idempotency ensures that running the same operation multiple times produces the
 
 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:
 
-:::python
-
 - **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 **Graph API** 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.
+- **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.
-  :::
-
-:::js
-
-- **Control flow**: The Functional API does not require thinking about graph structure. You can use standard TypeScript constructs to define workflows. This will usually trim the amount of code you need to write.
-- **Short-term memory**: The **Graph API** 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 `task` 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
 
@@ -975,7 +551,6 @@ Encapsulate side effects (e.g., writing to a file, sending an email) in tasks to
 
     In this example, a side effect (writing to a file) is directly included in the workflow, so it will be executed a second time when resuming the workflow.
 
-    :::python
     ```python
     @entrypoint(checkpointer=checkpointer)
     def my_workflow(inputs: dict) -> int:
@@ -988,31 +563,11 @@ Encapsulate side effects (e.g., writing to a file, sending an email) in tasks to
         value = interrupt("question")
         return value
     ```
-    :::
-
-    :::js
-    ```typescript
-    import { entrypoint, interrupt } from "@langchain/langgraph";
-    import fs from "fs";
-
-    const myWorkflow = entrypoint(
-      { checkpointer, name: "workflow },
-      async (inputs: Record<string, any>) => {
-        // This code will be executed a second time when resuming the workflow.
-        // Which is likely not what you want.
-        fs.writeFileSync("output.txt", "Side effect executed");
-        const value = interrupt("question");
-        return value;
-      }
-    );
-    ```
-    :::
 
 === "Correct"
 
     In this example, the side effect is encapsulated in a task, ensuring consistent execution upon resumption.
 
-    :::python
     ```python
     from langgraph.func import task
 
@@ -1030,43 +585,17 @@ Encapsulate side effects (e.g., writing to a file, sending an email) in tasks to
         value = interrupt("question")
         return value
     ```
-    :::
-
-    :::js
-    ```typescript
-    import { entrypoint, task, interrupt } from "@langchain/langgraph";
-    import * as fs from "fs";
-
-    const writeToFile = task("writeToFile", async () => {
-      fs.writeFileSync("output.txt", "Side effect executed");
-    });
-
-    const myWorkflow = entrypoint(
-      { checkpointer, name: "workflow" },
-      async (inputs: Record<string, any>) => {
-        // The side effect is now encapsulated in a task.
-        await writeToFile();
-        const value = interrupt("question");
-        return value;
-      }
-    );
-    ```
-    :::
 
 ### Non-deterministic control flow
 
 Operations that might give different results each time (like getting current time or random numbers) should be encapsulated in tasks to ensure that on resume, the same result is returned.
 
-- In a task: Get random number (5) → interrupt → resume → (returns 5 again) → ...
-- Not in a task: Get random number (5) → interrupt → resume → get new random number (7) → ...
+* In a task: Get random number (5) → interrupt → resume → (returns 5 again) → ...
+* Not in a task: Get random number (5) → interrupt → resume → get new random number (7) → ...
 
-:::python
-This is especially important when using **human-in-the-loop** workflows with multiple interrupts calls. LangGraph keeps a list of resume values for each task/entrypoint. When an interrupt is encountered, it's matched with the corresponding resume value. This matching is strictly **index-based**, so the order of the resume values should match the order of the interrupts.
-:::
-
-:::js
-This is especially important when using **human-in-the-loop** workflows with multiple interrupt calls. LangGraph keeps a list of resume values for each task/entrypoint. When an interrupt is encountered, it's matched with the corresponding resume value. This matching is strictly **index-based**, so the order of the resume values should match the order of the interrupts.
-:::
+This is especially important when using **human-in-the-loop** workflows with multiple interrupts calls. LangGraph keeps a list
+of resume values for each task/entrypoint. When an interrupt is encountered, it's matched with the corresponding resume value.
+This matching is strictly **index-based**, so the order of the resume values should match the order of the interrupts.
 
 If order of execution is not maintained when resuming, one `interrupt` call may be matched with the wrong `resume` value, leading to incorrect results.
 
@@ -1076,7 +605,6 @@ Please read the section on [determinism](#determinism) for more details.
 
     In this example, the workflow uses the current time to determine which task to execute. This is non-deterministic because the result of the workflow depends on the time at which it is executed.
 
-    :::python
     ```python
     from langgraph.func import entrypoint
 
@@ -1085,51 +613,24 @@ Please read the section on [determinism](#determinism) for more details.
         t0 = inputs["t0"]
         # highlight-next-line
         t1 = time.time()
-
+        
         delta_t = t1 - t0
-
+        
         if delta_t > 1:
             result = slow_task(1).result()
             value = interrupt("question")
         else:
             result = slow_task(2).result()
             value = interrupt("question")
-
+            
         return {
             "result": result,
             "value": value
         }
     ```
-    :::
-
-    :::js
-    ```typescript
-    import { entrypoint, interrupt } from "@langchain/langgraph";
-
-    const myWorkflow = entrypoint(
-      { checkpointer, name: "workflow" },
-      async (inputs: { t0: number }) => {
-        const t1 = Date.now();
-
-        const deltaT = t1 - inputs.t0;
-
-        if (deltaT > 1000) {
-          const result = await slowTask(1);
-          const value = interrupt("question");
-          return { result, value };
-        } else {
-          const result = await slowTask(2);
-          const value = interrupt("question");
-          return { result, value };
-        }
-      }
-    );
-    ```
-    :::
 
 === "Correct"
 
-    :::python
     In this example, the workflow uses the input `t0` to determine which task to execute. This is deterministic because the result of the workflow depends only on the input.
 
     ```python
@@ -1148,48 +649,19 @@ Please read the section on [determinism](#determinism) for more details.
         t0 = inputs["t0"]
         # highlight-next-line
         t1 = get_time().result()
-
+        
         delta_t = t1 - t0
-
+        
         if delta_t > 1:
             result = slow_task(1).result()
             value = interrupt("question")
         else:
             result = slow_task(2).result()
             value = interrupt("question")
-
+            
         return {
             "result": result,
             "value": value
         }
     ```
-    :::
 
-    :::js
-    In this example, the workflow uses the input `t0` to determine which task to execute. This is deterministic because the result of the workflow depends only on the input.
-
-    ```typescript
-    import { entrypoint, task, interrupt } from "@langchain/langgraph";
-
-    const getTime = task("getTime", () => Date.now());
-
-    const myWorkflow = entrypoint(
-      { checkpointer, name: "workflow" },
-      async (inputs: { t0: number }): Promise<any> => {
-        const t1 = await getTime();
-
-        const deltaT = t1 - inputs.t0;
-
-        if (deltaT > 1000) {
-          const result = await slowTask(1);
-          const value = interrupt("question");
-          return { result, value };
-        } else {
-          const result = await slowTask(2);
-          const value = interrupt("question");
-          return { result, value };
-        }
-      }
-    );
-    ```
-    :::

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

@@ -7,64 +7,24 @@ search:
 
 **LangGraph CLI** is a multi-platform command-line tool for building and running the [LangGraph API server](./langgraph_server.md) locally. The resulting server includes all API endpoints for your graph's runs, threads, assistants, etc. as well as the other services required to run your agent, including a managed database for checkpointing and storage.
 
-::: python
-
 ## 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" 
+    ```bash
     pip install langgraph-cli
-    `
-
-=== "Homebrew"
-`bash
-    brew install langgraph-cli
-    `
-:::
-
-::: js
-
-## Installation
-
-The LangGraph.js CLI can be installed from the NPM registry:
-
-=== "npx"
-`bash
-    npx @langchain/langgraph-cli
-    `
-
-=== "npm"
-`bash
-    npm install @langchain/langgraph-cli
-    `
-
-=== "yarn"
-`bash
-    yarn add @langchain/langgraph-cli
-    `
-
-=== "pnpm"
-`bash
-    pnpm add @langchain/langgraph-cli
-    `
-
-=== "bun"
-`bash
-    bun add @langchain/langgraph-cli
-    `
-:::
+    ```
 
 ## Commands
 
 LangGraph CLI provides the following core functionality:
 
-| Command                                                        | Description                                                                                                                                                                                                                                                                            |
-| -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [`langgraph build`](../cloud/reference/cli.md#build)           | Builds a Docker image for the [LangGraph API server](./langgraph_server.md) that can be directly deployed.                                                                                                                                                                             |
-| [`langgraph dev`](../cloud/reference/cli.md#dev)               | Starts a lightweight development server that requires no Docker installation. This server is ideal for rapid development and testing.                                                                                                                                                  |
+| Command | Description |
+| -------- | -------|
+| [`langgraph build`](../cloud/reference/cli.md#build) | Builds a Docker image for the [LangGraph API server](./langgraph_server.md) that can be directly deployed. |
+| [`langgraph dev`](../cloud/reference/cli.md#dev) | Starts a lightweight development server that requires no Docker installation. This server is ideal for rapid development and testing. This is available in version 0.1.55 and up.
 | [`langgraph dockerfile`](../cloud/reference/cli.md#dockerfile) | Generates a [Dockerfile](https://docs.docker.com/reference/dockerfile/) that can be used to build images for and deploy instances of the [LangGraph API server](./langgraph_server.md). This is useful if you want to further customize the dockerfile or deploy in a more custom way. |
-| [`langgraph up`](../cloud/reference/cli.md#up)                 | Starts an instance of the [LangGraph API server](./langgraph_server.md) locally in a docker container. This requires the docker server to be running locally. It also requires a LangSmith API key for local development or a license key for production use.                          |
+| [`langgraph up`](../cloud/reference/cli.md#up) | Starts an instance of the [LangGraph API server](./langgraph_server.md) locally in a docker container. This requires the docker server to be running locally. It also requires a LangSmith API key for local development or a license key for production use. | 
 
 For more information, see the [LangGraph CLI Reference](../cloud/reference/cli.md).

docs/docs/concepts/langgraph_cloud.md

@@ -11,11 +11,11 @@ To deploy a [LangGraph Server](../concepts/langgraph_server.md), follow the how-
 
 The Cloud SaaS deployment option is a fully managed model for deployment where we manage the [control plane](./langgraph_control_plane.md) and [data plane](./langgraph_data_plane.md) in our cloud.
 
-|                                    | [Control plane](../concepts/langgraph_control_plane.md)                                                                                     | [Data plane](../concepts/langgraph_data_plane.md)                                                                                                   |
-| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **What is it?**                    | <ul><li>Control plane UI for creating deployments and revisions</li><li>Control plane APIs for creating deployments and revisions</li></ul> | <ul><li>Data plane "listener" for reconciling deployments with control plane state</li><li>LangGraph Servers</li><li>Postgres, Redis, etc</li></ul> |
-| **Where is it hosted?**            | LangChain's cloud                                                                                                                           | LangChain's cloud                                                                                                                                   |
-| **Who provisions and manages it?** | LangChain                                                                                                                                   | LangChain                                                                                                                                           |
+|                   | [Control plane](../concepts/langgraph_control_plane.md) | [Data plane](../concepts/langgraph_data_plane.md) |
+|-------------------|-------------------|------------|
+| **What is it?** | <ul><li>Control plane UI for creating deployments and revisions</li><li>Control plane APIs for creating deployments and revisions</li></ul> | <ul><li>Data plane "listener" for reconciling deployments with control plane state</li><li>LangGraph Servers</li><li>Postgres, Redis, etc</li></ul> |
+| **Where is it hosted?** | LangChain's cloud | LangChain's cloud |
+| **Who provisions and manages it?** | LangChain | LangChain |
 
 ## Architecture
 

docs/docs/concepts/langgraph_components.md

@@ -10,4 +10,4 @@ The LangGraph Platform consists of components that work together to support the
 - [LangGraph control plane](./langgraph_control_plane.md): The LangGraph Control Plane refers to the Control Plane UI where users create and update LangGraph Servers and the Control Plane APIs that support the UI experience.
 - [LangGraph data plane](./langgraph_data_plane.md): The LangGraph Data Plane refers to LangGraph Servers, the corresponding infrastructure for each server, and the "listener" application that continuously polls for updates from the LangGraph Control Plane.
 
-![LangGraph components](img/lg_platform.png)
+![LangGraph components](img/lg_platform.png)

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).
@@ -49,7 +48,7 @@ This section describes various features of the control plane.
 For simplicity, the control plane offers two deployment types with different resource allocations: `Development` and `Production`.
 
 | **Deployment Type** | **CPU/Memory**  | **Scaling**         | **Database**                                                                     |
-| ------------------- | --------------- | ------------------- | -------------------------------------------------------------------------------- |
+|---------------------|-----------------|---------------------|----------------------------------------------------------------------------------|
 | Development         | 1 CPU, 1 GB RAM | Up to 1 container   | 10 GB disk, no backups                                                           |
 | Production          | 2 CPU, 2 GB RAM | Up to 10 containers | Autoscaling disk, automatic backups, highly available (multi-zone configuration) |
 
@@ -60,7 +59,7 @@ CPU and memory resources are per container.
     Once a deployment is created, the deployment type cannot be changed.
 
 !!! info "Resource Customization"
-For `Production` type deployments, resources can be manually increased on a case-by-case basis depending on use case and capacity constraints. Contact support@langchain.dev to request an increase in resources.
+    For `Production` type deployments, resources can be manually increased on a case-by-case basis depending on use case and capacity constraints. Contact support@langchain.dev to request an increase in resources.
 
     For `Development` types deployments, database disk size can be manually increased on a case-by-case basis depending on use case and capacity constraints. For most use cases, [TTLs](../how-tos/ttl/configure_ttl.md) should be configured to manage disk usage. Contact support@langchain.dev to request an increase in resources.
 
@@ -77,7 +76,7 @@ There is no direct access to the database. All access to the database occurs thr
 The database is never deleted until the deployment itself is deleted.
 
 !!! info
-A custom Postgres instance can be configured for [Self-Hosted Data Plane](../concepts/langgraph_self_hosted_data_plane.md) and [Self-Hosted Control Plane](../concepts/langgraph_self_hosted_control_plane.md) deployments.
+    A custom Postgres instance can be configured for [Self-Hosted Data Plane](../concepts/langgraph_self_hosted_data_plane.md) and [Self-Hosted Control Plane](../concepts/langgraph_self_hosted_control_plane.md) deployments.
 
 ### Asynchronous Deployment
 
@@ -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

@@ -9,7 +9,7 @@ The term "data plane" is used broadly to refer to [LangGraph Servers](./langgrap
 
 ## Server Infrastructure
 
-In addition to the [LangGraph Server](./langgraph_server.md) itself, the following infrastructure components for each server are also included in the broad definition of "data plane":
+In addition to the [LangGraph Server](./langgraph_server.md) itself, the following infrastructure for each server are also included in the broad definition of "data plane":
 
 - Postgres
 - Redis
@@ -44,7 +44,7 @@ All runs in a LangGraph Server are executed by a pool of background workers that
 
 ### Ephemeral metadata
 
-Runs in a LangGraph Server may be retried for specific failures (currently only for transient Postgres errors encountered during the run). In order to limit the number of retries (currently limited to 3 attempts per run) we record the attempt number in a Redis string when it is picked up. This contains no run-specific info other than its ID, and expires after a short delay.
+Runs in a LangGraph Server may be retried for specific failures (currently only for transient Postgres errors encountered during the run). In order to limit the number of retries (currently limited to 3 attempts per run) we record the attempt number in a Redis string when is picked up. This contains no run-specific info other than its ID, and expires after a short delay.
 
 ## Data Plane Features
 
@@ -56,38 +56,38 @@ 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.
 
 For number of pending runs, the autoscaler targets 10 pending runs. For example, if the current number of containers is 1, but the number of pending runs in 20, the autoscaler will scale up the deployment to 2 containers (20 pending runs / 2 containers = 10 pending runs per container).
 
-Each metric is computed independently and the autoscaler will determine the scaling action based on the metric that results in the largest number of containers.
+Each metric is computed independently and the autoscaler will determine the scaling action based on the metric that results in the most number of containers.
 
 Scale down actions are delayed for 30 minutes before any action is taken. In other words, if the autoscaler decides to scale down a deployment, it will first wait for 30 minutes before scaling down. After 30 minutes, the metrics are recomputed and the deployment will scale down if the recomputed metrics result in a lower number of containers than the current number. Otherwise, the deployment remains scaled up. This "cool down" period ensures that deployments do not scale up and down too frequently.
 
 ### Static IP Addresses
 
 !!! info "Only for Cloud SaaS"
-Static IP addresses are only available for [Cloud SaaS](../concepts/langgraph_cloud.md) deployments.
+    Static IP addresses are only available for [Cloud SaaS](../concepts/langgraph_cloud.md) deployments.
 
 All traffic from deployments created after January 6th 2025 will come through a NAT gateway. This NAT gateway will have several static IP addresses depending on the data region. Refer to the table below for the list of static IP addresses:
 
 | US             | EU             |
-| -------------- | -------------- |
+|----------------|----------------|
 | 35.197.29.146  | 34.13.192.67   |
 | 34.145.102.123 | 34.147.105.64  |
 | 34.169.45.153  | 34.90.22.166   |
 | 34.82.222.17   | 34.147.36.213  |
-| 35.227.171.135 | 34.32.137.113  |
+| 35.227.171.135 | 34.32.137.113  | 
 | 34.169.88.30   | 34.91.238.184  |
 | 34.19.93.202   | 35.204.101.241 |
 | 34.19.34.50    | 35.204.48.32   |
 
 ### Custom Postgres
 
-!!! info
-Custom Postgres instances are only available for [Self-Hosted Data Plane](../concepts/langgraph_self_hosted_data_plane.md) and [Self-Hosted Control Plane](../concepts/langgraph_self_hosted_control_plane.md) deployments.
+!!! info 
+    Custom Postgres instances are only available for [Self-Hosted Data Plane](../concepts/langgraph_self_hosted_data_plane.md) and [Self-Hosted Control Plane](../concepts/langgraph_self_hosted_control_plane.md) deployments.
 
 A custom Postgres instance can be used instead of the [one automatically created by the control plane](./langgraph_control_plane.md#database-provisioning). Specify the [`POSTGRES_URI_CUSTOM`](../cloud/reference/env_var.md#postgres_uri_custom) environment variable to use a custom Postgres instance.
 
@@ -96,32 +96,33 @@ Multiple deployments can share the same Postgres instance. For example, for `Dep
 ### Custom Redis
 
 !!! info
-Custom Redis instances are only available for [Self-Hosted Data Plane](../concepts/langgraph_self_hosted_control_plane.md) and [Self-Hosted Control Plane](../concepts/langgraph_self_hosted_control_plane.md) deployments.
+    Custom Redis instances are only available for [Self-Hosted Data Plane](../concepts/langgraph_self_hosted_control_plane.md) and [Self-Hosted Control Plane](../concepts/langgraph_self_hosted_control_plane.md) deployments.
 
 A custom Redis instance can be used instead of the one automatically created by the control plane. Specify the [REDIS_URI_CUSTOM](../cloud/reference/env_var.md#redis_uri_custom) environment variable to use a custom Redis instance.
 
+
 Multiple deployments can share the same Redis instance. For example, for `Deployment A`, `REDIS_URI_CUSTOM` can be set to `redis://<hostname_1>:<port>/1` and for `Deployment B`, `REDIS_URI_CUSTOM` can be set to `redis://<hostname_1>:<port>/2`. `1` and `2` are different database numbers within the same instance, but `<hostname_1>` is shared. **The same database number cannot be used for separate deployments**.
 
 ### LangSmith Tracing
 
 LangGraph Server is automatically configured to send traces to LangSmith. See the table below for details with respect to each deployment option.
 
-| Cloud SaaS                               | Self-Hosted Data Plane                                      | Self-Hosted Control Plane                                          | Standalone Container                                                                         |
-| ---------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
+| Cloud SaaS | Self-Hosted Data Plane | Self-Hosted Control Plane | Standalone Container |
+|------------|------------------------|---------------------------|----------------------|
 | Required<br><br>Trace to LangSmith SaaS. | Optional<br><br>Disable tracing or trace to LangSmith SaaS. | Optional<br><br>Disable tracing or trace to Self-Hosted LangSmith. | Optional<br><br>Disable tracing, trace to LangSmith SaaS, or trace to Self-Hosted LangSmith. |
 
 ### Telemetry
 
 LangGraph Server is automatically configured to report telemetry metadata for billing purposes. See the table below for details with respect to each deployment option.
 
-| Cloud SaaS                        | Self-Hosted Data Plane            | Self-Hosted Control Plane                                                                                                           | Standalone Container                                                                                                                |
-| --------------------------------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
+| Cloud SaaS | Self-Hosted Data Plane | Self-Hosted Control Plane | Standalone Container |
+|------------|------------------------|---------------------------|----------------------|
 | Telemetry sent to LangSmith SaaS. | Telemetry sent to LangSmith SaaS. | Self-reported usage (audit) for air-gapped license key.<br><br>Telemetry sent to LangSmith SaaS for LangGraph Platform License Key. | Self-reported usage (audit) for air-gapped license key.<br><br>Telemetry sent to LangSmith SaaS for LangGraph Platform License Key. |
 
 ### Licensing
 
 LangGraph Server is automatically configured to perform license key validation. See the table below for details with respect to each deployment option.
 
-| Cloud SaaS                                          | Self-Hosted Data Plane                              | Self-Hosted Control Plane                                                                  | Standalone Container                                                                       |
-| --------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
+| Cloud SaaS | Self-Hosted Data Plane | Self-Hosted Control Plane | Standalone Container |
+|------------|------------------------|---------------------------|----------------------|
 | LangSmith API Key validated against LangSmith SaaS. | LangSmith API Key validated against LangSmith SaaS. | Air-gapped license key or LangGraph Platform License Key validated against LangSmith SaaS. | Air-gapped license key or LangGraph Platform License Key validated against LangSmith SaaS. |

docs/docs/concepts/langgraph_platform.md

@@ -9,7 +9,7 @@ Develop, deploy, scale, and manage agents with **LangGraph Platform** — the pu
 
 !!! tip "Get started with LangGraph Platform"
 
-    Check out the [LangGraph Platform quickstart](../tutorials/langgraph-platform/local-server.md) for instructions on how to use LangGraph Platform to run a LangGraph application locally.
+    Check out the [LangGraph Platform quickstart](../tutorials/langgraph-platform/local-server.md) for instructions on how to use LangGraph Platform run a LangGraph application locally.
 
 ## Why use LangGraph Platform?
 
@@ -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.
  
@@ -33,4 +33,4 @@ LangGraph Platform makes it easy to get your agent running in production —  wh
 
 - **[LangGraph Studio](./langgraph_studio.md)**: Enables visualization, interaction, and debugging of agentic systems that implement the LangGraph Server API protocol. Studio also integrates with LangSmith to enable tracing, evaluation, and prompt engineering.
 
-- **[Deployment](./deployment_options.md)**: There are four ways to deploy on LangGraph Platform: [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), and [Standalone Container](../concepts/langgraph_standalone_container.md).
+- **[Deployment](./deployment_options.md)**: There are four ways to deploy on LangGraph Platform: [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), and [Standalone Container](../concepts/langgraph_standalone_container.md).

docs/docs/concepts/langgraph_self_hosted_control_plane.md

@@ -3,24 +3,22 @@
 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
 
-- You use the [LangGraph CLI](./langgraph_cli.md) and/or [LangGraph Studio](./langgraph_studio.md) app to test graph locally.
+- You use `langgraph-cli` and/or [LangGraph Studio](./langgraph_studio.md) app to test graph locally.
 - You use `langgraph build` command to build image.
-- You have a Self-Hosted LangSmith instance deployed.
-- You are using Ingress for your LangSmith instance. All agents will be deployed as Kubernetes services behind this ingress.
 
 ## Self-Hosted Control Plane
 
-The [Self-Hosted Control Plane](./langgraph_self_hosted_control_plane.md) deployment option is a fully self-hosted model for deployment where you manage the [control plane](./langgraph_control_plane.md) and [data plane](./langgraph_data_plane.md) in your cloud. This option gives you full control and responsibility of the control plane and data plane infrastructure.
+The [Self-Hosted Control Plane](./langgraph_self_hosted_control_plane.md) deployment option is a fully self-hosted model for deployment where you manage the [control plane](./langgraph_control_plane.md) and [data plane](./langgraph_data_plane.md) in your cloud. This option give you full control and responsibility of the control plane and data plane infrastructure.
 
-|                                    | [Control plane](../concepts/langgraph_control_plane.md)                                                                                     | [Data plane](../concepts/langgraph_data_plane.md)                                                                                                   |
-| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **What is it?**                    | <ul><li>Control plane UI for creating deployments and revisions</li><li>Control plane APIs for creating deployments and revisions</li></ul> | <ul><li>Data plane "listener" for reconciling deployments with control plane state</li><li>LangGraph Servers</li><li>Postgres, Redis, etc</li></ul> |
-| **Where is it hosted?**            | Your cloud                                                                                                                                  | Your cloud                                                                                                                                          |
-| **Who provisions and manages it?** | You                                                                                                                                         | You                                                                                                                                                 |
+|                   | [Control plane](../concepts/langgraph_control_plane.md) | [Data plane](../concepts/langgraph_data_plane.md) |
+|-------------------|-------------------|------------|
+| **What is it?** | <ul><li>Control plane UI for creating deployments and revisions</li><li>Control plane APIs for creating deployments and revisions</li></ul> | <ul><li>Data plane "listener" for reconciling deployments with control plane state</li><li>LangGraph Servers</li><li>Postgres, Redis, etc</li></ul> |
+| **Where is it hosted?** | Your cloud | Your cloud |
+| **Who provisions and manages it?** | You | You |
 
 ### Architecture
 
@@ -28,7 +26,7 @@ The [Self-Hosted Control Plane](./langgraph_self_hosted_control_plane.md) deploy
 
 ### Compute Platforms
 
-- **Kubernetes**: The Self-Hosted Control Plane deployment option supports deploying control plane and data plane infrastructure to any Kubernetes cluster.
+ - **Kubernetes**: The Self-Hosted Control Plane deployment option supports deploying control plane and data plane infrastructure to any Kubernetes cluster.
 
 !!! tip
-If you would like to enable this on your LangSmith instance, please follow the [Self-Hosted Control Plane deployment guide](../cloud/deployment/self_hosted_control_plane.md).
+    If you would like to deploy to Kubernetes, you can use this [Helm chart](https://github.com/langchain-ai/helm/blob/main/charts/langgraph-cloud/README.md).

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
 
@@ -19,11 +19,11 @@ The Self-Hosted Data Plane deployment option is currently in beta stage and requ
 
 The [Self-Hosted Data Plane](../cloud/deployment/self_hosted_data_plane.md) deployment option is a "hybrid" model for deployment where we manage the [control plane](./langgraph_control_plane.md) in our cloud and you manage the [data plane](./langgraph_data_plane.md) in your cloud. This option provides a way to securely manage your data plane infrastructure, while offloading control plane management to us. When using the Self-Hosted Data Plane version, you authenticate with a [LangSmith](https://smith.langchain.com/) API key.
 
-|                                    | [Control plane](../concepts/langgraph_control_plane.md)                                                                                     | [Data plane](../concepts/langgraph_data_plane.md)                                                                                                   |
-| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **What is it?**                    | <ul><li>Control plane UI for creating deployments and revisions</li><li>Control plane APIs for creating deployments and revisions</li></ul> | <ul><li>Data plane "listener" for reconciling deployments with control plane state</li><li>LangGraph Servers</li><li>Postgres, Redis, etc</li></ul> |
-| **Where is it hosted?**            | LangChain's cloud                                                                                                                           | Your cloud                                                                                                                                          |
-| **Who provisions and manages it?** | LangChain                                                                                                                                   | You                                                                                                                                                 |
+|                   | [Control plane](../concepts/langgraph_control_plane.md) | [Data plane](../concepts/langgraph_data_plane.md) |
+|-------------------|-------------------|------------|
+| **What is it?** | <ul><li>Control plane UI for creating deployments and revisions</li><li>Control plane APIs for creating deployments and revisions</li></ul> | <ul><li>Data plane "listener" for reconciling deployments with control plane state</li><li>LangGraph Servers</li><li>Postgres, Redis, etc</li></ul> |
+| **Where is it hosted?** | LangChain's cloud | Your cloud |
+| **Who provisions and manages it?** | LangChain | You |
 
 For information on how to deploy a [LangGraph Server](../concepts/langgraph_server.md) to Self-Hosted Data Plane, see [Deploy to Self-Hosted Data Plane](../cloud/deployment/self_hosted_data_plane.md)
 
@@ -37,4 +37,4 @@ For information on how to deploy a [LangGraph Server](../concepts/langgraph_serv
 - **Amazon ECS**: Coming soon!
 
 !!! tip
-If you would like to deploy to Kubernetes, you can follow the [Self-Hosted Data Plane deployment guide](../cloud/deployment/self_hosted_data_plane.md).
+    If you would like to deploy to Kubernetes, you can use this [Helm chart](https://github.com/langchain-ai/helm/blob/main/charts/langgraph-cloud/README.md).

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:
@@ -26,7 +26,7 @@ Feature Differences:
 |-------|------------|------------|
 | [Cron Jobs](../cloud/concepts/cron_jobs.md) |❌|✅|
 | [Custom Authentication](../concepts/auth.md) |❌|✅|
-| [Deployment options](../concepts/deployment_options.md) | Standalone container | Cloud SaaS, Self-Hosted Data Plane, Self-Hosted Control Plane, Standalone container
+| [Deployment options](../concepts/deployment_options.md) | Standalone container | Cloud Saas, Self-Hosted Data Plane, Self-Hosted Control Plane, Standalone container
 
 ## Application structure
 

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.
-
 ## Architecture
 
 ![Standalone Container](./img/langgraph_platform_deployment_architecture.png)

docs/docs/concepts/langgraph_studio.md

@@ -21,10 +21,9 @@ Key features of LangGraph Studio:
 
 - Visualize your graph architecture
 - [Run and interact with your agent](../cloud/how-tos/invoke_studio.md)
-- [Manage assistants](../cloud/how-tos/studio/manage_assistants.md)
+- [Manage assistants](../cloud/how-tos/studio/manage_assistants.md.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)
 
@@ -34,7 +33,7 @@ Studio supports two modes:
 
 ### Graph mode
 
-Graph mode exposes the full feature-set of Studio and is useful when you would like as many details about the execution of your agent, including the nodes traversed, intermediate states, and LangSmith integrations (such as adding to datasets and playground).
+Graph mode exposes the full feature-set of Studio and is useful when you would like as many details about the execution of your agent, including the nodes traversed, intermediate states, and LangSmith integrations (such as adding to datasets an playground).
 
 ### Chat mode
 
@@ -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/low_level.md

@@ -9,13 +9,13 @@ search:
 
 At its core, LangGraph models agent workflows as graphs. You define the behavior of your agents using three key components:
 
-1. [`State`](#state): A shared data structure that represents the current snapshot of your application. It can be any data type, but is typically defined using a shared state schema.
+1. [`State`](#state): A shared data structure that represents the current snapshot of your application. It can be any Python type, but is typically a `TypedDict` or Pydantic `BaseModel`.
 
-2. [`Nodes`](#nodes): Functions that encode the logic of your agents. They receive the current state as input, perform some computation or side-effect, and return an updated state.
+2. [`Nodes`](#nodes): Python functions that encode the logic of your agents. They receive the current `State` as input, perform some computation or side-effect, and return an updated `State`.
 
-3. [`Edges`](#edges): Functions that determine which `Node` to execute next based on the current state. They can be conditional branches or fixed transitions.
+3. [`Edges`](#edges): Python functions that determine which `Node` to execute next based on the current `State`. They can be conditional branches or fixed transitions.
 
-By composing `Nodes` and `Edges`, you can create complex, looping workflows that evolve the state over time. The real power, though, comes from how LangGraph manages that state. To emphasize: `Nodes` and `Edges` are nothing more than functions - they can contain an LLM or just good ol' code.
+By composing `Nodes` and `Edges`, you can create complex, looping workflows that evolve the `State` over time. The real power, though, comes from how LangGraph manages that `State`. To emphasize: `Nodes` and `Edges` are nothing more than Python functions - they can contain an LLM or just good ol' Python code.
 
 In short: _nodes do the work, edges tell what to do next_.
 
@@ -33,51 +33,21 @@ To build your graph, you first define the [state](#state), you then add [nodes](
 
 Compiling is a pretty simple step. It provides a few basic checks on the structure of your graph (no orphaned nodes, etc). It is also where you can specify runtime args like [checkpointers](./persistence.md) and breakpoints. You compile your graph by just calling the `.compile` method:
 
-:::python
-
 ```python
 graph = graph_builder.compile(...)
 ```
 
-:::
-
-:::js
-
-```typescript
-const graph = new StateGraph(StateAnnotation)
-  .addNode("nodeA", nodeA)
-  .addEdge(START, "nodeA")
-  .addEdge("nodeA", END)
-  .compile();
-```
-
-:::
-
 You **MUST** compile your graph before you can use it.
 
 ## State
 
-:::python
 The first thing you do when you define a graph is define the `State` of the graph. The `State` consists of the [schema of the graph](#schema) as well as [`reducer` functions](#reducers) which specify how to apply updates to the state. The schema of the `State` will be the input schema to all `Nodes` and `Edges` in the graph, and can be either a `TypedDict` or a `Pydantic` model. All `Nodes` will emit updates to the `State` which are then applied using the specified `reducer` function.
-:::
-
-:::js
-The first thing you do when you define a graph is define the `State` of the graph. The `State` consists of the [schema of the graph](#schema) as well as [`reducer` functions](#reducers) which specify how to apply updates to the state. The schema of the `State` will be the input schema to all `Nodes` and `Edges` in the graph, and can be either a Zod schema or a schema built using `Annotation.Root`. All `Nodes` will emit updates to the `State` which are then applied using the specified `reducer` function.
-:::
 
 ### Schema
 
-:::python
 The main documented way to specify the schema of a graph is by using `TypedDict`. However, we also support [using a Pydantic BaseModel](../how-tos/graph-api.ipynb#use-pydantic-models-for-graph-state) as your graph state to add **default values** and additional data validation.
 
 By default, the graph will have the same input and output schemas. If you want to change this, you can also specify explicit input and output schemas directly. This is useful when you have a lot of keys, and some are explicitly for input and others for output. See the [guide here](../how-tos/graph-api.ipynb#define-input-and-output-schemas) for how to use.
-:::
-
-:::js
-The main documented way to specify the schema of a graph is by using Zod schemas. However, we also support using the `Annotation` API to define the schema of the graph.
-
-By default, the graph will have the same input and output schemas. If you want to change this, you can also specify explicit input and output schemas directly. This is useful when you have a lot of keys, and some are explicitly for input and others for output.
-:::
 
 #### Multiple schemas
 
@@ -86,16 +56,12 @@ Typically, all graph nodes communicate with a single schema. This means that the
 - Internal nodes can pass information that is not required in the graph's input / output.
 - We may also want to use different input / output schemas for the graph. The output might, for example, only contain a single relevant output key.
 
-It is possible to have nodes write to private state channels inside the graph for internal node communication. We can simply define a private schema, `PrivateState`.
-
-See [this guide](../how-tos/graph-api.ipynb#pass-private-state-between-nodes) for more detail.
+It is possible to have nodes write to private state channels inside the graph for internal node communication. We can simply define a private schema, `PrivateState`. See [this guide](../how-tos/graph-api.ipynb#pass-private-state-between-nodes) for more detail.
 
 It is also possible to define explicit input and output schemas for a graph. In these cases, we define an "internal" schema that contains _all_ keys relevant to graph operations. But, we also define `input` and `output` schemas that are sub-sets of the "internal" schema to constrain the input and output of the graph. See [this guide](../how-tos/graph-api.ipynb#define-input-and-output-schemas) for more detail.
 
 Let's look at an example:
 
-:::python
-
 ```python
 class InputState(TypedDict):
     user_input: str
@@ -123,7 +89,7 @@ def node_3(state: PrivateState) -> OutputState:
     # Read from PrivateState, write to OutputState
     return {"graph_output": state["bar"] + " Lance"}
 
-builder = StateGraph(OverallState,input_schema=InputState,output_schema=OutputState)
+builder = StateGraph(OverallState,input=InputState,output=OutputState)
 builder.add_node("node_1", node_1)
 builder.add_node("node_2", node_2)
 builder.add_node("node_3", node_3)
@@ -134,80 +100,14 @@ builder.add_edge("node_3", END)
 
 graph = builder.compile()
 graph.invoke({"user_input":"My"})
-# {'graph_output': 'My name is Lance'}
+{'graph_output': 'My name is Lance'}
 ```
 
-:::
-
-:::js
-
-```typescript
-const InputState = z.object({
-  userInput: z.string(),
-});
-
-const OutputState = z.object({
-  graphOutput: z.string(),
-});
-
-const OverallState = z.object({
-  foo: z.string(),
-  userInput: z.string(),
-  graphOutput: z.string(),
-});
-
-const PrivateState = z.object({
-  bar: z.string(),
-});
-
-const graph = new StateGraph({
-  state: OverallState,
-  input: InputState,
-  output: OutputState,
-})
-  .addNode("node1", (state) => {
-    // Write to OverallState
-    return { foo: state.userInput + " name" };
-  })
-  .addNode("node2", (state) => {
-    // Read from OverallState, write to PrivateState
-    return { bar: state.foo + " is" };
-  })
-  .addNode(
-    "node3",
-    (state) => {
-      // Read from PrivateState, write to OutputState
-      return { graphOutput: state.bar + " Lance" };
-    },
-    { input: PrivateState }
-  )
-  .addEdge(START, "node1")
-  .addEdge("node1", "node2")
-  .addEdge("node2", "node3")
-  .addEdge("node3", END)
-  .compile();
-
-await graph.invoke({ userInput: "My" });
-// { graphOutput: 'My name is Lance' }
-```
-
-:::
-
 There are two subtle and important points to note here:
 
-:::python
+1. We pass `state: InputState` as the input schema to `node_1`. But, we write out to `foo`, a channel in `OverallState`. How can we write out to a state channel that is not included in the input schema? This is because a node _can write to any state channel in the graph state._ The graph state is the union of of the state channels defined at initialization, which includes `OverallState` and the filters `InputState` and `OutputState`.
 
-1. We pass `state: InputState` as the input schema to `node_1`. But, we write out to `foo`, a channel in `OverallState`. How can we write out to a state channel that is not included in the input schema? This is because a node _can write to any state channel in the graph state._ The graph state is the union of the state channels defined at initialization, which includes `OverallState` and the filters `InputState` and `OutputState`.
-
-2. We initialize the graph with `StateGraph(OverallState,input_schema=InputState,output_schema=OutputState)`. So, how can we write to `PrivateState` in `node_2`? How does the graph gain access to this schema if it was not passed in the `StateGraph` initialization? We can do this because _nodes can also declare additional state channels_ as long as the state schema definition exists. In this case, the `PrivateState` schema is defined, so we can add `bar` as a new state channel in the graph and write to it.
-   :::
-
-:::js
-
-1. We pass `state` as the input schema to `node1`. But, we write out to `foo`, a channel in `OverallState`. How can we write out to a state channel that is not included in the input schema? This is because a node _can write to any state channel in the graph state._ The graph state is the union of the state channels defined at initialization, which includes `OverallState` and the filters `InputState` and `OutputState`.
-
-2. We initialize the graph with `StateGraph({ state: OverallState, input: InputState, output: OutputState })`. So, how can we write to `PrivateState` in `node2`? How does the graph gain access to this schema if it was not passed in the `StateGraph` initialization? We can do this because _nodes can also declare additional state channels_ as long as the state schema definition exists. In this case, the `PrivateState` schema is defined, so we can add `bar` as a new state channel in the graph and write to it.
-   :::
+2. We initialize the graph with `StateGraph(OverallState,input=InputState,output=OutputState)`. So, how can we write to `PrivateState` in `node_2`? How does the graph gain access to this schema if it was not passed in the `StateGraph` initialization? We can do this because _nodes can also declare additional state channels_ as long as the state schema definition exists. In this case, the `PrivateState` schema is defined, so we can add `bar` as a new state channel in the graph and write to it.
 
 ### Reducers
 
@@ -219,8 +119,6 @@ These two examples show how to use the default reducer:
 
 **Example A:**
 
-:::python
-
 ```python
 from typing_extensions import TypedDict
 
@@ -229,33 +127,10 @@ class State(TypedDict):
     bar: list[str]
 ```
 
-:::
-
-:::js
-
-```typescript
-const State = z.object({
-  foo: z.number(),
-  bar: z.array(z.string()),
-});
-```
-
-:::
-
-In this example, no reducer functions are specified for any key. Let's assume the input to the graph is:
-
-:::python
-`{"foo": 1, "bar": ["hi"]}`. Let's then assume the first `Node` returns `{"foo": 2}`. This is treated as an update to the state. Notice that the `Node` does not need to return the whole `State` schema - just an update. After applying this update, the `State` would then be `{"foo": 2, "bar": ["hi"]}`. If the second node returns `{"bar": ["bye"]}` then the `State` would then be `{"foo": 2, "bar": ["bye"]}`
-:::
-
-:::js
-`{ foo: 1, bar: ["hi"] }`. Let's then assume the first `Node` returns `{ foo: 2 }`. This is treated as an update to the state. Notice that the `Node` does not need to return the whole `State` schema - just an update. After applying this update, the `State` would then be `{ foo: 2, bar: ["hi"] }`. If the second node returns `{ bar: ["bye"] }` then the `State` would then be `{ foo: 2, bar: ["bye"] }`
-:::
+In this example, no reducer functions are specified for any key. Let's assume the input to the graph is `{"foo": 1, "bar": ["hi"]}`. Let's then assume the first `Node` returns `{"foo": 2}`. This is treated as an update to the state. Notice that the `Node` does not need to return the whole `State` schema - just an update. After applying this update, the `State` would then be `{"foo": 2, "bar": ["hi"]}`. If the second node returns `{"bar": ["bye"]}` then the `State` would then be `{"foo": 2, "bar": ["bye"]}`
 
 **Example B:**
 
-:::python
-
 ```python
 from typing import Annotated
 from typing_extensions import TypedDict
@@ -267,56 +142,21 @@ class State(TypedDict):
 ```
 
 In this example, we've used the `Annotated` type to specify a reducer function (`operator.add`) for the second key (`bar`). Note that the first key remains unchanged. Let's assume the input to the graph is `{"foo": 1, "bar": ["hi"]}`. Let's then assume the first `Node` returns `{"foo": 2}`. This is treated as an update to the state. Notice that the `Node` does not need to return the whole `State` schema - just an update. After applying this update, the `State` would then be `{"foo": 2, "bar": ["hi"]}`. If the second node returns `{"bar": ["bye"]}` then the `State` would then be `{"foo": 2, "bar": ["hi", "bye"]}`. Notice here that the `bar` key is updated by adding the two lists together.
-:::
-
-:::js
-
-```typescript
-import { z } from "zod";
-import { withLangGraph } from "@langchain/langgraph/zod";
-
-const State = z.object({
-  foo: z.number(),
-  bar: withLangGraph(z.array(z.string()), {
-    reducer: {
-      fn: (x, y) => x.concat(y),
-    },
-  }),
-});
-```
-
-In this example, we've used the `withLangGraph` function to specify a reducer function for the second key (`bar`). Note that the first key remains unchanged. Let's assume the input to the graph is `{ foo: 1, bar: ["hi"] }`. Let's then assume the first `Node` returns `{ foo: 2 }`. This is treated as an update to the state. Notice that the `Node` does not need to return the whole `State` schema - just an update. After applying this update, the `State` would then be `{ foo: 2, bar: ["hi"] }`. If the second node returns `{ bar: ["bye"] }` then the `State` would then be `{ foo: 2, bar: ["hi", "bye"] }`. Notice here that the `bar` key is updated by adding the two arrays together.
-:::
 
 ### Working with Messages in Graph State
 
 #### Why use messages?
 
-:::python
 Most modern LLM providers have a chat model interface that accepts a list of messages as input. LangChain's [`ChatModel`](https://python.langchain.com/docs/concepts/#chat-models) in particular accepts a list of `Message` objects as inputs. These messages come in a variety of forms such as `HumanMessage` (user input) or `AIMessage` (LLM response). To read more about what message objects are, please refer to [this](https://python.langchain.com/docs/concepts/#messages) conceptual guide.
-:::
-
-:::js
-Most modern LLM providers have a chat model interface that accepts a list of messages as input. LangChain's [`ChatModel`](https://js.langchain.com/docs/concepts/#chat-models) in particular accepts a list of `Message` objects as inputs. These messages come in a variety of forms such as `HumanMessage` (user input) or `AIMessage` (LLM response). To read more about what message objects are, please refer to [this](https://js.langchain.com/docs/concepts/#messages) conceptual guide.
-:::
 
 #### Using Messages in your Graph
 
-:::python
 In many cases, it is helpful to store prior conversation history as a list of messages in your graph state. To do so, we can add a key (channel) to the graph state that stores a list of `Message` objects and annotate it with a reducer function (see `messages` key in the example below). The reducer function is vital to telling the graph how to update the list of `Message` objects in the state with each state update (for example, when a node sends an update). If you don't specify a reducer, every state update will overwrite the list of messages with the most recently provided value. If you wanted to simply append messages to the existing list, you could use `operator.add` as a reducer.
 
 However, you might also want to manually update messages in your graph state (e.g. human-in-the-loop). If you were to use `operator.add`, the manual state updates you send to the graph would be appended to the existing list of messages, instead of updating existing messages. To avoid that, you need a reducer that can keep track of message IDs and overwrite existing messages, if updated. To achieve this, you can use the prebuilt `add_messages` function. For brand new messages, it will simply append to existing list, but it will also handle the updates for existing messages correctly.
-:::
-
-:::js
-In many cases, it is helpful to store prior conversation history as a list of messages in your graph state. To do so, we can add a key (channel) to the graph state that stores a list of `Message` objects and annotate it with a reducer function (see `messages` key in the example below). The reducer function is vital to telling the graph how to update the list of `Message` objects in the state with each state update (for example, when a node sends an update). If you don't specify a reducer, every state update will overwrite the list of messages with the most recently provided value. If you wanted to simply append messages to the existing list, you could use a function that concatenates arrays as a reducer.
-
-However, you might also want to manually update messages in your graph state (e.g. human-in-the-loop). If you were to use a simple concatenation function, the manual state updates you send to the graph would be appended to the existing list of messages, instead of updating existing messages. To avoid that, you need a reducer that can keep track of message IDs and overwrite existing messages, if updated. To achieve this, you can use the prebuilt `MessagesZodState` schema. For brand new messages, it will simply append to existing list, but it will also handle the updates for existing messages correctly.
-:::
 
 #### Serialization
 
-:::python
 In addition to keeping track of message IDs, the `add_messages` function will also try to deserialize messages into LangChain `Message` objects whenever a state update is received on the `messages` channel. See more information on LangChain serialization/deserialization [here](https://python.langchain.com/docs/how_to/serialization/). This allows sending graph inputs / state updates in the following format:
 
 ```python
@@ -327,7 +167,7 @@ In addition to keeping track of message IDs, the `add_messages` function will al
 {"messages": [{"type": "human", "content": "message"}]}
 ```
 
-Since the state updates are always deserialized into LangChain `Messages` when using `add_messages`, you should use dot notation to access message attributes, like `state["messages"][-1].content`. Below is an example of a graph that uses `add_messages` as its reducer function.
+Since the state updates are always deserialized into LangChain `Messages` when using `add_messages`, you should use dot notation to access message attributes, like `state["messages"][-1].content`. Below is an example of a graph that uses `add_messages` as it's reducer function.
 
 ```python
 from langchain_core.messages import AnyMessage
@@ -339,45 +179,6 @@ class GraphState(TypedDict):
     messages: Annotated[list[AnyMessage], add_messages]
 ```
 
-:::
-
-:::js
-In addition to keeping track of message IDs, `MessagesZodState` will also try to deserialize messages into LangChain `Message` objects whenever a state update is received on the `messages` channel. This allows sending graph inputs / state updates in the following format:
-
-```typescript
-// this is supported
-{
-  messages: [new HumanMessage("message")];
-}
-
-// and this is also supported
-{
-  messages: [{ role: "human", content: "message" }];
-}
-```
-
-Since the state updates are always deserialized into LangChain `Messages` when using `MessagesZodState`, you should use dot notation to access message attributes, like `state.messages[state.messages.length - 1].content`. Below is an example of a graph that uses `MessagesZodState`:
-
-```typescript
-import { StateGraph, MessagesZodState } from "@langchain/langgraph";
-
-const graph = new StateGraph(MessagesZodState)
-  ...
-```
-
-`MessagesZodState` is defined with a single `messages` key which is a list of `BaseMessage` objects and uses the appropriate reducer. Typically, there is more state to track than just messages, so we see people extend this state and add more fields, like:
-
-```typescript
-const State = z.object({
-  messages: MessagesZodState.shape.messages,
-  documents: z.array(z.string()),
-});
-```
-
-:::
-
-:::python
-
 #### MessagesState
 
 Since having a list of messages in your state is so common, there exists a prebuilt state called `MessagesState` which makes it easy to use messages. `MessagesState` is defined with a single `messages` key which is a list of `AnyMessage` objects and uses the `add_messages` reducer. Typically, there is more state to track than just messages, so we see people subclass this state and add more fields, like:
@@ -389,41 +190,26 @@ class State(MessagesState):
     documents: list[str]
 ```
 
-:::
-
 ## Nodes
 
-:::python
 In LangGraph, nodes are typically python functions (sync or async) where the **first** positional argument is the [state](#state), and (optionally), the **second** positional argument is a "config", containing optional [configurable parameters](#configuration) (such as a `thread_id`).
-:::
 
-:::js
-In LangGraph, nodes are typically functions (sync or async) where the **first** positional argument is the [state](#state), and (optionally), the **second** positional argument is a "config", containing optional [configurable parameters](#configuration) (such as a `thread_id`).
-:::
-
-:::python
 Similar to `NetworkX`, you add these nodes to a graph using the [add_node][langgraph.graph.StateGraph.add_node] method:
 
 ```python
-from typing_extensions import TypedDict
-
 from langchain_core.runnables import RunnableConfig
 from langgraph.graph import StateGraph
 
-class State(TypedDict):
-    input: str
-    results: str
-
-builder = StateGraph(State)
+builder = StateGraph(dict)
 
 
-def my_node(state: State, config: RunnableConfig):
+def my_node(state: dict, config: RunnableConfig):
     print("In node: ", config["configurable"]["user_id"])
     return {"results": f"Hello, {state['input']}!"}
 
 
 # The second argument is optional
-def my_other_node(state: State):
+def my_other_node(state: dict):
     return state
 
 
@@ -432,117 +218,47 @@ builder.add_node("other_node", my_other_node)
 ...
 ```
 
-:::
-
-:::js
-You can add nodes to a graph using the `addNode` method.
-
-```typescript
-import { StateGraph } from "@langchain/langgraph";
-import { RunnableConfig } from "@langchain/core/runnables";
-import { z } from "zod";
-
-const State = z.object({
-  input: z.string(),
-  results: z.string(),
-});
-
-const builder = new StateGraph(State);
-  .addNode("myNode", (state, config) => {
-    console.log("In node: ", config?.configurable?.user_id);
-    return { results: `Hello, ${state.input}!` };
-  })
-  addNode("otherNode", (state) => {
-    return state;
-  })
-  ...
-```
-
-:::
-
 Behind the scenes, functions are converted to [RunnableLambda](https://api.python.langchain.com/en/latest/runnables/langchain_core.runnables.base.RunnableLambda.html#langchain_core.runnables.base.RunnableLambda)s, which add batch and async support to your function, along with native tracing and debugging.
 
 If you add a node to a graph without specifying a name, it will be given a default name equivalent to the function name.
 
-:::python
-
 ```python
 builder.add_node(my_node)
 # You can then create edges to/from this node by referencing it as `"my_node"`
 ```
 
-:::
-
-:::js
-
-```typescript
-builder.addNode(myNode);
-// You can then create edges to/from this node by referencing it as `"myNode"`
-```
-
-:::
-
 ### `START` Node
 
 The `START` Node is a special node that represents the node that sends user input to the graph. The main purpose for referencing this node is to determine which nodes should be called first.
 
-:::python
-
 ```python
 from langgraph.graph import START
 
 graph.add_edge(START, "node_a")
 ```
 
-:::
-
-:::js
-
-```typescript
-import { START } from "@langchain/langgraph";
-
-graph.addEdge(START, "nodeA");
-```
-
-:::
-
 ### `END` Node
 
 The `END` Node is a special node that represents a terminal node. This node is referenced when you want to denote which edges have no actions after they are done.
 
-:::python
-
-```python
+```
 from langgraph.graph import END
 
 graph.add_edge("node_a", END)
 ```
 
-:::
-
-:::js
-
-```typescript
-import { END } from "@langchain/langgraph";
-
-graph.addEdge("nodeA", END);
-```
-
-:::
-
 ### Node Caching
 
-:::python
 LangGraph supports caching of tasks/nodes based on the input to the node. To use caching:
 
-- Specify a cache when compiling a graph (or specifying an entrypoint)
-- Specify a cache policy for nodes. Each cache policy supports:
-  - `key_func` used to generate a cache key based on the input to a node, which defaults to a `hash` of the input with pickle.
-  - `ttl`, the time to live for the cache in seconds. If not specified, the cache will never expire.
+* Specify a cache when compiling a graph (or specifying an entrypoint)
+* Specify a cache policy for nodes. Each cache policy supports:
+    * `key_func` used to generate a cache key based on the input to a node, which defaults to a `hash` of the input with pickle.
+    * `ttl`, the time to live for the cache in seconds. If not specified, the cache will never expire.
 
 For example:
 
-```python
+```py
 import time
 from typing_extensions import TypedDict
 from langgraph.graph import StateGraph
@@ -578,40 +294,6 @@ print(graph.invoke({"x": 5}, stream_mode='updates'))  # (2)!
 
 1. First run takes the full second to run (due to mocked expensive computation).
 2. Second run utilizes cache and returns quickly.
-   :::
-
-:::js
-LangGraph supports caching of tasks/nodes based on the input to the node. To use caching:
-
-- Specify a cache when compiling a graph (or specifying an entrypoint)
-- Specify a cache policy for nodes. Each cache policy supports:
-  - `keyFunc`, which is used to generate a cache key based on the input to a node.
-  - `ttl`, the time to live for the cache in seconds. If not specified, the cache will never expire.
-
-```typescript
-import { StateGraph, MessagesZodState } from "@langchain/langgraph";
-import { InMemoryCache } from "@langchain/langgraph-checkpoint";
-
-const graph = new StateGraph(MessagesZodState)
-  .addNode(
-    "expensive_node",
-    async () => {
-      // Simulate an expensive operation
-      await new Promise((resolve) => setTimeout(resolve, 3000));
-      return { result: 10 };
-    },
-    { cachePolicy: { ttl: 3 } }
-  )
-  .addEdge(START, "expensive_node")
-  .compile({ cache: new InMemoryCache() });
-
-await graph.invoke({ x: 5 }, { streamMode: "updates" }); // (1)!
-// [{"expensive_node": {"result": 10}}]
-await graph.invoke({ x: 5 }, { streamMode: "updates" }); // (2)!
-// [{"expensive_node": {"result": 10}, "__metadata__": {"cached": true}}]
-```
-
-:::
 
 ## Edges
 
@@ -626,27 +308,14 @@ A node can have MULTIPLE outgoing edges. If a node has multiple out-going edges,
 
 ### Normal Edges
 
-:::python
 If you **always** want to go from node A to node B, you can use the [add_edge][langgraph.graph.StateGraph.add_edge] method directly.
 
 ```python
 graph.add_edge("node_a", "node_b")
 ```
 
-:::
-
-:::js
-If you **always** want to go from node A to node B, you can use the [`addEdge`](insert-ref) method directly.
-
-```typescript
-graph.addEdge("nodeA", "nodeB");
-```
-
-:::
-
 ### Conditional Edges
 
-:::python
 If you want to **optionally** route to 1 or more edges (or optionally terminate), you can use the [add_conditional_edges][langgraph.graph.StateGraph.add_conditional_edges] method. This method accepts the name of a node and a "routing function" to call after that node is executed:
 
 ```python
@@ -663,36 +332,11 @@ You can optionally provide a dictionary that maps the `routing_function`'s outpu
 graph.add_conditional_edges("node_a", routing_function, {True: "node_b", False: "node_c"})
 ```
 
-:::
-
-:::js
-If you want to **optionally** route to 1 or more edges (or optionally terminate), you can use the [`addConditionalEdges`](insert-ref) method. This method accepts the name of a node and a "routing function" to call after that node is executed:
-
-```typescript
-graph.addConditionalEdges("nodeA", routingFunction);
-```
-
-Similar to nodes, the `routingFunction` accepts the current `state` of the graph and returns a value.
-
-By default, the return value `routingFunction` is used as the name of the node (or list of nodes) to send the state to next. All those nodes will be run in parallel as a part of the next superstep.
-
-You can optionally provide an object that maps the `routingFunction`'s output to the name of the next node.
-
-```typescript
-graph.addConditionalEdges("nodeA", routingFunction, {
-  true: "nodeB",
-  false: "nodeC",
-});
-```
-
-:::
-
 !!! tip
-Use [`Command`](#command) instead of conditional edges if you want to combine state updates and routing in a single function.
+    Use [`Command`](#command) instead of conditional edges if you want to combine state updates and routing in a single function.
 
 ### Entry Point
 
-:::python
 The entry point is the first node(s) that are run when the graph starts. You can use the [`add_edge`][langgraph.graph.StateGraph.add_edge] method from the virtual [`START`][langgraph.constants.START] node to the first node to execute to specify where to enter the graph.
 
 ```python
@@ -701,22 +345,8 @@ from langgraph.graph import START
 graph.add_edge(START, "node_a")
 ```
 
-:::
-
-:::js
-The entry point is the first node(s) that are run when the graph starts. You can use the [`addEdge`](insert-ref) method from the virtual [`START`](insert-ref) node to the first node to execute to specify where to enter the graph.
-
-```typescript
-import { START } from "@langchain/langgraph";
-
-graph.addEdge(START, "nodeA");
-```
-
-:::
-
 ### Conditional Entry Point
 
-:::python
 A conditional entry point lets you start at different nodes depending on custom logic. You can use [`add_conditional_edges`][langgraph.graph.StateGraph.add_conditional_edges] from the virtual [`START`][langgraph.constants.START] node to accomplish this.
 
 ```python
@@ -731,31 +361,8 @@ You can optionally provide a dictionary that maps the `routing_function`'s outpu
 graph.add_conditional_edges(START, routing_function, {True: "node_b", False: "node_c"})
 ```
 
-:::
-
-:::js
-A conditional entry point lets you start at different nodes depending on custom logic. You can use [`addConditionalEdges`](insert-ref) from the virtual [`START`](insert-ref) node to accomplish this.
-
-```typescript
-import { START } from "@langchain/langgraph";
-
-graph.addConditionalEdges(START, routingFunction);
-```
-
-You can optionally provide an object that maps the `routingFunction`'s output to the name of the next node.
-
-```typescript
-graph.addConditionalEdges(START, routingFunction, {
-  true: "nodeB",
-  false: "nodeC",
-});
-```
-
-:::
-
 ## `Send`
 
-:::python
 By default, `Nodes` and `Edges` are defined ahead of time and operate on the same shared state. However, there can be cases where the exact edges are not known ahead of time and/or you may want different versions of `State` to exist at the same time. A common example of this is with [map-reduce](https://langchain-ai.github.io/langgraph/how-tos/map-reduce/) design patterns. In this design pattern, a first node may generate a list of objects, and you may want to apply some other node to all those objects. The number of objects may be unknown ahead of time (meaning the number of edges may not be known) and the input `State` to the downstream `Node` should be different (one for each generated object).
 
 To support this design pattern, LangGraph supports returning [`Send`][langgraph.types.Send] objects from conditional edges. `Send` takes two arguments: first is the name of the node, and second is the state to pass to that node.
@@ -767,26 +374,8 @@ def continue_to_jokes(state: OverallState):
 graph.add_conditional_edges("node_a", continue_to_jokes)
 ```
 
-:::
-
-:::js
-By default, `Nodes` and `Edges` are defined ahead of time and operate on the same shared state. However, there can be cases where the exact edges are not known ahead of time and/or you may want different versions of `State` to exist at the same time. A common example of this is with map-reduce design patterns. In this design pattern, a first node may generate a list of objects, and you may want to apply some other node to all those objects. The number of objects may be unknown ahead of time (meaning the number of edges may not be known) and the input `State` to the downstream `Node` should be different (one for each generated object).
-
-To support this design pattern, LangGraph supports returning [`Send`](insert-ref) objects from conditional edges. `Send` takes two arguments: first is the name of the node, and second is the state to pass to that node.
-
-```typescript
-import { Send } from "@langchain/langgraph";
-
-graph.addConditionalEdges("nodeA", (state) => {
-  return state.subjects.map((subject) => new Send("generateJoke", { subject }));
-});
-```
-
-:::
-
 ## `Command`
 
-:::python
 It can be useful to combine control flow (edges) and state updates (nodes). For example, you might want to BOTH perform state updates AND decide which node to go to next in the SAME node. LangGraph provides a way to do so by returning a [`Command`][langgraph.types.Command] object from node functions:
 
 ```python
@@ -807,69 +396,20 @@ def my_node(state: State) -> Command[Literal["my_other_node"]]:
         return Command(update={"foo": "baz"}, goto="my_other_node")
 ```
 
-Check out this [how-to guide](../how-tos/graph-api.ipynb#combine-control-flow-and-state-updates-with-command) for an end-to-end example of how to use `Command`.
-:::
-
-:::js
-It can be useful to combine control flow (edges) and state updates (nodes). For example, you might want to BOTH perform state updates AND decide which node to go to next in the SAME node. LangGraph provides a way to do so by returning a `Command` object from node functions:
-
-```typescript
-import { Command } from "@langchain/langgraph";
-
-graph.addNode("myNode", (state) => {
-  return new Command({
-    update: { foo: "bar" },
-    goto: "myOtherNode",
-  });
-});
-```
-
-With `Command` you can also achieve dynamic control flow behavior (identical to [conditional edges](#conditional-edges)):
-
-```typescript
-import { Command } from "@langchain/langgraph";
-
-graph.addNode("myNode", (state) => {
-  if (state.foo === "bar") {
-    return new Command({
-      update: { foo: "baz" },
-      goto: "myOtherNode",
-    });
-  }
-});
-```
-
-When using `Command` in your node functions, you must add the `ends` parameter when adding the node to specify which nodes it can route to:
-
-```typescript
-builder.addNode("myNode", myNode, {
-  ends: ["myOtherNode", END],
-});
-```
-
-Check out this [how-to guide](../how-tos/graph-api.ipynb#combine-control-flow-and-state-updates-with-command) for an end-to-end example of how to use `Command`.
-:::
-:::
-
 !!! important
 
     When returning `Command` in your node functions, you must add return type annotations with the list of node names the node is routing to, e.g. `Command[Literal["my_other_node"]]`. This is necessary for the graph rendering and tells LangGraph that `my_node` can navigate to `my_other_node`.
 
+Check out this [how-to guide](../how-tos/graph-api.ipynb#combine-control-flow-and-state-updates-with-command) for an end-to-end example of how to use `Command`.
+
 ### When should I use Command instead of conditional edges?
 
-:::python
 Use `Command` when you need to **both** update the graph state **and** route to a different node. For example, when implementing [multi-agent handoffs](./multi_agent.md#handoffs) where it's important to route to a different agent and pass some information to that agent.
-:::
-
-:::js
-Use `Command` when you need to **both** update the graph state **and** route to a different node. For example, when implementing [multi-agent handoffs](./multi_agent.md#handoffs) where it's important to route to a different agent and pass some information to that agent.
-:::
 
 Use [conditional edges](#conditional-edges) to route between nodes conditionally without updating the state.
 
 ### Navigating to a node in a parent graph
 
-:::python
 If you are using [subgraphs](./subgraphs.md), you might want to navigate from a node within a subgraph to a different subgraph (i.e. a different node in the parent graph). To do so, you can specify `graph=Command.PARENT` in `Command`:
 
 ```python
@@ -889,33 +429,6 @@ def my_node(state: State) -> Command[Literal["other_subgraph"]]:
 
     When you send updates from a subgraph node to a parent graph node for a key that's shared by both parent and subgraph [state schemas](#schema), you **must** define a [reducer](#reducers) for the key you're updating in the parent graph state. See this [example](../how-tos/graph-api.ipynb#navigate-to-a-node-in-a-parent-graph).
 
-:::
-
-:::js
-If you are using [subgraphs](./subgraphs.md), you might want to navigate from a node within a subgraph to a different subgraph (i.e. a different node in the parent graph). To do so, you can specify `graph: Command.PARENT` in `Command`:
-
-```typescript
-import { Command } from "@langchain/langgraph";
-
-graph.addNode("myNode", (state) => {
-  return new Command({
-    update: { foo: "bar" },
-    goto: "otherSubgraph", // where `otherSubgraph` is a node in the parent graph
-    graph: Command.PARENT,
-  });
-});
-```
-
-!!! note
-
-    Setting `graph` to `Command.PARENT` will navigate to the closest parent graph.
-
-!!! important "State updates with `Command.PARENT`"
-
-    When you send updates from a subgraph node to a parent graph node for a key that's shared by both parent and subgraph [state schemas](#schema), you **must** define a [reducer](#reducers) for the key you're updating in the parent graph state.
-
-:::
-
 This is particularly useful when implementing [multi-agent handoffs](./multi_agent.md#handoffs).
 
 Check out [this guide](../how-tos/graph-api.ipynb#navigate-to-a-node-in-a-parent-graph) for detail.
@@ -928,13 +441,7 @@ Refer to [this guide](../how-tos/graph-api.ipynb#use-inside-tools) for detail.
 
 ### Human-in-the-loop
 
-:::python
 `Command` is an important part of human-in-the-loop workflows: when using `interrupt()` to collect user input, `Command` is then used to supply the input and resume execution via `Command(resume="User input")`. Check out [this conceptual guide](./human_in_the_loop.md) for more information.
-:::
-
-:::js
-`Command` is an important part of human-in-the-loop workflows: when using `interrupt()` to collect user input, `Command` is then used to supply the input and resume execution via `new Command({ resume: "User input" })`. Check out the [human-in-the-loop conceptual guide](./human_in_the_loop.md) for more information.
-:::
 
 ## Graph Migrations
 
@@ -950,9 +457,7 @@ LangGraph can easily handle migrations of graph definitions (nodes, edges, and s
 
 When creating a graph, you can also mark that certain parts of the graph are configurable. This is commonly done to enable easily switching between models or system prompts. This allows you to create a single "cognitive architecture" (the graph) but have multiple different instance of it.
 
-You can optionally specify a config schema when creating a graph.
-
-:::python
+You can optionally specify a `config_schema` when creating a graph.
 
 ```python
 class ConfigSchema(TypedDict):
@@ -961,48 +466,16 @@ class ConfigSchema(TypedDict):
 graph = StateGraph(State, config_schema=ConfigSchema)
 ```
 
-:::
-
-:::js
-
-```typescript
-import { z } from "zod";
-
-const ConfigSchema = z.object({
-  llm: z.string(),
-});
-
-const graph = new StateGraph(State, ConfigSchema);
-```
-
-:::
-
 You can then pass this configuration into the graph using the `configurable` config field.
 
-:::python
-
 ```python
 config = {"configurable": {"llm": "anthropic"}}
 
 graph.invoke(inputs, config=config)
 ```
 
-:::
-
-:::js
-
-```typescript
-const config = { configurable: { llm: "anthropic" } };
-
-await graph.invoke(inputs, config);
-```
-
-:::
-
 You can then access and use this configuration inside a node or conditional edge:
 
-:::python
-
 ```python
 def node_a(state, config):
     llm_type = config.get("configurable", {}).get("llm", "openai")
@@ -1011,23 +484,9 @@ def node_a(state, config):
 ```
 
 See [this guide](../how-tos/graph-api.ipynb#add-runtime-configuration) for a full breakdown on configuration.
-:::
-
-:::js
-
-```typescript
-graph.addNode("myNode", (state, config) => {
-  const llmType = config?.configurable?.llm || "openai";
-  const llm = getLlm(llmType);
-  return { results: `Hello, ${state.input}!` };
-});
-```
-
-:::
 
 ### Recursion Limit
 
-:::python
 The recursion limit sets the maximum number of [super-steps](#graphs) the graph can execute during a single execution. Once the limit is reached, LangGraph will raise `GraphRecursionError`. By default this value is set to 25 steps. The recursion limit can be set on any graph at runtime, and is passed to `.invoke`/`.stream` via the config dictionary. Importantly, `recursion_limit` is a standalone `config` key and should not be passed inside the `configurable` key as all other user-defined configuration. See the example below:
 
 ```python
@@ -1035,19 +494,6 @@ graph.invoke(inputs, config={"recursion_limit": 5, "configurable":{"llm": "anthr
 ```
 
 Read [this how-to](https://langchain-ai.github.io/langgraph/how-tos/recursion-limit/) to learn more about how the recursion limit works.
-:::
-
-:::js
-The recursion limit sets the maximum number of [super-steps](#graphs) the graph can execute during a single execution. Once the limit is reached, LangGraph will raise `GraphRecursionError`. By default this value is set to 25 steps. The recursion limit can be set on any graph at runtime, and is passed to `.invoke`/`.stream` via the config object. Importantly, `recursionLimit` is a standalone `config` key and should not be passed inside the `configurable` key as all other user-defined configuration. See the example below:
-
-```typescript
-await graph.invoke(inputs, {
-  recursionLimit: 5,
-  configurable: { llm: "anthropic" },
-});
-```
-
-:::
 
 ## Visualization
 

docs/docs/concepts/memory.md

@@ -5,204 +5,183 @@ 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.
+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.
 
-- [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. 
-
-:::python
-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.
-:::
-
-:::js
-In practice, episodic memories are often implemented through few-shot example 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 can be used to generate few-shot examples, often the challenge lies in selecting the most relevant examples based on user input.
-:::
-
-:::python
-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.
-:::
-
-:::js
-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 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.
-
-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
-```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})
-    ...
-```
-:::
-
-:::js
-```typescript
-// Node that *uses* the instructions
-const callModel = async (state: State, store: BaseStore) => {
-    const namespace = ["agent_instructions"];
-    const instructions = await store.get(namespace, "agent_a");
-    // Application logic
-    const prompt = promptTemplate.format({ 
-        instructions: instructions[0].value.instructions 
-    });
-    // ...
-};
-
-// Node that updates instructions
-const updateInstructions = async (state: State, store: BaseStore) => {
-    const namespace = ["instructions"];
-    const currentInstructions = await store.search(namespace);
-    // Memory logic
-    const prompt = promptTemplate.format({ 
-        instructions: currentInstructions[0].value.instructions, 
-        conversation: state.messages 
-    });
-    const output = await llm.invoke(prompt);
-    const newInstructions = output.new_instructions;
-    await store.put(["agent_instructions"], "agent_a", { 
-        instructions: newInstructions 
-    });
-    // ...
-};
-```
-:::
-
-![](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.
-
-:::python
 ```python
 from langgraph.store.memory import InMemoryStore
 
@@ -235,47 +214,121 @@ items = store.search(
     namespace, filter={"my-key": "my-value"}, query="language preferences"
 )
 ```
-:::
 
-:::js
-```typescript
-import { InMemoryStore } from "@langchain/langgraph";
+### Framework for thinking about long-term memory
 
-const embed = (texts: string[]): number[][] => {
-    // Replace with an actual embedding function or LangChain embeddings object
-    return texts.map(() => [1.0, 2.0]);
-};
+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:
 
-// InMemoryStore saves data to an in-memory dictionary. Use a DB-backed store in production use.
-const store = new InMemoryStore({ index: { embed, dims: 2 } });
-const userId = "my-user";
-const applicationContext = "chitchat";
-const namespace = [userId, applicationContext];
+**What is the type of memory?**
 
-await store.put(
-    namespace,
-    "a-memory",
-    {
-        rules: [
-            "User likes short, direct language",
-            "User only speaks English & TypeScript",
-        ],
-        "my-key": "my-value",
-    }
-);
+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).
 
-// get the "memory" by ID
-const item = await store.get(namespace, "a-memory");
+**When do you want to update memories?**
 
-// search for "memories" within this namespace, filtering on content equivalence, sorted by vector similarity
-const items = await store.search(
-    namespace, 
-    { 
-        filter: { "my-key": "my-value" }, 
-        query: "language preferences" 
-    }
-);
+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})
+    ...
 ```
-:::
 
-For more information about the memory store, see the [Persistence](persistence.md#memory-store) guide.
+![](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

@@ -1,3 +1,8 @@
+---
+search:
+  boost: 2
+---
+
 # Multi-agent systems
 
 An [agent](./agentic_concepts.md#agent-architectures) is _a system that uses an LLM to decide the control flow of an application_. As you develop these systems, they might grow more complex over time, making them harder to manage and scale. For example, you might run into the following problems:
@@ -20,23 +25,21 @@ The primary benefits of using multi-agent systems are:
 
 There are several ways to connect agents in a multi-agent system:
 
-- **Network**: each agent can communicate with [every other agent](../tutorials/multi_agent/multi-agent-collaboration/). Any agent can decide which other agent to call next.
-- **Supervisor**: each agent communicates with a single [supervisor](../tutorials/multi_agent/agent_supervisor/) agent. Supervisor agent makes decisions on which agent should be called next.
+- **Network**: each agent can communicate with [every other agent](https://langchain-ai.github.io/langgraph/tutorials/multi_agent/multi-agent-collaboration/). Any agent can decide which other agent to call next.
+- **Supervisor**: each agent communicates with a single [supervisor](https://langchain-ai.github.io/langgraph/tutorials/multi_agent/agent_supervisor/) agent. Supervisor agent makes decisions on which agent should be called next.
 - **Supervisor (tool-calling)**: this is a special case of supervisor architecture. Individual agents can be represented as tools. In this case, a supervisor agent uses a tool-calling LLM to decide which of the agent tools to call, as well as the arguments to pass to those agents.
-- **Hierarchical**: you can define a multi-agent system with [a supervisor of supervisors](../tutorials/multi_agent/hierarchical_agent_teams/). This is a generalization of the supervisor architecture and allows for more complex control flows.
+- **Hierarchical**: you can define a multi-agent system with [a supervisor of supervisors](https://langchain-ai.github.io/langgraph/tutorials/multi_agent/hierarchical_agent_teams/). This is a generalization of the supervisor architecture and allows for more complex control flows.
 - **Custom multi-agent workflow**: each agent communicates with only a subset of agents. Parts of the flow are deterministic, and only some agents can decide which other agents to call next.
 
 ### Handoffs
 
-In multi-agent architectures, agents can be represented as graph nodes. Each agent node executes its step(s) and decides whether to finish execution or route to another agent, including potentially routing to itself (e.g., running in a loop). A common pattern in multi-agent interactions is **handoffs**, where one agent _hands off_ control to another. Handoffs allow you to specify:
+In multi-agent architectures, agents can be represented as graph nodes. Each agent node executes its step(s) and decides whether to finish execution or route to another agent, including potentially routing to itself (e.g., running in a loop). A common pattern in multi-agent interactions is **handoffs**, where one agent *hands off* control to another. Handoffs allow you to specify:
 
-- **destination**: target agent to navigate to (e.g., name of the node to go to)
-- **payload**: [information to pass to that agent](#communication-and-state-management) (e.g., state update)
+- __destination__: target agent to navigate to (e.g., name of the node to go to)
+- __payload__: [information to pass to that agent](#communication-and-state-management) (e.g., state update)
 
 To implement handoffs in LangGraph, agent nodes can return [`Command`](./low_level.md#command) object that allows you to combine both control flow and state updates:
 
-:::python
-
 ```python
 def agent(state) -> Command[Literal["agent", "another_agent"]]:
     # the condition for routing/halting can be anything, e.g. LLM tool call / structured output, etc.
@@ -49,26 +52,6 @@ def agent(state) -> Command[Literal["agent", "another_agent"]]:
     )
 ```
 
-:::
-
-:::js
-
-```typescript
-graph.addNode((state) => {
-    // the condition for routing/halting can be anything, e.g. LLM tool call / structured output, etc.
-    const goto = getNextAgent(...); // 'agent' / 'another_agent'
-    return new Command({
-      // Specify which agent to call next
-      goto,
-      // Update the graph state
-      update: { myStateKey: "myStateValue" }
-    });
-})
-```
-
-:::
-
-:::python
 In a more complex scenario where each agent node is itself a graph (i.e., a [subgraph](./subgraphs.md)), a node in one of the agent subgraphs might want to navigate to a different agent. For example, if you have two agents, `alice` and `bob` (subgraph nodes in a parent graph), and `alice` needs to navigate to `bob`, you can set `graph=Command.PARENT` in the `Command` object:
 
 ```python
@@ -81,30 +64,8 @@ def some_node_inside_alice(state):
     )
 ```
 
-:::
-
-:::js
-In a more complex scenario where each agent node is itself a graph (i.e., a [subgraph](./subgraphs.md)), a node in one of the agent subgraphs might want to navigate to a different agent. For example, if you have two agents, `alice` and `bob` (subgraph nodes in a parent graph), and `alice` needs to navigate to `bob`, you can set `graph: Command.PARNT` in the `Command` object:
-
-```typescript
-alice.addNode((state) => {
-  return new Command({
-    goto: "bob",
-    update: { myStateKey: "myStateValue" },
-    // specify which graph to navigate to (defaults to the current graph)
-    graph: Command.PARENT,
-  });
-});
-```
-
-:::
-
 !!! note
-
-    :::python
-
-    If you need to support visualization for subgraphs communicating using `Command(graph=Command.PARENT)` you would need to wrap them in a node function with `Command` annotation:
-    Instead of this:
+    If you need to support visualization for subgraphs communicating using `Command(graph=Command.PARENT)` you would need to wrap them in a node function with `Command` annotation, e.g. instead of this:
 
     ```python
     builder.add_node(alice)
@@ -119,35 +80,13 @@ alice.addNode((state) => {
     builder.add_node("alice", call_alice)
     ```
 
-    :::
-
-    :::js
-    If you need to support visualization for subgraphs communicating using/ `Command({ graph: Command.PARENT })` you would need to wrap them in a node function with `Command` annotation:
-
-    Instead of this:
-
-    ```typescript
-    builder.addNode("alice", alice);
-    ```
-
-    you would need to do this:
-
-    ```typescript
-    builder.addNode("alice", (state) => alice.invoke(state), { ends: ["bob"] });
-    ```
-
-    :::
-
 #### Handoffs as tools
 
-One of the most common agent types is a [tool-calling agent](../agents/overview.md). For those types of agents, a common pattern is wrapping a handoff in a tool call:
-
-:::python
+One of the most common agent types is a [tool-calling agent](../agents/overview.md). For those types of agents, a common pattern is wrapping a handoff in a tool call, e.g.:
 
 ```python
 from langchain_core.tools import tool
 
-@tool
 def transfer_to_bob():
     """Transfer to bob."""
     return Command(
@@ -161,69 +100,18 @@ def transfer_to_bob():
     )
 ```
 
-:::
-
-:::js
-
-```typescript
-import { tool } from "@langchain/core/tools";
-import { Command } from "@langchain/langgraph";
-import { z } from "zod";
-
-const transferToBob = tool(
-  async () => {
-    return new Command({
-      // name of the agent (node) to go to
-      goto: "bob",
-      // data to send to the agent
-      update: { myStateKey: "myStateValue" },
-      // indicate to LangGraph that we need to navigate to
-      // agent node in a parent graph
-      graph: Command.PARENT,
-    });
-  },
-  {
-    name: "transfer_to_bob",
-    description: "Transfer to bob.",
-    schema: z.object({}),
-  }
-);
-```
-
-:::
-
 This is a special case of updating the graph state from tools where, in addition to the state update, the control flow is included as well.
 
 !!! important
 
-    If you want to use tools that return `Command`, you can either use prebuilt components, or implement your own tool-executing node that collects `Command` objects returned by the tools and returns a list of them:
-
-:::python
-You can use prebuilt [`create_react_agent`][langgraph.prebuilt.chat_agent_executor.create_react_agent] / [`ToolNode`][langgraph.prebuilt.tool_node.ToolNode] components, or implement your own:
-
-```python
-def call_tools(state):
-    ...
-    commands = [tools_by_name[tool_call["name"]].invoke(tool_call) for tool_call in tool_calls]
-    return commands
-```
-
-:::
-
-:::js
-You can use prebuilt [`createReactAgent`][<insert-ref>] / [`ToolNode`][<insert-ref>] components, or implement your own:
-
-```typescript
-graph.addNode("call_tools", async (state) => {
-  // ... tool execution logic
-  const commands = toolCalls.map((toolCall) =>
-    toolsByName[toolCall.name].invoke(toolCall)
-  );
-  return commands;
-});
-```
-
-:::
+    If you want to use tools that return `Command`, you can either use prebuilt [`create_react_agent`][langgraph.prebuilt.chat_agent_executor.create_react_agent] / [`ToolNode`][langgraph.prebuilt.tool_node.ToolNode] components, or implement your own tool-executing node that collects `Command` objects returned by the tools and returns a list of them, e.g.:
+    
+    ```python
+    def call_tools(state):
+        ...
+        commands = [tools_by_name[tool_call["name"]].invoke(tool_call) for tool_call in tool_calls]
+        return commands
+    ```
 
 Let's now take a closer look at the different multi-agent architectures.
 
@@ -231,7 +119,6 @@ Let's now take a closer look at the different multi-agent architectures.
 
 In this architecture, agents are defined as graph nodes. Each agent can communicate with every other agent (many-to-many connections) and can decide which agent to call next. This architecture is good for problems that do not have a clear hierarchy of agents or a specific sequence in which agents should be called.
 
-:::python
 
 ```python
 from typing import Literal
@@ -276,70 +163,10 @@ builder.add_edge(START, "agent_1")
 network = builder.compile()
 ```
 
-:::
-
-:::js
-
-```typescript
-import { StateGraph, MessagesZodState, START, END } from "@langchain/langgraph";
-import { ChatOpenAI } from "@langchain/openai";
-import { Command } from "@langchain/langgraph";
-import { z } from "zod";
-
-const model = new ChatOpenAI();
-
-const agent1 = async (state: z.infer<typeof MessagesZodState>) => {
-  // you can pass relevant parts of the state to the LLM (e.g., state.messages)
-  // to determine which agent to call next. a common pattern is to call the model
-  // with a structured output (e.g. force it to return an output with a "next_agent" field)
-  const response = await model.invoke(...);
-  // route to one of the agents or exit based on the LLM's decision
-  // if the LLM returns "__end__", the graph will finish execution
-  return new Command({
-    goto: response.nextAgent,
-    update: { messages: [response.content] },
-  });
-};
-
-const agent2 = async (state: z.infer<typeof MessagesZodState>) => {
-  const response = await model.invoke(...);
-  return new Command({
-    goto: response.nextAgent,
-    update: { messages: [response.content] },
-  });
-};
-
-const agent3 = async (state: z.infer<typeof MessagesZodState>) => {
-  // ...
-  return new Command({
-    goto: response.nextAgent,
-    update: { messages: [response.content] },
-  });
-};
-
-const builder = new StateGraph(MessagesZodState)
-  .addNode("agent1", agent1, {
-    ends: ["agent2", "agent3", END]
-  })
-  .addNode("agent2", agent2, {
-    ends: ["agent1", "agent3", END]
-  })
-  .addNode("agent3", agent3, {
-    ends: ["agent1", "agent2", END]
-  })
-  .addEdge(START, "agent1");
-
-const network = builder.compile();
-```
-
-:::
-
 ### Supervisor
 
 In this architecture, we define agents as nodes and add a supervisor node (LLM) that decides which agent nodes should be called next. We use [`Command`](./low_level.md#command) to route execution to the appropriate agent node based on supervisor's decision. This architecture also lends itself well to running multiple agents in parallel or using [map-reduce](../how-tos/graph-api.ipynb#map-reduce-and-the-send-api) pattern.
 
-:::python
-
 ```python
 from typing import Literal
 from langchain_openai import ChatOpenAI
@@ -383,70 +210,12 @@ builder.add_edge(START, "supervisor")
 supervisor = builder.compile()
 ```
 
-:::
-
-:::js
-
-```typescript
-import { StateGraph, MessagesZodState, Command, START, END } from "@langchain/langgraph";
-import { ChatOpenAI } from "@langchain/openai";
-import { z } from "zod";
-
-const model = new ChatOpenAI();
-
-const supervisor = async (state: z.infer<typeof MessagesZodState>) => {
-  // you can pass relevant parts of the state to the LLM (e.g., state.messages)
-  // to determine which agent to call next. a common pattern is to call the model
-  // with a structured output (e.g. force it to return an output with a "next_agent" field)
-  const response = await model.invoke(...);
-  // route to one of the agents or exit based on the supervisor's decision
-  // if the supervisor returns "__end__", the graph will finish execution
-  return new Command({ goto: response.nextAgent });
-};
-
-const agent1 = async (state: z.infer<typeof MessagesZodState>) => {
-  // you can pass relevant parts of the state to the LLM (e.g., state.messages)
-  // and add any additional logic (different models, custom prompts, structured output, etc.)
-  const response = await model.invoke(...);
-  return new Command({
-    goto: "supervisor",
-    update: { messages: [response] },
-  });
-};
-
-const agent2 = async (state: z.infer<typeof MessagesZodState>) => {
-  const response = await model.invoke(...);
-  return new Command({
-    goto: "supervisor",
-    update: { messages: [response] },
-  });
-};
-
-const builder = new StateGraph(MessagesZodState)
-  .addNode("supervisor", supervisor, {
-    ends: ["agent1", "agent2", END]
-  })
-  .addNode("agent1", agent1, {
-    ends: ["supervisor"]
-  })
-  .addNode("agent2", agent2, {
-    ends: ["supervisor"]
-  })
-  .addEdge(START, "supervisor");
-
-const supervisorGraph = builder.compile();
-```
-
-:::
-
 Check out this [tutorial](https://langchain-ai.github.io/langgraph/tutorials/multi_agent/agent_supervisor/) for an example of supervisor multi-agent architecture.
 
 ### Supervisor (tool-calling)
 
 In this variant of the [supervisor](#supervisor) architecture, we define a supervisor [agent](./agentic_concepts.md#agent-architectures) which is responsible for calling sub-agents. The sub-agents are exposed to the supervisor as tools, and the supervisor agent decides which tool to call next. The supervisor agent follows a [standard implementation](./agentic_concepts.md#tool-calling-agent) as an LLM running in a while loop calling tools until it decides to stop.
 
-:::python
-
 ```python
 from typing import Annotated
 from langchain_openai import ChatOpenAI
@@ -475,67 +244,12 @@ tools = [agent_1, agent_2]
 supervisor = create_react_agent(model, tools)
 ```
 
-:::
-
-:::js
-
-```typescript
-import { ChatOpenAI } from "@langchain/openai";
-import { createReactAgent } from "@langchain/langgraph/prebuilt";
-import { tool } from "@langchain/core/tools";
-import { z } from "zod";
-
-const model = new ChatOpenAI();
-
-// this is the agent function that will be called as tool
-// notice that you can pass the state to the tool via config parameter
-const agent1 = tool(
-  async (_, config) => {
-    const state = config.configurable?.state;
-    // you can pass relevant parts of the state to the LLM (e.g., state.messages)
-    // and add any additional logic (different models, custom prompts, structured output, etc.)
-    const response = await model.invoke(...);
-    // return the LLM response as a string (expected tool response format)
-    // this will be automatically turned to ToolMessage
-    // by the prebuilt createReactAgent (supervisor)
-    return response.content;
-  },
-  {
-    name: "agent1",
-    description: "Agent 1 description",
-    schema: z.object({}),
-  }
-);
-
-const agent2 = tool(
-  async (_, config) => {
-    const state = config.configurable?.state;
-    const response = await model.invoke(...);
-    return response.content;
-  },
-  {
-    name: "agent2",
-    description: "Agent 2 description",
-    schema: z.object({}),
-  }
-);
-
-const tools = [agent1, agent2];
-// the simplest way to build a supervisor w/ tool-calling is to use prebuilt ReAct agent graph
-// that consists of a tool-calling LLM node (i.e. supervisor) and a tool-executing node
-const supervisor = createReactAgent({ llm: model, tools });
-```
-
-:::
-
 ### Hierarchical
 
 As you add more agents to your system, it might become too hard for the supervisor to manage all of them. The supervisor might start making poor decisions about which agent to call next, or the context might become too complex for a single supervisor to keep track of. In other words, you end up with the same problems that motivated the multi-agent architecture in the first place.
 
 To address this, you can design your system _hierarchically_. For example, you can create separate, specialized teams of agents managed by individual supervisors, and a top-level supervisor to manage the teams.
 
-:::python
-
 ```python
 from typing import Literal
 from langchain_openai import ChatOpenAI
@@ -604,97 +318,6 @@ builder.add_edge("team_2_graph", "top_level_supervisor")
 graph = builder.compile()
 ```
 
-:::
-
-:::js
-
-```typescript
-import { StateGraph, MessagesZodState, Command, START, END } from "@langchain/langgraph";
-import { ChatOpenAI } from "@langchain/openai";
-import { z } from "zod";
-
-const model = new ChatOpenAI();
-
-// define team 1 (same as the single supervisor example above)
-
-const team1Supervisor = async (state: z.infer<typeof MessagesZodState>) => {
-  const response = await model.invoke(...);
-  return new Command({ goto: response.nextAgent });
-};
-
-const team1Agent1 = async (state: z.infer<typeof MessagesZodState>) => {
-  const response = await model.invoke(...);
-  return new Command({
-    goto: "team1Supervisor",
-    update: { messages: [response] }
-  });
-};
-
-const team1Agent2 = async (state: z.infer<typeof MessagesZodState>) => {
-  const response = await model.invoke(...);
-  return new Command({
-    goto: "team1Supervisor",
-    update: { messages: [response] }
-  });
-};
-
-const team1Builder = new StateGraph(MessagesZodState)
-  .addNode("team1Supervisor", team1Supervisor, {
-    ends: ["team1Agent1", "team1Agent2", END]
-  })
-  .addNode("team1Agent1", team1Agent1, {
-    ends: ["team1Supervisor"]
-  })
-  .addNode("team1Agent2", team1Agent2, {
-    ends: ["team1Supervisor"]
-  })
-  .addEdge(START, "team1Supervisor");
-const team1Graph = team1Builder.compile();
-
-// define team 2 (same as the single supervisor example above)
-const team2Supervisor = async (state: z.infer<typeof MessagesZodState>) => {
-  // ...
-};
-
-const team2Agent1 = async (state: z.infer<typeof MessagesZodState>) => {
-  // ...
-};
-
-const team2Agent2 = async (state: z.infer<typeof MessagesZodState>) => {
-  // ...
-};
-
-const team2Builder = new StateGraph(MessagesZodState);
-// ... build team2Graph
-const team2Graph = team2Builder.compile();
-
-// define top-level supervisor
-
-const topLevelSupervisor = async (state: z.infer<typeof MessagesZodState>) => {
-  // you can pass relevant parts of the state to the LLM (e.g., state.messages)
-  // to determine which team to call next. a common pattern is to call the model
-  // with a structured output (e.g. force it to return an output with a "next_team" field)
-  const response = await model.invoke(...);
-  // route to one of the teams or exit based on the supervisor's decision
-  // if the supervisor returns "__end__", the graph will finish execution
-  return new Command({ goto: response.nextTeam });
-};
-
-const builder = new StateGraph(MessagesZodState)
-  .addNode("topLevelSupervisor", topLevelSupervisor, {
-    ends: ["team1Graph", "team2Graph", END]
-  })
-  .addNode("team1Graph", team1Graph)
-  .addNode("team2Graph", team2Graph)
-  .addEdge(START, "topLevelSupervisor")
-  .addEdge("team1Graph", "topLevelSupervisor")
-  .addEdge("team2Graph", "topLevelSupervisor");
-
-const graph = builder.compile();
-```
-
-:::
-
 ### Custom multi-agent workflow
 
 In this architecture we add individual agents as graph nodes and define the order in which agents are called ahead of time, in a custom workflow. In LangGraph the workflow can be defined in two ways:
@@ -703,8 +326,6 @@ In this architecture we add individual agents as graph nodes and define the orde
 
 - **Dynamic control flow (Command)**: in LangGraph you can allow LLMs to decide parts of your application control flow. This can be achieved by using [`Command`](./low_level.md#command). A special case of this is a [supervisor tool-calling](#supervisor-tool-calling) architecture. In that case, the tool-calling LLM powering the supervisor agent will make decisions about the order in which the tools (agents) are being called.
 
-:::python
-
 ```python
 from langchain_openai import ChatOpenAI
 from langgraph.graph import StateGraph, MessagesState, START
@@ -727,37 +348,6 @@ builder.add_edge(START, "agent_1")
 builder.add_edge("agent_1", "agent_2")
 ```
 
-:::
-
-:::js
-
-```typescript
-import { StateGraph, MessagesZodState, START } from "@langchain/langgraph";
-import { ChatOpenAI } from "@langchain/openai";
-import { z } from "zod";
-
-const model = new ChatOpenAI();
-
-const agent1 = async (state: z.infer<typeof MessagesZodState>) => {
-  const response = await model.invoke(...);
-  return { messages: [response] };
-};
-
-const agent2 = async (state: z.infer<typeof MessagesZodState>) => {
-  const response = await model.invoke(...);
-  return { messages: [response] };
-};
-
-const builder = new StateGraph(MessagesZodState)
-  .addNode("agent1", agent1)
-  .addNode("agent2", agent2)
-  // define the flow explicitly
-  .addEdge(START, "agent1")
-  .addEdge("agent1", "agent2");
-```
-
-:::
-
 ## Communication and state management
 
 The most important thing when building multi-agent systems is figuring out how the agents communicate.
@@ -785,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
 
@@ -799,27 +389,12 @@ It can be helpful to indicate which agent a particular AI message is from, espec
 
 ### Representing handoffs in message history
 
-:::python
 Handoffs are typically done via the LLM calling a dedicated [handoff tool](#handoffs-as-tools). This is represented as an [AI message](https://python.langchain.com/docs/concepts/messages/#aimessage) with tool calls that is passed to the next agent (LLM). Most LLM providers don't support receiving AI messages with tool calls **without** corresponding tool messages.
-:::
-
-:::js
-Handoffs are typically done via the LLM calling a dedicated [handoff tool](#handoffs-as-tools). This is represented as an [AI message](https://js.langchain.com/docs/concepts/messages/#aimessage) with tool calls that is passed to the next agent (LLM). Most LLM providers don't support receiving AI messages with tool calls **without** corresponding tool messages.
-:::
 
 You therefore have two options:
 
-:::python
-
 1. Add an extra [tool message](https://python.langchain.com/docs/concepts/messages/#toolmessage) to the message list, e.g., "Successfully transferred to agent X"
 2. Remove the AI message with the tool calls
-   :::
-
-:::js
-
-1. Add an extra [tool message](https://js.langchain.com/docs/concepts/messages/#toolmessage) to the message list, e.g., "Successfully transferred to agent X"
-2. Remove the AI message with the tool calls
-   :::
 
 In practice, we see that most developers opt for option (1).
 
@@ -827,25 +402,16 @@ In practice, we see that most developers opt for option (1).
 
 A common practice is to have multiple agents communicating on a shared message list, but only [adding their final messages to the list](#sharing-only-final-results). This means that any intermediate messages (e.g., tool calls) are not saved in this list.
 
-What if you **do** want to save these messages so that if this particular subagent is invoked in the future you can pass those back in?
+What if you __do__ want to save these messages so that if this particular subagent is invoked in the future you can pass those back in?
 
 There are two high-level approaches to achieve that:
 
-:::python
-
 1. Store these messages in the shared message list, but filter the list before passing it to the subagent LLM. For example, you can choose to filter out all tool calls from **other** agents.
 2. Store a separate message list for each agent (e.g., `alice_messages`) in the subagent's graph state. This would be their "view" of what the message history looks like.
-   :::
-
-:::js
-
-1. Store these messages in the shared message list, but filter the list before passing it to the subagent LLM. For example, you can choose to filter out all tool calls from **other** agents.
-2. Store a separate message list for each agent (e.g., `aliceMessages`) in the subagent's graph state. This would be their "view" of what the message history looks like.
-   :::
 
 ### Using different state schemas
 
 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 [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.