fix(docs): typos (#1167)

Author: dqbd

CONTRIBUTING.md

@@ -257,7 +257,7 @@ Some key concepts:
 - Each node writes to (one or more) channels. This defines where the final value after a node is executed is stored, because nodes don't store their own value.
 - More on channels below.
 
-To form an intuition around Pregel graphs, lets look at the example tests.
+To form an intuition around Pregel graphs, let's look at the example tests.
 
 In the example below, the pregel graph is defined to start at `inputChannelName` and end at `outputChannelName`. The graph has a single node called `nodeOne` that transforms the input value by adding one to it. When the graph is invoked with an input value of `2`:
 
@@ -352,17 +352,17 @@ it("should handle checkpoints correctly", async () => {
 });
 ```
 
-Those are some of the fundamentals of how a Pregel graph works. To get a deeper understanding of how Pregel works, you can check out it's expected behavior in `pregel.test.ts`.
+Those are some of the fundamentals of how a Pregel graph works. To get a deeper understanding of how Pregel works, you can check out its expected behavior in `pregel.test.ts`.
 
 #### Channels
 
 Some concepts about channels:
 
 1. Channels are the way nodes communicate with one another in Pregel. If it were not for channels, nodes would have no way of storing values or denoting dependencies on other nodes.
-2. At it's core, every channel does a couple things:
+2. At its core, every channel does a couple things:
 
 - It stores a current value.
-- It implements a way to `update` it's current value based on the expected parameter for the update function.
+- It implements a way to `update` its current value based on the expected parameter for the update function.
 - It implements a way to `checkpoint` or "snapshot" the current state of the channel. This enables persistence across a graph.
 - It implements a way to `empty` or "restore" a channel from a checkpoint/snapshot. This enables us to create a new channel from a checkpoint variable stored in a database.
 

docs/docs/concepts/application_structure.md

@@ -31,7 +31,7 @@ Below are examples of directory structures for Python and JavaScript application
     ├── 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
+    │   │   ├── 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
@@ -47,7 +47,7 @@ Below are examples of directory structures for Python and JavaScript application
     │   ├── utils # utilities for your graph
     │   │   ├── __init__.py
     │   │   ├── tools.py # tools for your graph
-    │   │   ├── nodes.py # node functions for you graph
+    │   │   ├── nodes.py # node functions for your graph
     │   │   └── state.py # state definition of your graph
     │   ├── requirements.txt # package dependencies
     │   ├── __init__.py
@@ -64,7 +64,7 @@ Below are examples of directory structures for Python and JavaScript application
     │   ├── utils # utilities for your graph
     │   │   ├── __init__.py
     │   │   ├── tools.py # tools for your graph
-    │   │   ├── nodes.py # node functions for you graph
+    │   │   ├── nodes.py # node functions for your graph
     │   │   └── state.py # state definition of your graph
     │   ├── __init__.py
     │   └── agent.py # code for constructing your graph

docs/docs/concepts/assistants.md

@@ -4,7 +4,7 @@
 
     - [LangGraph Server](./langgraph_server.md)
 
-When building agents, it is fairly 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 agents. Assistants offer an easy way to make and save these types of changes to agent configuration. This can have at least two use-cases:
+When building agents, it is fairly 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 agents. Assistants offer an easy way to make and save these types of changes to agent configuration. This can have at least two use cases:
 
 - Assistants give developers a quick and easy way to modify and version agents for experimentation.
 - Assistants can be modified via LangGraph Studio, offering a no-code way to configure agents (e.g., for business users).

docs/docs/concepts/auth.md

@@ -277,8 +277,8 @@ Notice that we are mixing global and resource-specific handlers in the above exa
 
 Authorization handlers can return `None`, a boolean, or a filter object.
 
-- `null`, `void` and `true` mean "authorize access to all underling resources"
-- `False` means "deny access to all underling resources (raises a 403 error)"
+- `null`, `void` and `true` mean "authorize access to all underlying resources"
+- `False` means "deny access to all underlying resources (raises a 403 error)"
 - A metadata filter object will restrict access to resources. Supports exact matches and operators.
 
 ???+ info "Filter object syntax"

docs/docs/concepts/high_level.md

@@ -6,7 +6,7 @@ However, we often want LLM systems that can pick their own control flow! This is
 
 - Using an LLM to route between two potential paths
 - Using an LLM to decide which of many tools to call
-- Using an LLM to decide whether the generated answer is sufficient or more work is need
+- Using an LLM to decide whether the generated answer is sufficient or more work is needed
 
 There are many different types of [agent architectures](https://blog.langchain.dev/what-is-a-cognitive-architecture/) to consider, which given an LLM varying levels of control. On one extreme, a router allows an LLM to select a single step from a specified set of options and, on the other extreme, a fully autonomous long-running agent may have complete freedom to select any sequence of steps that it wants for a given problem. 
 
@@ -15,13 +15,13 @@ There are many different types of [agent architectures](https://blog.langchain.d
 Several concepts are utilized in many agent architectures:
 
 - [Tool calling](agentic_concepts.md#tool-calling): this is often how LLMs make decisions
-- Action taking: often times, the LLMs' outputs are used as the input to an action
+- Action taking: oftentimes, the LLMs' outputs are used as the input to an action
 - [Memory](agentic_concepts.md#memory): reliable systems need to have knowledge of things that occurred
 - [Planning](agentic_concepts.md#planning): planning steps (either explicit or implicit) are useful for ensuring that the LLM, when making decisions, makes them in the highest fidelity way.
 
 ## Challenges
 
-In practice, there is often a trade-off between control and reliability. As we give LLMs more control, the application often become less reliable. This can be due to factors such as LLM non-determinism and / or errors in selecting tools (or steps) that the agent uses (takes).
+In practice, there is often a trade-off between control and reliability. As we give LLMs more control, the application often becomes less reliable. This can be due to factors such as LLM non-determinism and / or errors in selecting tools (or steps) that the agent uses (takes).
 
 ![Agent Challenge](img/challenge.png)
 

docs/docs/concepts/human_in_the_loop.md

@@ -148,7 +148,7 @@ To use `interrupt` in your graph, you need to:
 
 There are typically three different **actions** that you can do with a human-in-the-loop workflow:
 
-1. **Approve or Reject**: Pause the graph before a critical step, such as an API call, to review and approve the action. If the action is rejected, you can prevent the graph from executing the step, and potentially take an alternative action. This pattern often involve **routing** the graph based on the human's input.
+1. **Approve or Reject**: Pause the graph before a critical step, such as an API call, to review and approve the action. If the action is rejected, you can prevent the graph from executing the step, and potentially take an alternative action. This pattern often involves **routing** the graph based on the human's input.
 
 2. **Edit Graph State**: Pause the graph to review and edit the graph state. This is useful for correcting mistakes or updating the state with additional information. This pattern often involves **updating** the state with the human's input.
 
@@ -455,7 +455,7 @@ By leveraging `Command`, you can resume graph execution, handle user inputs, and
 
 ## Using with `invoke`
 
-When you use `stream` to run the graph, you will receive an `Interrupt` event that let you know the `interrupt` was triggered.
+When you use `stream` to run the graph, you will receive an `Interrupt` event that lets you know the `interrupt` was triggered.
 
 `invoke` does not return the interrupt information. To access this information, you must use the [getState](/langgraphjs/reference/classes/langgraph.CompiledStateGraph.html#getState) method to retrieve the graph state after calling `invoke`.
 

docs/docs/concepts/langgraph_server.md

@@ -119,9 +119,9 @@ The LangGraph Cloud API provides several endpoints for creating and managing cro
 
 Webhooks enable event-driven communication from your LangGraph Cloud application to external services. For example, you may want to issue an update to a separate service once an API call to LangGraph Cloud has finished running.
 
-Many LangGraph Cloud endpoints accept a `webhook` parameter. If this parameter is specified by a an endpoint that can accept POST requests, LangGraph Cloud will send a request at the completion of a run.
+Many LangGraph Cloud endpoints accept a `webhook` parameter. If this parameter is specified by an endpoint that can accept POST requests, LangGraph Cloud will send a request at the completion of a run.
 
-See the corresponding [how-to guide](/langgraphjs/cloud/how-tos/webhooks.md) for more detail.
+See the corresponding [how-to guide](/langgraphjs/cloud/how-tos/webhooks.md) for more details.
 
 ## Related
 

docs/docs/concepts/low_level.md

@@ -195,7 +195,7 @@ In addition to keeping track of message IDs, the `messagesStateReducer` function
 }
 ```
 
-Below is an example of a graph state annotation that uses `messagesStateReducer` as it's reducer function.
+Below is an example of a graph state annotation that uses `messagesStateReducer` as its reducer function.
 
 ```ts
 import type { BaseMessage } from "@langchain/core/messages";
@@ -350,7 +350,7 @@ If you want to **optionally** route to 1 or more edges (or optionally terminate)
 graph.addConditionalEdges("nodeA", routingFunction);
 ```
 
-Similar to nodes, the `routingFunction` accept the current `state` of the graph and return a value.
+Similar to nodes, the `routingFunction` accepts the current `state` of the graph and return a value.
 
 By default, the return value `routingFunction` is used as the name of the node (or an array of nodes) to send the state to next. All those nodes will be run in parallel as a part of the next superstep.
 
@@ -403,7 +403,7 @@ const graph = new StateGraph(...)
 
 ## `Send`
 
-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 of example of this is with `map-reduce` design patterns. In this design pattern, a first node may generate an array 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).
+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 an array 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`](/langgraphjs/reference/classes/langgraph.Send.html) 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.
 
@@ -554,7 +554,7 @@ LangGraph can easily handle migrations of graph definitions (nodes, edges, and s
 
 ## Configuration
 
-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.
+When creating a graph, you can also mark that certain parts of the graph are configurable. This is commonly done to enable easy switching between models or system prompts. This allows you to create a single "cognitive architecture" (the graph) but have multiple different instances of it.
 
 You can then pass this configuration into the graph using the `configurable` config field.
 

docs/docs/concepts/memory.md

@@ -205,7 +205,7 @@ trimMessages(messages, {
 
 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."
 
-LangGraph stores long-term memories as JSON documents in a [store](persistence.md#memory-store) ([reference doc](https://langchain-ai.github.io/langgraphjs/reference/classes/checkpoint.BaseStore.html)). 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.
+LangGraph stores long-term memories as JSON documents in a [store](persistence.md#memory-store) ([reference doc](https://langchain-ai.github.io/langgraphjs/reference/classes/checkpoint.BaseStore.html)). 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 make 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.
 
 ```typescript
 import { InMemoryStore } from "@langchain/langgraph";

