DEV Community: bsorrentino

LangGraph4j 1.9.0: What's new and the roadmap

bsorrentino — Sat, 19 Sep 2026 11:51:59 +0000

LangGraph4j 1.9.0 is out!

LangGraph4j 1.9.0 is out! With the 1.8.x release stream now in LTS, development moves forward on 1.9 with improvements to streaming, persistence, and the infrastructure for building agents in Java.

This release is an important step toward workflows that are easier to follow while they run and easier to inspect after they finish. A node can now report progress output before returning its result, checkpoint savers have a richer execution lifecycle, and Studio gets an UI refresh.

Let's look at what changes for an application built on 1.8.x, with particular attention to custom output from nodes and checkpoint management. The official migration guide provides details API reference for the changes discussed here.

Emit custom output while a node is running

Imagine a node that retrieves documents, processes them, and prepares a response. The caller may want to show progress throughout that work. Waiting for the final node output gives the user minimal information about what is happening in the meantime.

In 1.9, a node action can emit its own typed NodeOutput values through the active graph execution stream (graph.stream(...)). They arrive alongside the usual START, node, and END outputs, before the node has necessarily finished.

The mechanism is straightforward:

Define a subclass of NodeOutput carrying the information you want to expose.
Obtain a dispatcher from the node's RunnableConfig.
Dispatch custom outputs during execution.
Handle those types when consuming the graph stream.

Here is a small example.

public final class ProgressOutput extends NodeOutput<AgentState> {
    private final String message;

    public ProgressOutput(String node, AgentState state, String message) {
        super(node, state);
        this.message = message;
    }

    public String message() {
        return message;
    }
}

Inside the node, the dispatcher publishes a message while the returned map still provides the normal state update:

AsyncNodeActionWithConfig<AgentState> process = (state, config) -> {
    var dispatcher = config.<AgentState, ProgressOutput>customDispatcher();

    dispatcher.dispatchAsync(
        new ProgressOutput(config.nodeId(), state, "Processing documents"));

    // Perform the node's work here.

    return completedFuture(Map.of("result", "Documents processed"));
};

Once this action is registered in a compiled graph, the caller can recognize its progress messages:


graph.stream(GraphInput.noArgs(), RunnableConfig.empty()).forEachAsync( output -> {
        if (output instanceof ProgressOutput progress) {
            System.out.println(progress.message());
        } else {
            System.out.println("Graph step: " + output.node());
        }
    });

This gives us a useful channel for progress notifications, intermediate results, and application-specific events. Dispatching a custom output does not update graph state. If a value must influence routing, be available to later nodes, or become part of a persisted result, include it in the node's returned state update.

There are two dispatch options. dispatchSync(...) waits until the stream accepts the value and can throw InterruptedException; dispatchAsync(...) submits without waiting. The dispatcher is available during node execution in an active graph stream, including the supported hook context. Keep its use within that lifecycle: accessing it outside has an unpredicable result.

Custom events are intended for graph.stream(...) consumers; they do not change the result returned by graph.invoke(...). See the custom-output tutorial for the complete contract and a hook-based example.

The streaming engine behind it

This capability comes with a refactoring of the internal streaming engine around AsyncGeneratorFlow from async-generator 5.0 project.

Ordinary iteration over stream() remains source-compatible. Applications extending directly streaming generators, supplying a BlockingQueue, or depending on AsyncGenerator.WithResult need migration work.

Note: 👀

This refactoring is a groundwork for Reactor Flow support in a future LangGraph4j 2.0; that support is a future direction.

Checkpoint Savers: A richer execution lifecycle

Checkpoint persistence is central to long-running agents and Human-in-the-Loop workflows. In 1.9, the changes cover what happens when execution finishes, how released runs can be retrieved, how subgraph savers participate, and how interruptions and failures are recorded. These are the checkpoint changes I would review first when upgrading an existing application.

Completed runs release their thread by default

With a checkpoint saver configured, a graph that completes normally now releases its active thread automatically. Depending on the saver, release archives or tags its checkpoints and removes the active checkpoint set.

This matters if your application completes a graph, updates the same active thread's state, and executes it again. To retain the previous lifecycle, explicitly disable automatic release when compiling:

var compileConfig = CompileConfig.builder()
    .checkpointSaver(saver)
    .releaseThread(false) // backward compatible option
    .build();

