LangGraph4j
Build stateful, cyclic, multi-agent LLM workflows inside Java applications.
Workflow permissions are narrowed to contents:read, application nodes explicitly configure tools and external calls, and the state flow, conditional edges, checkpoints, and persistence backends are described; this supports moderate scores for least privilege, data-flow transparency, and rollback. Secrets are referenced through environment variables and a Gitleaks step exists, but baseline CI is manual-only, no dependency vulnerability scan, commit pinning, or SBOM is shown, and an example enables model request/response logging; sensitive-data and dependency-security handling are therefore not complete. No general human-confirmation mechanism is demonstrated. Tools may create external effects, yet approval, idempotency, and compensation controls are not shown. The README, MIT notice, and acknowledgment of inspiration provide attribution, but maintainer and publisher identities are not independently verified.
The README is broadly consistent about core abstractions, execution methods, and Java baselines, and identifies Maven Central, Ollama, LangChain4j, Spring AI, and multiple persistence integrations. It nevertheless labels an example as a development snapshot while using the stable version, and availability of models, databases, and frameworks remains deployment-dependent. Compilation reportedly validates graph structure and some failures surface through GraphStateException or CompletableFuture, but the material does not systematically document runtime error classes, retry limits, timeouts, or user-facing diagnostics, so failure messaging is thin.
The documentation gives clear entry points for beginners, conditional routing, persistence, framework-integrated agents, and visual debugging. Synchronous and asynchronous nodes, streaming, subgraphs, multiple LLM frameworks, and multiple checkpoint stores provide strong environment fit. Conditional edges and conditional entry points let developers specify routing precisely. The deduction is for incomplete capability boundaries: unsupported behavior, production safety limits, and a comprehensive integration compatibility matrix are not documented.
Concepts, the pattern matrix, project structure, installation, first example, execution methods, and integration navigation are well organized. Maven/BOM instructions, Java requirements, and stable-versus-snapshot guidance are concrete, while examples and how-to references are extensive. The full MIT text agrees with the license metadata and earns full credit. Deductions apply because no dedicated FAQ, comprehensive known-limitations list, API deprecation/migration policy, or full changelog is shown; the README lists only the latest release. SECURITY.md supplies supported versions, reporting routes, and a response target, but retains template-like wording and does not clearly identify the responsible owner or direct contact.
Shared state, cyclic graphs, conditional routing, checkpoints, streaming, visualization, and integrations with two major Java AI frameworks form a directly composable development framework. The introductory example and concrete APIs make its outputs highly usable and offer clear marginal value over hand-built orchestration. Cost-benefit is not fully addressed because the sources do not quantify runtime overhead, model/token cost, persistence cost, concurrency tradeoffs, or Studio deployment burden.
Most claims refer to concrete classes, methods, modules, configurations, examples, or stated test locations. The README, SECURITY.md, workflows, and YAML files partially corroborate Java requirements, integrations, secret injection, and maintenance paths. Deductions apply because implementation sources, the dependency tree, actual test results, and full release records are absent from the supplied evidence, while CI is not automatically triggered. Promotional descriptions such as seamless integration or excellent debugging are not consistently separated from verifiable facts.
- The framework does not demonstrate uniform user confirmation, tool permission policy, or compensation for external side effects; production applications should add approval, scoping, idempotency, and audit controls at node and tool boundaries.
- Model request/response logging may capture prompts, personal data, tool arguments, or credentials; redact data and restrict retention and access before enabling it.
- Environment-variable injection for secrets such as WEATHER_API_KEY is appropriate, but rotation, runtime isolation, and leak-response procedures are not shown.
- Baseline CI and documentation deployment are manual-only, and no dependency vulnerability scan or immutable action commit pinning is shown; independently audit Maven dependencies and the GitHub Actions supply chain before adoption.
- Checkpoints may persist complete agent state and conversations; database-backed savers require application-defined encryption, tenant isolation, deletion, and retention policies.
- The static evidence does not establish that examples, tests, release claims, or runtime behavior were executed at this revision.
What does this agent do, and when should you use it?
LangGraph4j is a Java library for stateful, multi-agent LLM applications, with documented integration paths for LangChain4j and Spring AI. Applications describe execution with StateGraph, AgentState, nodes, and edges, then compile that definition into an immutable CompiledGraph. The runtime supports conditional routing, cycles, asynchronous nodes, streamed state updates, parallel branches, and nested subgraphs. Checkpoints make executions inspectable and resumable, with saver modules for MySQL, PostgreSQL, Redis, SQLite, Oracle, DynamoDB, CockroachDB, and Hazelcast. Its primary deployment boundary is a library embedded in a Java application, while Studio supplies an embeddable web interface for running and debugging graphs.
A developer defines an AgentState schema with Map<String, Channel<?>> and reducers, then registers NodeAction<S> or AsyncNodeAction<S> implementations in a StateGraph. Each node receives the current state, may call an LLM, execute a tool, or run custom Java code, and returns a Map<String, Object> of updates; channel reducers control how those updates are merged. Normal edges select a fixed successor, while addConditionalEdges(...) and addConditionalEntryPoint(...) choose routes from the current state, enabling branches and cycles. compile() validates the graph and produces a CompiledGraph; stream(...) yields state after each completed node, while invoke(...) returns the final state through a CompletableFuture after reaching END. CheckpointSaver records intermediate state for inspection and resumption, and PlantUML, Mermaid, and Studio expose the graph structure or execution visually.
- A Spring Boot or Spring AI team needs to coordinate model calls, tool execution, and conditional routing in a cyclic Java agent workflow.
- A LangChain4j developer wants a repository-provided AgentExecutor reference for implementing a ReAct-style agent.
- A backend team operates long-running workflows and needs to checkpoint execution in PostgreSQL, MySQL, Redis, or another supplied saver backend.
- A conversational application needs separate execution threads and checkpoint histories for multiple user sessions.
- An engineer debugging complex agent behavior wants streamed node-by-node state, checkpoint replay, and Mermaid, PlantUML, or Studio visualization.
- A platform team wants reusable subgraphs inside larger workflows and parallel execution for independent branches.
What are this agent's strengths and limitations?
- Cycles and conditional edges are first-class execution primitives, covering retries, clarification loops, and tool-routing patterns that a conventional DAG cannot express directly.
- The project documents both LangChain4j and Spring AI integration paths while allowing nodes to contain arbitrary Java logic.
- Checkpointing extends beyond memory to dedicated MySQL, PostgreSQL, Redis, SQLite, Oracle, DynamoDB, CockroachDB, and Hazelcast saver modules.
- The runtime combines CompletableFuture-based asynchronous work, streaming, parallel branches, subgraphs, and per-thread checkpoint histories.
- PlantUML, Mermaid, and an embeddable Studio provide several concrete ways to inspect graph structure and execution.
- Stable 1.8.x modules require Java 17+, and the notebook tooling currently referenced under how-tos/ requires Java 22.
- This is an embedded Java library rather than a ready-hosted agent service; adopters must supply the model, tools, state design, application boundary, and deployment.
- Durable checkpointing adds a storage dependency and operational work; MemorySaver alone is not durable production storage.
- Moving between LangChain4j and Spring AI requires integration changes because their model builders and tool annotations differ.
- The supplied material does not establish native support for ChatGPT, Codex, Claude products, or direct OpenAI and Anthropic API adapters.
How do you install or deploy this agent?
Use Java 17 or later; the notebook tooling currently described under how-tos/ requires Java 22. For Maven, set version 1.8.24 and import the BOM:
<properties>
<langgraph4j.version>1.8.24</langgraph4j.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.bsc.langgraph4j</groupId>
<artifactId>langgraph4j-bom</artifactId>
<version>${langgraph4j.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.bsc.langgraph4j</groupId>
<artifactId>langgraph4j-core</artifactId>
</dependency>
</dependencies>
Add the relevant LangChain4j, Spring AI, Studio, or CheckpointSaver modules as needed. The core library documents no mandatory API credential; credentials and network configuration depend on the chosen model or storage provider. The supplied integration examples use a local Ollama server at http://localhost:11434 with qwen2.5:7b.
How do you use this agent?
For a first run, create a state class extending AgentState and configure a messages channel with Channels.appender(ArrayList::new). Implement GreeterNode and ResponderNode as NodeAction classes, construct new StateGraph<>(SimpleState.SCHEMA, SimpleState::new), register them with addNode(...), and connect START -> greeter -> responder -> END. Call stateGraph.compile(), then iterate over compiledGraph.stream(Map.of(SimpleState.MESSAGES_KEY, "Let's, begin!")); every yielded item represents state after a node completes. Use invoke(initialState, RunnableConfig) when only the final state is needed. For resumable execution, provide a saver through CompileConfig.builder().checkpointSaver(...). A real model-backed agent additionally requires a LangChain4j or Spring AI chatModel, registered tools, and a compiled AgentExecutor.
How does this agent compare with similar options?
LangGraph4j is explicitly inspired by the Python LangGraph project but targets Java and provides integration modules for LangChain4j and Spring AI. Compared with a conventional DAG-only workflow engine, it permits control flow to revisit earlier nodes, which fits agent retries, clarification steps, and repeated tool use.