Javascript Agents

Purpose and Scope

This page explains the JavaScript agent model from the perspective of a developer working in the LangChain repository and documentation ecosystem. In the JavaScript docs, an agent is described as a model calling tools in a loop until the task is complete. The harness around that loop supplies the model, prompt, tools, and middleware needed at the right time. The main authoring entry point is createAgent, which lets an application compose a model identifier or model instance with tools and optional instructions such as a system prompt.

The requested repository files for this page do not implement the JavaScript agent runtime. Instead, they show how this Python monorepo keeps JavaScript source-code ingestion available through langchain_classic compatibility modules. That distinction matters: JavaScript agents are authored in the LangChain.js package and documented in the JavaScript docs, while this repository still contains Python-side support for parsing JavaScript code as documents. Those parsing shims are useful when an agent or retrieval workflow needs to inspect JavaScript projects, index source files, or migrate older imports.

Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py, libs/langchain/langchain_classic/document_loaders/parsers/language/code_segmenter.py

Relevant Source Files

• libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py - Provides the langchain_classic compatibility export for JavaScriptSegmenter, dynamically resolving the implementation from langchain_community.document_loaders.parsers.language.javascript.
• libs/langchain/langchain_classic/document_loaders/parsers/language/code_segmenter.py - Provides the matching compatibility export for the generic CodeSegmenter, dynamically resolving the implementation from langchain_community.document_loaders.parsers.language.code_segmenter.

These files are small, but they define an important boundary in the monorepo. Both modules use create_importer and a DEPRECATED_LOOKUP table to redirect old langchain_classic imports to langchain_community implementations. Each module exposes a narrow public surface through __all__: JavaScriptSegmenter for JavaScript-specific segmentation and CodeSegmenter for generic code segmentation. That design keeps legacy import paths working while centralizing the actual parser implementations in the community package.

Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py, libs/langchain/langchain_classic/document_loaders/parsers/language/code_segmenter.py

Core Primitives

A JavaScript LangChain agent starts with three core primitives: a model, tools, and a harness. The model is the language model that decides what to say or what tool to call next. Tools are typed capabilities that the model can invoke, such as search, database access, or application actions. The harness is the runtime wrapper that manages the loop, provides the right context, applies the prompt, exposes tools, and runs middleware that can modify behavior before or after model and tool calls.

The JavaScript docs present createAgent as the configurable harness. At the simplest level, you pass a model and a list of tools. A model can be selected with a provider-qualified identifier such as provider:model, or supplied as an initialized model object when the application needs explicit provider setup. A tool is commonly defined with a name, description, and schema so the model can decide when and how to call it. A system prompt shapes the agent’s behavior, while middleware handles more advanced runtime customization.

import { createAgent, tool } from "langchain";
import * as z from "zod";
 
const search = tool(({ query }) => `Results for: ${query}`, {
  name: "search",
  description: "Search for information",
  schema: z.object({ query: z.string() }),
});
 
const agent = createAgent({
  model: "google-genai:gemini-3.5-flash",
  tools: [search],
});

System-to-Code Mapping

For application developers, the JavaScript agent loop is the primary abstraction: model decisions, tool calls, returned tool results, and final answers are coordinated by the harness. For repository maintainers reading these Python files, the relevant code path is different but complementary. The parser modules support workflows where JavaScript source is loaded into LangChain as documents, split into meaningful code segments, and then used by retrieval or analysis systems that may be driven by agents.

javascript.py maps the public name JavaScriptSegmenter to a deprecated lookup target in langchain_community. Its __getattr__ function delegates unresolved attribute access to _import_attribute, which is created by create_importer. code_segmenter.py uses the same pattern for CodeSegmenter. Together, they show that language-specific code parsing is treated as an integration-style capability rather than a core agent primitive. The agent may use parsed code as context, but the segmenter itself is a document-processing component.

Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py, libs/langchain/langchain_classic/document_loaders/parsers/language/code_segmenter.py

Execution Flow

A typical JavaScript agent execution begins when the application invokes the agent with a user request. The harness sends the current messages and system instructions to the model. If the model can answer directly, it returns a final response. If it needs external information or side effects, it emits a tool call. The harness validates the call against the tool schema, executes the tool, appends the tool result to the conversation, and calls the model again. This repeats until the task is complete.

When the agent needs repository knowledge, a surrounding retrieval pipeline may load source files first. In a JavaScript codebase, a loader can parse JavaScript files into documents, segment code into chunks, embed or index those chunks, and later retrieve the most relevant snippets for an agent. The two requested modules sit in that preparatory path. They do not run the agent loop; they preserve import compatibility for code segmenters that help prepare JavaScript source context for downstream LLM and agent workflows.

Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py, libs/langchain/langchain_classic/document_loaders/parsers/language/code_segmenter.py

API Components

The source-level public contract here is intentionally compact. libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py exports JavaScriptSegmenter. libs/langchain/langchain_classic/document_loaders/parsers/language/code_segmenter.py exports CodeSegmenter. Both modules declare their exported names in __all__, use TYPE_CHECKING imports so type checkers can see the target classes, and defer runtime resolution through __getattr__. The lookup table names are explicit, making the legacy-to-community package mapping discoverable and consistent.

That pattern is important for migration. Older code may still import from langchain_classic.document_loaders.parsers.language.javascript or langchain_classic.document_loaders.parsers.language.code_segmenter. Rather than duplicating implementations, the compatibility module resolves the attribute dynamically and lets the shared importer handle deprecation behavior. In practice, developers should treat these paths as compatibility surfaces and prefer the current package location when writing new code, while recognizing that existing retrieval or code-analysis agents may still rely on the older imports.

# Compatibility import surface shown by the requested source files
from langchain_classic.document_loaders.parsers.language.javascript import JavaScriptSegmenter
from langchain_classic.document_loaders.parsers.language.code_segmenter import CodeSegmenter

Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py, libs/langchain/langchain_classic/document_loaders/parsers/language/code_segmenter.py

Practical Guidance and Next Steps

Use the JavaScript agent docs when you are authoring a LangChain.js application: start with createAgent, choose a model, define tools with clear schemas, and add a system prompt or middleware only when the simple harness is no longer enough. Think of the agent as the decision-making loop and the harness as the engineering boundary where context, capabilities, safety checks, and runtime behavior are attached. That framing helps keep agent code understandable as applications grow from a single tool to many tools and middleware layers.

Use the repository files on this page when your agentic application needs JavaScript source context and you are maintaining Python-side LangChain code that still references langchain_classic document loaders. The segmenters belong to the ingestion side of the system: they prepare code for retrieval, indexing, summarization, or analysis. After this page, read the Tools page for tool definitions, the Runnables and LCEL page for composable execution, and the Documents and Loaders page for the broader ingestion pipeline that feeds context into agents.