var graph = workflow.compile(compileConfig);

An interruption or an exception does not automatically release the thread. Interrupted runs remain available for Human-in-the-Loop continuation, and failed runs remain available for the application's recovery strategy. graph.updateState(...) continues to work in those situations as before.

The practical upgrade check is to examine what your code does after successful completion. Any inspection, replay, resume, or manual-release logic that assumes an active checkpoint set needs attention.

Experimental versioning for released runs

Checkpoint tags gain optional version information. BaseCheckpointSaver.Tag exposes threadId(), version() as an Optional<Integer>, checkpoints(), and lastCheckpoint().

Two lookup methods make released runs accessible:

Optional<Tag> tag(RunnableConfig config, Integer version) throws Exception;

Optional<Tag> lastTag(RunnableConfig config) throws Exception;

The version argument to tag(...) is nullable. lastTag(...) retrieves the latest tag regardless of whether it is versioned.

GraphResult.asLastCheckpointStateData() now obtains its data through Tag.lastCheckpoint(), preserving its observable result. This is useful continuity for callers retrieving the final checkpoint state while the underlying release model evolves.

Parent and Subgraph savers work together

Subgraphs increasingly carry real agent behavior, so their persistence lifecycle must follow the parent execution.

BaseCheckpointSaver now supports putSubGraphSaver(...) to register a subgraph saver and listSubGraphSaver(...) to retrieve registrations associated with a parent configuration. SubCompiledGraphNodeAction registers its saver with the parent; AbstractCheckpointSaver.release(...) then cascades release to the registered subgraph threads.

If you implement a custom saver, AbstractCheckpointSaver provides a reference implementation of the registration mechanism. Review that lifecycle when adapting your implementation, especially if your agents contain nested compiled graphs.

Interruption and Error Metadata

The saver contract also exposes explicit lifecycle hooks:

void registerInterruption(
    RunnableConfig config,
    InterruptionMetadata interruptionMetadata) throws Exception;

Tag releaseCheckpointsOnError(
    RunnableConfig config,
    Throwable error) throws Exception;

These allow a saver to retain interruption information and distinguish an error release from normal completion. InterruptionMetadata now also exposes the interruption reason. That gives later analysis more context about why an execution stopped.

The error-release hook does not change the default described above: an exception leaves the thread available, and the caller chooses its recovery or release strategy.

Note: 👀

To avoid leaving lots of unfinished records in the checkpoint persistence layer, we recommend calling saver.releaseOnError(RunnableConfig, Throwable) within exception handling logic. We are currently considering automating this in a future release by having the graph execution engine invoke the method whenever an error occurs.

The in-memory, file-system, Redis, Postgres, Oracle, MySQL, CockroachDB, DynamoDB, and Hazelcast savers have been aligned with this contract through default implementations. The amount of information retained remains a concern of the specific saver implementation.

SQLite and PostgreSQL V2 savers

Both relational integrations add implementations backed by versioned SQL resources:

Integration	New implementation	Existing implementation
SQLite	`SQLiteSaverV2`	`SQLiteSaver`, for the V1 schema
PostgreSQL	`PostgresSaverV2`	`PostgresSaver`, for the V1 schema

The V2 implementations align with the updated release, error, and interruption contract. The original classes remain available for their V1 schemas. Treat adoption of a V2 saver as a persistence change to review against your existing database.

Other changes worth knowing before upgrading

Explicit Graph Inputs

GraphInput becomes the preferred API for expressing whether an execution is starting or resuming:

graph.stream(GraphInput.args(Map.of("input", "Hello")), config);
graph.stream(GraphInput.resume(), config);
graph.stream(GraphInput.resume(Map.of("approval", "APPROVED")), config);

Use GraphInput.noArgs() for a new execution without arguments. The older map-based stream and invoke overloads remain available in 1.9, but are deprecated for removal. Moving away from a null map makes the intended operation explicit.

Diagnostics and State Serialization

RunnableConfig.nodePath() supplies the current node path for regular nodes and subgraphs, replacing the older partial graphPath() usage. A node can also intentionally interrupt execution by raising GraphInterruptException.

State cloning remains enabled by default. RunnableConfig.builder().disableCloneState() opts out, which can help during early development with objects that are not yet serializable. Exposed state may then reflect later mutations, so consider how consumers retain or modify it.