docs/docs/concepts/persistence.md

@@ -1,6 +1,6 @@
 # Persistence
 
-LangGraph has a built-in persistence layer, implemented through checkpointers. When you compile graph with a checkpointer, the checkpointer saves a `checkpoint` of the graph state at every super-step. Those checkpoints are saved to a `thread`, which can be accessed after graph execution. Because `threads` allow access to graph's state after execution, several powerful capabilities including human-in-the-loop, memory, time travel, and fault-tolerance are all possible. See [this how-to guide](/langgraphjs/how-tos/persistence) for an end-to-end example on how to add and use checkpointers with your graph. Below, we'll discuss each of these concepts in more detail. 
+LangGraph has a built-in persistence layer, implemented through checkpointers. When you compile graph with a checkpointer, the checkpointer saves a `checkpoint` of the graph state at every super-step. Those checkpoints are saved to a `thread`, which can be accessed after graph execution. Because `threads` allow access to graph's state after execution, several powerful capabilities including human-in-the-loop, memory, time travel, and fault-tolerance are all possible. See [this how-to guide](/langgraphjs/how-tos/persistence) for an end-to-end example of how to add and use checkpointers with your graph. Below, we'll discuss each of these concepts in more detail. 
 
 ![Checkpoints](img/persistence/checkpoints.jpg)
 
