LangGraph4j

The deciding trait is that you do not have to leave. Agent frameworks are overwhelmingly written for one language, and the usual answer in a Java shop is a small Python service nobody wants to own, with its own deployment and its own on-call. This removes that service entirely.

What you trade is the ecosystem. The examples, the blog posts and the answers to your specific error message are all written about the original, and you will be translating them. Pick it if the JVM is where your team already lives. Pick the Python original if you are free to choose.

The risk is the feature. A graph supporting retries and clarification loops can revisit a node indefinitely, and no default iteration ceiling, no recursion guard and no spend limit appear in the documentation. The termination argument is left to whoever wrote the conditions.

That is a reasonable position for a library and a bad surprise for a first-time user, because the failure is quiet. What it does right is refusing to hide the loop: a cycle is an edge somebody wrote down rather than a retry buried inside a framework, so the thing that will spin is visible in the code.

1. A single named state passed between nodes is the decision that makes everything else analysable. What a node may read and what it may write become properties of a type rather than of a prompt, which means a reviewer can reason about information flow without executing anything at all.

2. Persistence is a separate module rather than an assumption, so a graph can be durable or not without changing shape. 3. No evaluation is published and none is needed: this is a port of a specified model, and the interesting question is fidelity to that specification, which is answered by reading.

The dependency is strategic rather than technical. A port inherits its direction from the project it tracks, which means the interesting design questions get answered somewhere else, by people with different priorities and a different language. That is fine for adoption and it caps what this can become.

Moat: the JVM audience, which is large, conservative and underserved, and that is a better position than it sounds. Likely path is continued volunteer maintenance for as long as the upstream model stays interesting to somebody. Position: safe to import, and treat it as a dependency rather than as a strategy.

This is not a tool I roll out, it is a dependency somebody adds, which changes my question from procurement to governance. It arrives through the same artefact repository, the same version pinning and the same review my build already applies to every library, so the control already exists.

The language baseline is met and the cost is engineering time rather than licences. What I own afterwards is the service my team builds with it, including model spend, logging and the on-call rota. Approved with conditions: it belongs inside a service my platform team runs, not in sixty engineers' hands.

The licence is permissive and the distribution is boring in the best way: coordinates in a build file, a bill of materials so the versions agree, and no installer, no account and nothing to opt out of. That is what a library should feel like when you add it.

Model access is delegated to the integration layer underneath, so whatever that supports is what I get, which includes a runtime on my own hardware and costs this project no code at all. What is missing is protocol support: nothing here speaks MCP, so my servers stay somebody else's problem.