StateSerializer.declareTransientAttributes(...) excludes named attributes from serialized data and restores them from the same serializer's in-memory transient storage. Those values do not survive a restart, a different process, or a new serializer instance. Keep anything needed for durable resume in persisted state. GsonStateSerializer is deprecated for removal; move toward Jackson-based serialization.

Agent infrastructure

The experimental core skills API introduces SkillSource, SkillPath, and SkillParser.

Spring AI builds on this with SubAgent, CustomSubAgent, SkilledReactSubAgent, and SkillResource, making compiled agents reusable as tools. I covered the pattern in Skill-Based Sub-Agents with LangGraph4j and Spring AI.

LangGraph4j Studio gets a visual refresh

Studio 1.8

Studio 1.9

In the new Studio the active node receives a blue highlight and a loading indicator, making execution easier to follow at a glance.

LangGraph4j DSL

The release also adds langgraph4j-dsl, whose JsonDslGenerator exports graphs, including parallel nodes and nested subgraphs, as JSON:

String json = compiledGraph.reduce(new JsonDslGenerator<>());

This representation has been used for the Studio refactoring toward React Flow library.

What's Next for LangGraph4j

The next phase of development will focus on three areas. These are roadmap priorities, with scope and delivery to evolve as implementation progresses.

Persist more of the execution context

I want to improve graph execution-context persistence so that it supports monitoring and post-processing analysis more effectively. The checkpoint lifecycle work in 1.9 is a step in that direction: understanding completed, interrupted, and failed runs is essential when agentic workflows move into production.

The aim is to make retained execution information more useful for understanding behavior and for subsequent analysis and processing.

Redesign parallel node execution

Another priority is to redesign the parallel-node implementation, removing current limitations and improving efficiency. As workflows grow, parallel branches need to become easier to compose and manage.

This is upcoming work. Applications using 1.9 should continue to account for the currently documented parallel-execution limitations.

Improve built-in Agents for Spring AI and LangChain4j

Finally, I want to enhance the built-in agent infrastructure for both Spring AI and LangChain4j. The skills and sub-agent work demonstrates how much can be built on top of graph execution; the goal is to make those building blocks more useful and easier to compose across both integrations.

Try the Release

Update the LangGraph4j BOM to 1.9.0 to keep module versions aligned:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.bsc.langgraph4j</groupId>
      <artifactId>langgraph4j-bom</artifactId>
      <version>1.9.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Conclusions

For an existing 1.8.x application, start with the migration guide, review thread release and stored checkpoint compatibility, then exercise interruption, resume, and completion paths with your chosen saver.

I'm interested in feedback from real workflows, especially around custom progress output and checkpoint management. Check out LangGraph4j, try the release, and let me know what would help your next agentic application. If you find the project useful, leave a star ⭐️ and... happy AI coding! 👋

Originally published at https://bsorrentino.github.io on September 18, 2026.

Interesting experimentation using Spring AI and LangGraph4j

bsorrentino — Wed, 19 Aug 2026 09:26:37 +0000

l3o6

Aug 8

Building an Agentic Harness with Spring AI and LangGraph4j

#springboot #java #agents #langgraph4j

4 min read

Interesting AI use case, using LangGraph4j to orchestrate and AiService by LangChain4j, it's a great match

bsorrentino — Fri, 07 Aug 2026 20:42:35 +0000

Praveen Yadav

Aug 5

Building a Multi-Agent Hiring Workflow with LangChain4j and LangGraph4j on Spring Boot

#java #ai #llm #springboot

10 min read

Skill-Based Sub-Agents with LangGraph4j and Spring AI

bsorrentino — Mon, 04 May 2026 20:27:26 +0000

Combine Tools & Skill to create Agent

Modern agentic systems usually expose two strong but separate abstractions:

Tools, which give an LLM executable capabilities
Skills, which package reusable instructions for a narrow task

This article shows how to combine both ideas in LangGraph4j so that a skill is not just prompt text, but a fully operational sub-agent exposed as a tool. The result is a practical pattern for building modular multi-agent systems in Java with Spring AI and LangGraph4j, while keeping each agent focused, reusable, and low in context cost.

Starting from a standard ReACT agent, the approach implemented is quite simple.