@@ -221,7 +221,7 @@ import { InMemoryStore } from "@langchain/langgraph";
 const inMemoryStore = new InMemoryStore();
 ```
 
-Memories are namespaced by a `tuple`, which in this specific example will be `[<user_id>, "memories"]`. The namespace can be any length and represent anything, does not have be user specific.
+Memories are namespaced by a `tuple`, which in this specific example will be `[<user_id>, "memories"]`. The namespace can be any length and represent anything, does not have to be user specific.
 
 ```ts
 const userId = "1";
@@ -263,7 +263,7 @@ The attributes a retrieved memory has are:
 - `created_at`: Timestamp for when this memory was created
 - `updated_at`: Timestamp for when this memory was updated
 
-With this all in place, we use the `inMemoryStore` in LangGraph. The `inMemoryStore` works hand-in-hand with the checkpointer: the checkpointer saves state to threads, as discussed above, and the the `inMemoryStore` allows us to store arbitrary information for access *across* threads. We compile the graph with both the checkpointer and the `inMemoryStore` as follows. 
+With this all in place, we use the `inMemoryStore` in LangGraph. The `inMemoryStore` works hand-in-hand with the checkpointer: the checkpointer saves state to threads, as discussed above, and the `inMemoryStore` allows us to store arbitrary information for access *across* threads. We compile the graph with both the checkpointer and the `inMemoryStore` as follows. 
 
 ```ts
 import { MemorySaver } from "@langchain/langgraph";
@@ -329,7 +329,7 @@ const updateMemory = async (
 };
 ```
 
