What our run actually established
Our run installed documentation dependencies; it did not build or test the JVM framework. The stored record is dated October 13, 2026, at commit f34ed80, with full SHA f34ed80826c879b03a1fc063370eedcf65767c16. The harness selected npm in embabel-agent-docs, despite also detecting Maven in the repository.
Our sandbox used the lab-node:22 image with 3 CPUs and 8 GB RAM. The stored install outcome is success, 3 seconds, exit code 0 and no timeout. Build and test each have an explicit skipped outcome with the reason "no script". Skipped steps are not failures, but they provide no passing-test evidence either. There is no supported Maven test total to report from this run.
The harness records command outcomes separately through success flags, exit codes, elapsed time, timeout flags and log tails; skipped steps carry their own reason. The MrKeyoor testing methodology explains that reporting approach and its limits. That page provides provenance context, not evidence that this older run used today's procedure or completed additional work.
The stored npm audit result contains zero advisories. Scan coverage is unknown because the record has no scannedPackages field. Neither that result nor the successful install establishes the security of Embabel's JVM dependencies or a deployed application. The install log also contains deprecation warnings for inflight and glob.
When the planner is worth evaluating
Embabel Agent is a JVM framework that replans after each action. Its README defines flows through actions, goals, conditions and domain objects. The default planner uses Goal Oriented Action Planning, while Utility AI is another documented option.
The useful distinction is whether your application benefits from choosing a route through known actions. If several goals can reuse those actions, planning deserves a trial. If the application always follows the same sequence, direct orchestration may be easier to inspect and maintain. This is a design choice, not a performance result from our sandbox.
Execution scope also matters. Focused mode invokes a particular agent. Closed mode selects an agent but runs only its defined actions. Open mode can compose actions across the platform and is described by the README as the least deterministic mode. Even then, individual steps must have been specified by developers; model-driven steps can still produce nondeterministic results.
Start an evaluation with one bounded goal and focused execution. Check that the available actions produce the intended route, then test missing inputs and unsuccessful actions before widening the scope. The README also warns against exposing mutation or deletion casually through domain-object tool methods.
What the persistence issue now says
Issue #1965 was closed as completed in #2004 on September 12, 2026. Its original report described paused processes tied to one pod's memory, but the subsequent discussion describes snapshot persistence rather than requiring a persistent AgentProcessRepository itself.
A maintainer describes the intended recovery scenario as one waiting process whose pod dies, followed by restoration and resumption on another pod. The same discussion explicitly excludes concurrent editing of one blackboard by multiple users. A September 5 comment says integration with caching persistence stores was going into release 1.5.2.
Those updates make the original issue body insufficient evidence for a blanket claim that persistence remains absent. They also do not prove a particular backend, configuration or recovery path works in your deployment. Read the issue and its resolution, verify the implementation in the version you select, and exercise a pod-loss recovery before relying on a long human approval wait. Our run did not test persistence.
The supplied release page concerns version 1.5.1. It is separate from the October checkout and does not establish that our run tested that release. No application compatibility or release-validation result follows from the documentation install.
Which alternative fits the application
Spring AI provides Spring-friendly APIs for connecting application data and APIs with AI models. Its README documents model access, structured outputs, tools, retrieval and MCP. Embabel itself builds on Spring AI, so Spring AI is a foundation within Embabel as well as a direct option for applications that want to orchestrate calls themselves.
LangChain4j provides unified APIs for LLM providers and embedding stores. Its README also documents agents, retrieval and integrations with Quarkus, Spring Boot, Helidon and Micronaut. Consider it as a replacement candidate when the decision centers on Java integration and framework choice. The supplied extract does not establish equivalent planning or process-recovery behavior.
How the ratings are assessed
For assessed dimensions, 1 means the supplied evidence shows substantial obstacles, 3 means it supports evaluation with material limits, and 5 means it supports a strong assessment across that dimension. Scores 2 and 4 fall between those anchors. Unknown dimensions remain unassessed rather than receiving a midpoint.
Documentation receives 3/5 because the supplied README explains the programming model, execution modes, setup and examples, while this review has not verified those instructions through an application build. Setup ease, community support and production maturity remain unassessed: the documentation install, release notes and issue discussion cannot establish those dimensions.