Load a SKILL.md file
Read its front matter to define the tool contract ( name and argument description)
Use the skill body as the sub-agent system prompt
Restrict the sub-agent to only the tools declared by the skill
Register the sub-agent in a parent ReAct agent as if it were a normal tool

In other words, a skill becomes an executable tool-backed agent.

Why This Pattern Matters

The standard ReAct pattern already gives an LLM a strong execution model: reason, choose a tool, inspect the result, and continue until the task is complete. That model is useful because the LLM does not need to commit to a fixed plan up front. It can adapt after every tool call.

The next step is to let a tool itself be implemented by another agent.

Once that happens, the parent agent is no longer forced to know every operational detail. It only needs to know:

which specialized capability exists
when to invoke it
what input to pass

The specialized logic is delegated to a narrower agent with its own instructions and its own restricted toolset. This gives us a clean sub-agent architecture without inventing a new orchestration primitive. We reuse the same tool-calling semantics that ReAct agents already understand well.

Why Reusing Tool Semantics Is Powerful

One of the most valuable properties of LLM-based agents is their ability to build and revise a tool execution plan while reasoning over intermediate results. ReAct made this practical by combining thought, action, and observation in a loop.

When a tool call can transparently invoke another agent, we preserve that planning model instead of replacing it.

The parent agent can:

decide that a specialized capability is needed
provide only the task-relevant context
wait for a result exactly as it would for a standard tool

The child agent can:

run its own reasoning loop
invoke its own allowed tools
return a compact outcome to the parent

This gives hierarchical coordination without exposing the full inner workflow to the parent prompt.

Minimizing Context and Token Usage

This pattern also improves context discipline.

Without sub-agents, a single generalist agent often needs:

every tool definition
all operating instructions for every domain
every procedural rule in one large system prompt

That quickly becomes expensive and unreliable.

With skill-based sub-agents:

the parent only sees high-level capabilities
each child sees only the instructions relevant to its task
each child receives only the tools it is allowed to use

This narrower context has practical benefits:

fewer tokens sent to the model
lower prompt interference between unrelated domains
clearer tool choice
better modularity as the system grows

The allowed-tools skill property plays an important role here anabling tool filtering. It turns tool access into an explicit design decision instead of an accidental side effect of what happened to be registered globally.

Reference implementation

I've started implementation in the new LangGraph4j release stream 1.9 currently in active development. The implementation is centered on [SkilledReactSubAgent], which turns a markdown skill into both:

a compiled LangGraph4j sub-graph
a Spring AI tool (i.e. ToolCallback)

That means the same component can participate in the graph as an agent and present itself to the parent LLM as a callable tool.

In particular the flow is:

Parse the SKILL.md
Extract name and description from front matter
Optionally filter tools using allowed-tools
Use the markdown body as the sub-agent instructions
Compile the agent
Wrap it into a function tool whose input is a single context field

The important design choice is that the tool definition is derived from the skill metadata, while the agent behavior is derived from the skill content.

Skill Format

The supported skill format is

---
name: <agent name>
description: "|"
        <multi line description>
allowed-tools: <list of tools>
---

<skill body>

From Skill to Tool-Backed Agent

The conversion happens in SkilledReactSubAgent.Builder#build(...). This is the crucial bridge where:

the skill metadata defines the external API
the skill body defines the internal operating behavior
the allowed tools define the sub-agent execution boundary

The resulting agent is then wrapped as a Spring AI function tool.

From the parent agent point of view, this is just another tool. Internally, it is a complete ReAct-capable agent workflow.

Examples

Purchase Assistant Agent

This is an agent that allow to select a produdct from a reference marketplace and purchase it. Below the simplified component diagram.

Marketplace Skill

---
name: agent-marketplace
description: |
    marketplace agent, ask for information about products. This is agent that provides the information on the product marketplace.
    required data are:
    * product name
allowed-tools: searchByProduct
---

## Retrieve product information
We need all information about about the product of interest in particular is mandatory to have
* product name

with such information we have to invoke tool `searchByProduct` and return the result

Payment Skill

---
name: agent-payment
description: |
    payment agent, this is the agent that provides payment service.
    required data are:
    * Product name
    * Product price
    * Product currency
    * the International Bank Account Number (IBAN) - optional

