Spring AI Alibaba

For a Java shop this is the path of least resistance, and the trait that decides it is that an agent is a component in the application you already deploy rather than a Python service somebody has to operate alongside it. The four composition patterns cover most of what teams actually build: run in order, run in parallel, route by condition, loop until done.

There is also a console for building and evaluating agents visually, which will either help your non-Java colleagues or become a second thing to run. Pick it for Spring services. Pick Koog when the language is Kotlin and the target includes a phone.

The risk is gravity. The framework is open and the abstractions are general, and the integration the documentation reaches for first is the parent company's own model service. That is normal and it is also the thing to check: how well the alternatives are exercised, and whether a deployment that cannot use that service hits paths nobody runs in continuous integration.

Test your intended provider before committing. What it does right: the console imports flows from another low-code platform's format, so migrating in is a supported operation instead of a rewrite, which is rare enough to note.

1. There are two layers by design. A graph runtime supplies persistence and streaming for long-running stateful agents, and the agent framework's composition patterns sit on top, so an author can drop to the graph when the patterns do not fit. 2. The practices that usually live in undocumented prompt engineering are surfaced as hooks with names, covering compaction, context editing, retry on tool failure, limits on model and tool calls, planning and dynamic tool selection.

Turning tacit practice into declared configuration is the most reviewable form of this work, and almost nobody does it.

The strategy is sound and the market is genuinely underserved. Enterprise Java is where the durable systems live, the agent frameworks all arrived in Python, and whoever is the obvious answer for that audience earns years of default consumption. Publishing it free and letting the model service collect is the correct sequencing.

The constraint is geography. For buyers outside the vendor's home region, the parent's identity is a procurement factor regardless of the licence, which caps the addressable market rather than the technology. No acquirer, no exit, it is a strategic line item. Position: evaluate on the engineering, decide on the jurisdiction.

Zero cost for sixty engineers and the runtime requirement is one we met years ago, so infrastructure has no new argument. Agents become components inside existing services, which means our deployment, monitoring and on-call arrangements already cover them. That is the cheapest possible adoption curve.

The administrative console is the part that needs a decision. It is another application to host, another surface to protect, and there is no described identity integration for it, so it would sit behind our own controls or not at all. Onboarding is short for a Spring developer. Approved with conditions: framework yes, console only behind our own access layer.

Apache-2.0 and it installs the way Java installs, which is to say a coordinate and a build file rather than a shell script I have to read first. Tool servers are managed from the console instead of a text file, which is not my preference but is at least a place rather than a mystery, and agents can address each other over the open agent protocol.

My complaint is the model layer: the board records no local support, so the machine I built stays out of the loop and every request needs a key. The secret scanner in their pipeline is a nice touch.