Keep in sync:
AGENTS.mdandCLAUDE.mdcontain identical guidelines. If you update one, update the other.
Documentation for LangChain products hosted on Mintlify. These guidelines apply to manually authored content under src/, not Mintlify build/ output.
- Always ask for clarification rather than making assumptions
- Never fabricate examples, JSON snippets, policy details, or use case descriptions — use only content from the user or existing source files
- Never use markdown in frontmatter
description— breaks SEO - Never edit
build/— Mintlify build output (regenerate withmake buildormake dev) - Always update
src/docs.jsonwhen adding new pages - Use Tabler icons only — not FontAwesome
- Test code examples before including them
| What | Where/How |
|---|---|
| LangSmith docs | src/langsmith/ |
| Open source docs | src/oss/ (LangChain, LangGraph, Deep Agents) |
| Python integrations | src/oss/python/integrations/ |
| JS integrations | src/oss/javascript/integrations/ |
| Reusable snippets | src/snippets/ |
| Images | src/images/ |
| Provider icons | src/images/providers/ |
| Navigation config | src/docs.json |
| Build system | pipeline/ |
| Icon library | Tabler — https://tabler.io/icons |
| Mintlify components | https://mintlify.com/docs/components |
| API reference site | reference.langchain.com — built outside this repo; report reference docs issues |
| Mintlify MCP server | npx add-mcp https://www.mintlify.com/docs/mcp |
This project uses Mintlify for documentation. Key files: src/docs.json (navigation + site config), MDX files with YAML frontmatter for page metadata. When making multi-file docs changes, always update src/docs.json navigation and any redirect mappings. Custom CSS lives in src/style.css.
docs/
├── src/ # All manually authored content
│ ├── docs.json # Mintlify config + navigation
│ ├── index.mdx # Home page
│ ├── style.css # Custom CSS
│ ├── langsmith/ # LangSmith product docs
│ ├── oss/ # Open source docs
│ │ ├── langchain/ # LangChain framework
│ │ ├── langgraph/ # LangGraph framework
│ │ ├── deepagents/ # Deep Agents
│ │ ├── python/ # Python-specific (integrations, migrations, releases)
│ │ ├── javascript/ # TypeScript-specific (integrations, migrations, releases)
│ │ ├── integrations/ # Shared integration content
│ │ ├── concepts/ # Conceptual overviews
│ │ ├── contributing/ # Contribution guides
│ │ └── reference/ # Reference tab entry pages (link to reference.langchain.com)
│ ├── snippets/ # Reusable MDX snippets
│ │ ├── langsmith/ # LangSmith snippets
│ │ ├── oss/ # OSS snippets
│ │ └── code-samples/ # Embedded code samples
│ ├── images/ # Documentation images
│ │ ├── brand/ # Logos, favicons
│ │ └── providers/ # Provider icons (dark/ and light/ variants)
│ └── fonts/ # TWK Lausanne font files
├── pipeline/ # Python build system & preprocessors
├── build/ # Build output — do not edit
├── scripts/ # Helper utilities
└── tests/ # Pipeline testsNavigation is defined in src/docs.json. The site has 4 products (Home, LangSmith, LangSmith Fleet, Open source). When adding pages, find the correct product/tab/group below, then update the matching section in docs.json.
Single page (src/index.mdx). No tabs.
7 tabs, all files in src/langsmith/:
| Tab | Groups |
|---|---|
| Get started | Account administration (Workspace setup, Users & access control, Billing & usage), Tools, Additional resources |
| Observability | Tracing setup, Configuration & troubleshooting, Viewing & managing traces, Automations, Feedback & evaluation, Monitoring & alerting, Data type reference |
| Evaluation | Datasets, Set up evaluations, Analyze experiment results, Annotation & human feedback, Common data types |
| Prompt engineering | Create and update prompts, Tutorials |
| Agent deployment | Agent server, Core capabilities, Develop agents, Deployment guides, Studio, Auth & access control, Server customization |
| Platform setup | Overview, Hybrid, Self-hosted (by cloud provider, Setup guides, Enable features, Configuration, External services, Auth, Observability, Scripts) |
| Reference | LangSmith Deployment (Agent Server API, Control Plane API), Releases |
All LangSmith files are flat in src/langsmith/ (no per-tab subdirectories except fleet/ and images/).
Flat groups (no tabs):
- Get started
- Configure
- Tools and automation
- Advanced
- Additional resources
2 language dropdowns (Python, TypeScript), each with 7 tabs sharing the same names. Groups listed below are for the Python dropdown; TypeScript groups differ in some tabs (noted with *).
| Tab | Directory | Groups |
|---|---|---|
| Deep Agents | src/oss/deepagents/ |
Get started, Deployment, Core capabilities, Frontend, Protocols, Code |
| LangChain | src/oss/langchain/ |
Get started, Core components, Middleware, Frontend, Advanced usage, Agent development, Production |
| LangGraph | src/oss/langgraph/ |
Get started, Capabilities, Production, Frontend, LangGraph APIs |
| Integrations* | src/oss/python/integrations/ or src/oss/javascript/integrations/ |
Popular Providers, Integrations by component (TS: "General integrations, RAG integrations") |
| Learn* | src/oss/ (various) |
Tutorials, Conceptual overviews, Additional resources (TS adds: "LangChain Academy") |
| Reference | src/oss/reference/ |
Reference, Errors, Releases, Policies — short entry pages linking to reference.langchain.com |
| Contribute | src/oss/contributing/ |
Contribution guides, integration authoring |
See Contributing to documentation for setup instructions.
Every MDX file requires:
---
title: Clear, concise page title
description: SEO summary — no markdown allowed (no links, backticks, formatting)
---Integration page descriptions: "Integrate with the ClassName type using LangChain Python."
- Example:
"Integrate with the ChatOpenAI chat model using LangChain Python."
Use :::python or :::js fences for language-specific content. Pages with these fences generate separate Python and JavaScript versions.
:::python
Python-only content here
:::highlighted = True # [!code highlight]
added = True # [!code ++]
removed = True # [!code --]Use @[ClassName] to auto-link to API docs. Defined in pipeline/preprocessors/link_map.py.
Use for: First mention of SDK classes/methods (@[ChatOpenAI], @[StateGraph], @[create_agent])
Don't use for: Repeated mentions, general concepts, or when a descriptive link is clearer
Images: Store in src/images/. Use descriptive filenames and alt text.
Icons: Use Tabler names only (icon="home", icon="brand-github"). For missing icons, use SVG path: icon="/images/providers/name.svg"
Common Tabler names: home (not house), tool (not wrench), player-play (not play), bulb (not lightbulb), alert-triangle (not exclamation-triangle)
| Component | Use for |
|---|---|
<Tabs> / <Tab> |
Python/JS examples |
<Steps> / <Step> |
Numbered instructions |
<Accordion> |
Collapsible content |
<CodeGroup> |
Tabbed code blocks |
<Card> / <CardGroup> |
Navigation/overview links only (not for highlighting points) |
<Note>, <Tip>, <Warning>, <Info> |
Callouts |
When documenting new features, APIs, or behavior that requires a minimum package or CLI version, add a version-added admonition near the first mention of the feature. Use a <Note> callout with a concise requirement, for example: Feature name requires \package>=x.y.z`.`
For language-specific requirements, wrap the note in the relevant :::python or :::js fence. Include separate notes when Python and TypeScript packages have different minimum versions.
Use these classDef colors (from LangChain brand palette) for all mermaid diagrams. See .github/brand-guidelines.md for the full brand color reference.
| Role | classDef value |
|---|---|
| process (blue) | fill:#E5F4FF,stroke:#006DDD,stroke-width:2px,color:#030710 |
| trigger (green) | fill:#F6FFDB,stroke:#6E8900,stroke-width:2px,color:#2E3900 |
| decision (purple) | fill:#FDF3FF,stroke:#7E65AE,stroke-width:2px,color:#504B5F |
| output (plum) | fill:#EBD0F0,stroke:#885270,stroke-width:2px,color:#441E33 |
| alert (peach) | fill:#F8E8E6,stroke:#B27D75,stroke-width:2px,color:#634643 |
| neutral (muted blue) | fill:#F2FAFF,stroke:#40668D,stroke-width:2px,color:#2F4B68 |
When using %%{init}%% theme variables, use: lineColor:'#40668D', primaryColor:'#E5F4FF', primaryTextColor:'#030710', primaryBorderColor:'#006DDD'.
Do not use Tailwind default colors, Material Design colors, or other off-brand palettes in mermaid diagrams.
Follow Google Developer Documentation Style Guide.
Do:
- Match existing conventions in the file you are editing — do not restructure, combine, or split pages unless explicitly asked
- Reference existing pages for style patterns when creating new content
- Be concise — cut filler words and wordy phrases ("to" not "in order to", "because" not "due to the fact that", "can" not "has the ability to")
- Second-person imperative present tense ("Run the following code…")
- Active voice ("The function returns a list" not "A list is returned by the function")
- Sentence-case headings starting with active verb, not gerund ("Add a tool" not "Adding a tool")
- American English spelling
- Oxford commas in lists ("traces, datasets, and experiments")
- Descriptive link text ("View the tracing docs" not "click this link")
- Add cross-links where applicable
- Use
@[ClassName]link map for API references - Use
:::python/:::jsfencing on OSS docs - Language tags on all code blocks (use actual language, not
output) - Sort imports in all code snippets (stdlib, third-party, local)
- Use
.content_blocksinstead of.contentwhen accessing message content in LangChain code snippets - Test code examples and links before publishing
Don't:
- Skip frontmatter
- Use absolute URLs for internal links
- Use markdown in description fields
- Use
/python/or/javascript/in links (resolved by build pipeline) - Use model aliases — use full identifiers (e.g.,
claude-sonnet-4-6) - Use FontAwesome icon names
- Use nested double quotes in component attributes — use
default="['a', 'b']"notdefault='["a", "b"]' - Use contractions ("do not" not "don't", "cannot" not "can't", "it is" not "it's")
- Use first person ("we", "I", "our", "let's") — write in second person or use the product name as subject
- Use future tense ("The function returns X" not "The function will return X")
- Use weasel words or filler (avoid "simply", "easily", "just", "very", "basically", "obviously")
- Use H5 or H6 headings
- Start headings with articles ("Add a tool" not "The tool setup guide")
- Use em dashes — prefer commas, colons, or separate sentences instead. Only use an em dash when no alternative reads naturally
- Add spaces around em dashes — write
word—wordnotword — word(make lint_proseenforces this) - Use excessive bold/italics in body text
- Start bulleted list items with a lowercase letter — always capitalize the first word
- Include "key features" lists
- Use horizontal lines (
---) to separate sections — use headings instead - Apply bold to UI element names unless existing docs already do so
- Misspell product names — use "prebuilt" (not "pre-built"), "Deep Agents" (not "DeepAgents"), "PyPI" (not "PyPi"), "URL" (not "url")
- Skip
make lint_prose— always run it on changed files before committing and fix all violations
Match these patterns, drawn from established pages, when authoring new content:
- Open with definition, then benefit, then task — start a section (and the page) with a one-sentence statement of what the feature is or does, follow with a sentence on what it enables for the reader, then give the procedure or detail. When a page has a sibling variant (for example, a paid or self-hosted version), link it in the opening lines.
- Introduce procedures with a colon lead-in — precede steps with a phrase such as "To add a channel:", then a numbered list (or the
<Steps>component) of imperative steps. State a step's result as a follow-on line when it matters ("The Add User modal displays."). Flag optional steps inline with "(Optional)". For long, multi-stage tasks, use### Step N. <verb>headings. - Use bold-led definition lists for options — for parameters, permissions, secrets, or enumerated types, write
- **Term**: Explanation.and end each explanation with a period. - Link on first mention, and point forward at section ends — link a feature, class, or term on first mention only, not on repeats. Use the pointer phrasing "For more information, see Page". Close substantial pages with a
## See alsolist of related links. - State requirements and constraints up front — put permission, plan tier, or preview requirements before the steps they govern ("Adding MCP servers requires admin permissions."). Write hard constraints as plain facts ("Once an agent identity is set, it cannot be changed.").
Always use the latest generally available (GA) models when referencing LLMs in docstrings and illustrative code snippets. Avoid preview or beta identifiers unless the model has no GA equivalent. Outdated model names signal stale code and confuse users.
Before writing or updating model references, verify current model IDs against the provider's official docs. Do not rely on memorized or cached model names — they go stale quickly.
LangSmith ships features through three release stages: alpha, beta, and generally available (GA). See Release stages for what each stage means.
These are common nouns, not proper nouns. Write them lowercase in prose, including parenthetical and inline status markers:
- Lowercase mid-sentence and in markers: "available in beta", "is in beta", "(beta)", "the feature is in alpha".
- Capitalize only where normal sentence case requires it: the first word of a sentence or heading ("Beta is optional.", "## Beta").
- Keep the literal product UI label capitalized when quoting it as a tag: the
Betatag, frontmattertag: "Beta". The same applies to a stage name standing alone as a table cell's only label. - Spell out "generally available" on first use, then use "GA". GA is always uppercase.
- Do not change code identifiers, package version identifiers (
1.0.0b1), or literal CLI output that contains "Beta".
- Create MDX file with required frontmatter in the correct directory (see navigation map above)
- Update
src/docs.jsonto add the page to the correct product → tab → group - For new groups, include an index page:
"pages": ["group/index", "group/page"]
Add a new LangSmith doc:
- Create
src/langsmith/<name>.mdxwith frontmatter - Find the correct tab and group in
src/docs.jsonundernavigation.products[1](LangSmith) - Add the page path (e.g.,
"langsmith/<name>") to that group'spagesarray
Add a new integration page (Python):
- Create
src/oss/python/integrations/<component>/<provider>.mdx - Add the page to the component's index page (
src/oss/python/integrations/<component>/index.mdx); only editsrc/docs.jsonwhen creating a brand-new component group - Use description format:
"Integrate with the ClassName type using LangChain Python." - If the provider has an overview page at
src/oss/python/integrations/providers/<provider>.mdx, add or update a section there linking to the new page (/oss/integrations/<component>/<provider>)
Add a new integration page (TypeScript):
- Create
src/oss/javascript/integrations/<component>/<provider>.mdx - Add the page to the component's index page (
src/oss/javascript/integrations/<component>/index.mdx); only editsrc/docs.jsonwhen creating a brand-new component group - If the provider has an overview page at
src/oss/javascript/integrations/providers/<provider>.mdx, add or update a section there linking to the new page (/oss/integrations/<component>/<provider>)
Add a reusable snippet:
- Create
src/snippets/<product>/<name>.mdx - Reference with
<Snippet file="<product>/<name>.mdx" />
When investigating a bug or unexpected behavior, always start by reading the relevant code and logs before forming a hypothesis. Do not assume something is working or ask the user to confirm — verify it yourself first.
make broken-links runs mint broken-links then filters known false positives (OpenAPI-generated pages: /langsmith/agent-server-api/, /api-reference/, ../langchain/agents). Output format:
found N broken links in M files
some-file.mdx ← file header (always printed)
⎿ /path/to/broken-target ← indented = actual broken link
another-file.mdx ← no indented lines = all its links were filtered out (false positive)Shortcut: Skip straight to ⎿ lines — those are the only real failures. File headers without ⎿ lines beneath them are OpenAPI pages that exist at deploy time but not locally.
Common cause: Page renamed/deleted but link and/or src/docs.json nav entry still references old name. Fix both the link in the MDX file AND the corresponding entry in docs.json.
To run locally: make broken-links
The model-by-eval-category table on /oss/python/deepagents/models is generated by scripts/refresh_deepagents_category_matrix.py. The script pulls category_scores from the latest successful Evals - GHA runs in langchain-ai/deepagents and writes the table to src/snippets/deepagents-eval-category-matrix.mdx (imported by src/oss/deepagents/models.mdx). Run it whenever new eval results land and the published table is out of date.
Setup and run:
export GITHUB_TOKEN="$(gh auth token)" # needs Actions: Read on langchain-ai/deepagents; SSO-authorize for langchain-ai
uv run python scripts/refresh_deepagents_category_matrix.py --writeNotes:
- For the latest
(model, category)value per cell, the script walks runs newest-first and keeps the first hit. Models with fewer than four of the six fixed categories filled are dropped (MIN_FILLED_CATEGORIES). - Only models explicitly listed in
INCLUDED_MODELS(in the script) appear in the table. To surface a new model, add itsprovider:modelkey there. - The fixed columns are defined by
FIXED_CATEGORY_COLUMNSin the script (unit_testis intentionally excluded). - Without
--write, the script prints the table to stdout for inspection. - After regenerating, commit only
src/snippets/deepagents-eval-category-matrix.mdx. Do not edit that snippet by hand.
Always run make lint_prose (Vale) before handing off or committing doc changes. CI blocks on it. Common offenders: em-dashes with surrounding spaces (— → —, enforced by LangChain.DashesSpaces), terminology, style.
Scope to changed files for speed: make lint_prose FILES="src/path/to/file.mdx" (or pass space-separated paths). Run with no FILES arg to lint all of src/.
Also run make broken-links when adding or renaming links, pages, or nav entries.
When extracting data from PRs or changelogs, use the "Release Note:" section in PR bodies, not PR titles. Always verify the data source format before processing.
- Explain the "why" of changes
- Highlight areas needing careful review
- Disclose AI agent involvement in description