allowed-tools:
    - submit-payment
    - retrieve-iban
---

## submit a payment for purchasing a specific product
We need all information about purchasing to allow the payment

* Product name
* Product price
* Product price currency
* International Bank Account Number (IBAN)

With such information you must invoke tool `submit-payment` and return the result of the payment transaction plus the IBAN.
If IBAN is not provided invoke tool `retrieve-iban` to retrieve the required IBAN.

Observing the skills above they define three different concerns:

name: the tool name exposed to the parent agent
description: the tool description shown to the model
allowed-tools: the only tools available inside the sub-agent

Everything after the front matter becomes the sub-agent system prompt.

Again, this is a strong separation of concerns. The parent agent sees a concise tool contract, while the child agent receives richer operating instructions.

Finally the code

Below a representative code snippet that show how wires two skill-based sub-agents into a parent agent:

var subAgentMarketplace = SkilledReactSubAgent.builder()
        .chatModel(chatModel)
        .tools(Marketplace.tools())
        .build(compileConfig,
                SkillSource.of(Paths.get("skills/agent-marketplace/")));

var subAgentPayment = SkilledReactSubAgent.builder()
        .chatModel(chatModel)
        .tools(Payment.tools())
        .build(compileConfig,
                SkillSource.of(Paths.get("skills/agent-payment/")));

var purchaseAssistantAgent = AgentExecutorEx.builder()
        .chatModel(chatModel)
        .tool(subAgentMarketplace)
        .tool(subAgentPayment)
        .build(compileConfig);

var input = """
        search for product 'X'.
        If found proceed to payment with IBAN US82WEST1234567890123456 
        to purchase it
        """;

var result = purchaseAssistantAgent.invoke( 
        GraphInput.args( Map.of("messages", new UserMessage(input) )), runnableConfig);

This composition is interesting because the purchase agent (the parent) does not need detailed knowledge of:

how product lookup works
how payment submission works
when IBAN retrieval is required

Those rules are delegated to the sub agents themselves.

That is a simple but good example of behavioral encapsulation. The parent agent only decides to involve marketplace agent to retrieve product and after that to involve payment agent to purchase.

This is a very basic but representative example, it is useful because it shows the intended layering:

the user gives a single business request
the parent agent decomposes the work
specialized sub-agents execute their own logic
the final answer comes back through the normal tool-response path

Interesting note that each sub agent, potentially, can relies on different LLM chat model so we can further optimize overall agent execution process

Below a more detailed componet diagram generated by LangGraph4j itself.

From this diagram it is quite clear that the sub agents are nothing but sub-graphs

Design Advantages

This approach has several practical advantages.

Reuse Existing Agent Patterns

There is no need to invent a separate orchestration protocol for sub-agents. A sub-agent is exposed as a tool, so the parent agent can use standard ReAct behavior without extra prompting complexity.

Better Modularity

Each skill owns:

its tool-facing identity
its internal instructions
its allowed tool boundary

That makes the system easier to evolve than a single monolithic agent prompt.

Smaller and Cleaner Context

The child agent receives only what it needs. This reduces token usage and lowers the risk that unrelated instructions distort tool choice or task execution.

Safer Capability Scoping

By filtering tools from allowed-tools, the framework prevents a child agent from accidentally seeing tools outside its intended domain.

Better Reusability

A skill can be packaged, versioned, and reused across different parent agents. The same marketplace or payment skill can participate in many workflows as long as the tool contract remains stable.

Tradeoffs and Implementation Considerations

This pattern is strong, but it is not free of tradeoffs.

The Parent Must Summarize Well

Because the child receives a single context field, the parent agent needs to pass the relevant facts clearly. If critical information is omitted, the child may need extra recovery steps or may fail to act.

Tool Descriptions Matter More

Since the parent sees the child as a tool, the name and description fields in the skill front matter become part of the routing surface for the LLM. Weak metadata will reduce invocation quality.

Prompt Boundaries Need Discipline

The skill body is effectively the child system prompt. If it is vague, contradictory, or overloaded, the benefits of modularity disappear. Skills need to stay focused.

Observability Is Important

Nested agents can make execution harder to inspect if tracing is weak. LangGraph4j's graph structure and step streaming help here, but production systems should still invest in logging and traceability.

Why LangGraph4j Fits This Well