-As we showed above, we can also access the store in any node and use `search` to get memories. Recall the the memories are returned as a list of objects that can be converted to a dictionary.
+As we showed above, we can also access the store in any node and use `search` to get memories. Recall that the memories are returned as a list of objects that can be converted to a dictionary.
 
 ```ts
 const memories = inMemoryStore.search(namespaceForMemory);
@@ -417,7 +417,7 @@ First, checkpointers facilitate [human-in-the-loop workflows](/langgraphjs/conce
 
 ### Memory
 
-Second, checkpointers allow for ["memory"](/langgraphjs/concepts/agentic_concepts#memory) between interactions.  In the case of repeated human interactions (like conversations) any follow up messages can be sent to that thread, which will retain its memory of previous ones. See [this how-to guide](/langgraphjs/how-tos/manage-conversation-history) for an end-to-end example on how to add and manage conversation memory using checkpointers.
+Second, checkpointers allow for ["memory"](/langgraphjs/concepts/agentic_concepts#memory) between interactions.  In the case of repeated human interactions (like conversations) any follow up messages can be sent to that thread, which will retain its memory of previous ones. See [this how-to guide](/langgraphjs/how-tos/manage-conversation-history) for an end-to-end example of how to add and manage conversation memory using checkpointers.
 
 ### Time Travel
 

docs/docs/how-tos/auth/custom_auth.md

@@ -70,7 +70,7 @@ In your `langgraph.json`, add the path to your auth file:
 
 ## 3. Connect from the client
 
-Once you've set up authentication in your server, requests must include the the required authorization information based on your chosen scheme.
+Once you've set up authentication in your server, requests must include the required authorization information based on your chosen scheme.
 Assuming you are using JWT token authentication, you could access your deployments using any of the following methods:
 
 === "Python Client"