LangGraph4j is a good fit for this pattern because it already models agent workflows as explicit graphs and integrates naturally with Spring AI tool abstractions.

That matters for two reasons:

the sub-agent is not just prompt composition; it is a compiled graph with state and execution hooks
the parent integration remains ergonomic because Spring AI already treats capabilities as tools
LangGraph4j support interruptions in subgraph enabling Human In The Loop also when involving sub agents

So the implementation is not forcing two incompatible ideas together. It is aligning:

LangGraph4j graph execution
Spring AI tool calling
markdown-defined skills

into a single reusable agent-building pattern.

Conclusion

Turning a skill into a sub-agent is a small change with a large impact.

It lets us:

preserve the strengths of the ReAct loop
delegate specialized behavior cleanly
reduce context size
constrain tool access per domain
build multi-agent systems out of reusable skill modules

The idea is implemented in a compact and pragmatic way: a SKILL.md file becomes the source of both the sub-agent prompt and the tool contract exposed to the parent agent.

For Java teams building agentic applications with Spring AI and LangGraph4j, this is a practical pattern for moving from a single large agent toward a modular multi-agent design without abandoning the tool semantics that current LLMs already handle well.

The implementation is in progress on release 1.9-SNAPSHOT in develop branch of LangGraph4j repository but the first result are very promising.

Hope this could help and encourage usage of LangGraph4j for your next Agentic Workflow. Checkout project, try it and let me know your feedback and... happy AI coding! 👋

Originally published at https://bsorrentino.github.io on April 28, 2026.

Interesting reading for who are approaching use AI for developing at scale

bsorrentino — Mon, 30 Mar 2026 07:48:38 +0000

Incomplete Developer

Mar 26

Spec-Driven Development: Return of Best Practices

#specdrivendevelopment #vibecoding #ai

4 min read

Agent Definition Language (ADL): The Open Source Standard for Defining AI Agents 👀. Looks promising https://www.nextmoca.com/blogs/agent-definition-language-adl-the-open-source-standard-for-defining-ai-agents

bsorrentino — Tue, 10 Feb 2026 09:28:44 +0000

Agent Definition Language (ADL): The Open Source Standard for Defining AI Agents — Next Moca

GitHub Repository: https://github.com/nextmoca/adl

nextmoca.com

Observability matter

bsorrentino — Fri, 06 Feb 2026 17:47:43 +0000

bsorrentino

Feb 6

LangGraph4j Hooks and OpenTelemetry

#langgraph4j #agents #observability #opentelemetry

3 min read

LangGraph4j Hooks and OpenTelemetry

bsorrentino — Fri, 06 Feb 2026 17:44:50 +0000

Why Observability Matters

Agentic workflows are dynamic: nodes may run conditionally, in parallel, or be skipped entirely. When something fails, a simple stack trace is rarely enough. Observability gives you a unified view of what happened, where it happened, and why.

In practice, observability helps you:

Understand end-to-end execution flow.
Detect performance bottlenecks early.
Correlate errors with specific nodes, edges, and state transitions.

Why Telemetry Matters

Observability is only possible if you collect high‑quality telemetry. Telemetry is the raw signal: traces, logs, and metrics. Without it, probably, you are debugging your system partially.

In agent graphs, telemetry becomes even more important because state and control flow are distributed across steps. The same workflow can behave differently depending on state, configuration, or external tool results.

The LangGraph4j hooks

LangGraph4j hooks are small, composable interceptors that sit around nodes and conditional edges. They let you run custom logic before, after, or wrapping the core action, without modifying the node itself.
Hooks can be registered globally (applies to all nodes/edges) or by ID (targeted to a specific node/edge), and their execution order is LIFO(Last In First Out) for BeforeCall/AfterCall, FIFO(First In First Out) for WrapCall.
This makes them a precise, low‑friction mechanism for cross‑cutting concerns like tracing, metrics, logging, or state inspection.

How Hooks Enable Observability

Hooks provide lifecycle interception points around node and edge execution. This is the ideal place to add logging, metrics, or traces without contaminating business logic.

In LangGraph4j you can intercept execution before, after, or around node/edge calls. Here is a minimal example that measures node execution time and logs it:

var graph = new StateGraph<>(MyState.SCHEMA, serializer)
    .addWrapCallNodeHook((nodeId, state, config, action) -> { // add Wrap call node hook
        var start = System.currentTimeMillis();
        return action.call()
            .whenComplete((res, err) -> {
                var ms = System.currentTimeMillis() - start;
                log.info("node '{}' took {}ms", nodeId, ms );
            });
    })
    .addNode( "node1", action1 )
    .addNode( "node2", action2 )
    ....
    .compile();

This pattern scales: you can plug in structured logs, metrics counters, or spans with the same hook mechanism.

OpenTelemetry in the Java Ecosystem

OpenTelemetry is the standard for observability across modern platforms. In Java it provides:

Tracing via spans
Metrics via meters
Logs via instrumentation

You configure it once and export telemetry to a backend like Jaeger, Grafana, or the OpenTelemetry Collector. The key benefit here is portability: you are not locked to a single vendor.

How LangGraph4j Hooks Enable OpenTelemetry

LangGraph4j includes a dedicated module, langgraph4j-opentelemetry, that provides hook implementations ready for tracing node and edge execution. Consider it as a reference implementation about how to integrate OpenTelemetry in LangGraph4j

The module includes:

OTELWrapCallTraceHook: creates spans for each node and edge call, adding config/state attributes and start/end events.
OTELWrapCallTraceSetParentHook: creates a parent span so node/edge spans are grouped inside a workflow scope.

A minimal integration looks like this:

var otelHook = new OTELWrapCallTraceHook<MyState>(serializer);
var parentHook = OTELWrapCallTraceSetParentHook.<MyState>builder()
    .scope("MyWorkflow")
    .groupName("stream")
    .build();

var workflow = new StateGraph<>(MyState.SCHEMA, serializer)
    .addWrapCallNodeHook(otelHook)
    .addWrapCallEdgeHook(otelHook)
    .addWrapCallNodeHook(parentHook)
    .addWrapCallEdgeHook(parentHook)
    .addNode( "node1", action1 )
    .addNode( "node2", action2 )
    .addContitionalEdges( "node2", edgeAction, 
            EdgeMappings.builder()
            .to("node1")
            .toEnd()
            .build() )
    ...        
    .compile();

This keeps node logic clean while producing rich, correlated traces for the entire workflow.

Below an example of output in Jaeger tracing platform

Conclusion

Hooks are the foundation for observability in LangGraph4j: they give you structured interception points without affect your main workflow code. OpenTelemetry builds on top of this by standardizing how telemetry is collected and exported in the Java ecosystem.
Combined, they deliver production-grade visibility for complex agent workflows.
Checkout project, try it and let me know your feedback and ... happy AI coding! 👋

References

OpenTelemetry

Originally published at https://bsorrentino.github.io on February 4, 2026.

I read this in a post: "AI agents are 5% models and 95% engineering glue." I completely agree, but I feel like it's not so clear among software engineers. This helps us to understand that we need to focus on adding value around models.

bsorrentino — Sat, 31 Jan 2026 08:55:24 +0000

Top GitHub Users By Public Contributions in Italy https://github.com/gayanvoice/top-github-users/blob/main/markdown/public_contributions/italy.md I'm at 26th place 👨‍💻 🚀😉

bsorrentino — Fri, 23 Jan 2026 15:04:34 +0000

top-github-users/markdown/public_contributions/italy.md at main · gayanvoice/top-github-users · GitHub

Check your ranking in GitHub! Don't forget to star ⭐ this repository. - gayanvoice/top-github-users

github.com

[Top GitHub Users By Public Contributions in Italy] (https://github.com/gayanvoice/top-github-users/blob/main/markdown/public_contributions/italy.md) I'm at 26th place 👨‍💻 🚀😉

bsorrentino — Fri, 23 Jan 2026 14:58:26 +0000

top-github-users/markdown/public_contributions/italy.md at main · gayanvoice/top-github-users · GitHub

Check your ranking in GitHub! Don't forget to star ⭐ this repository. - gayanvoice/top-github-users

github.com

Exploring Javelit, the Java counterpart to Streamlit, for rapid prototyping and AI agents using LangGraph4j.

bsorrentino — Sat, 20 Dec 2025 20:42:38 +0000

bsorrentino

Dec 20 '25

Experimenting with Javelit - The Streamlit for Java

#java #ui #ux #javelit

4 min read